On 7/31/2015 9:40 AM, Ruben Van Boxem wrote: > 2015-07-31 13:07 GMT+02:00 Edward Diener <[email protected] > <mailto:[email protected]>>: > > On 7/31/2015 6:05 AM, Ruben Van Boxem wrote: > > 2015-07-31 2:04 GMT+02:00 Edward Diener <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>: > > > > On 7/30/2015 10:48 AM, Óscar Fuentes wrote: > > > Edward Diener <[email protected] > <mailto:[email protected]> > > > <mailto:[email protected] > <mailto:[email protected]>>> > > > 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.
The reason I did not try it is that the design of the library, which is not my own, I am trying to "fix" does not export the whole class, but only particular member functions. In my own design of Windows dlls I always export an entire class but I can not overrule the design of someone else's library. > > > > 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. Which are the implicitly defined functions I must export individually ? Note that with the ex_exception class accessed from outside the shared library there is no problem but with the ex_xml_exception class there is a problem. > > 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. Glad to hear that. ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
