2015-07-31 13:07 GMT+02:00 Edward Diener <eldlistmaili...@tropicsoft.com>:
> On 7/31/2015 6:05 AM, Ruben Van Boxem wrote: > > 2015-07-31 2:04 GMT+02:00 Edward Diener <eldlistmaili...@tropicsoft.com > > <mailto:eldlistmaili...@tropicsoft.com>>: > > > > On 7/30/2015 10:48 AM, Óscar Fuentes wrote: > > > Edward Diener <eldlistmaili...@tropicsoft.com > > <mailto:eldlistmaili...@tropicsoft.com>> > > > writes: > > > > > >>> Another thing is to get some hints from a .map-file. > > >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the > > >>> of the link-cmd. > > >> > > >> I could not find any documentation regarding the linker options > you > > >> specify in the gcc documentation. Are they mingw-64 specific ? If > so > > >> where would thye be documented ? > > > > > > Those are not gcc options, but `ld' (the GNU linker) options. > > > > > > "-Wl" directs gcc to pass the following comma-separated options to > ld. > > > > To whom do I report this bug ? Does it go to mingw-64, to gcc, to > the ld > > linker on Windows ? I have shown this bug occurring through the > example > > I posted and I do not think anything I have shown is not standard > C++. > > It can be reproduced by anyone. I am not knowledgeable enough about > the > > workings of mingw-64/gcc or mingw-64/ld to be able to figure out why > > this bug is occurring but someone knowledgeable enough should be > able to > > fix what needs to be fixed. > > > > > > I'm not sure this is a GCC bug. Does the linker error also occur when > > using static libraries, and when you dllexport the whole class as > > opposed to the functions you're explicitly defining? > > I have tried neither. > It would be a helpful experiment. > > > I believe this error is the same as your previous one: you're not > > dllexporting some implictly defined functions. > > Which ones ? You can see the code. > As I said in my previous "crystal ball" solution to that problem, it would definitely help if c++filt worked again. Hmm, it just occurred to me that adding an underscore to the name would change how c++filt looks at a name. The linker cannot find functions it needs in ex_xml_exception::~ex_xml_exception() This function is empty, so there are implicit function definitions at play, which as I said, have no reason to be dllexported by default. > > Now, if this is what MSVC > > does, perhaps GCC should be modified to follow that behaviour, but that > > is not certain at this point. > > It has to be a bug in either gcc or ld using mingw-64 unless you can > show me what is wrong with the code which produces the link errors. > Unless you tell me that gcc/ld on Windows is incapable of > exporting/importing individual member functions of a class rather than > the class as a whole this is a bug somewhere in gcc/ld. > The thing is, you're not exporting the implicitly defined functions. Because you haven't defined them with the dllexport attribute, nor is the class as a whole dllexported, do its functions can't inherit that attribute. Why can you not dllexport the whole class, if I may ask? Note that e.g. this web page ( http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL) discusses the problems and workarounds. None of the options there says to export individual functions. Probably because it leads to exactly this type of issue. Also, I don't think the virtual inheritance has anything to do with it. Ruben > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
