From: Rashad M <moh...@gm...> - 2014-05-26 06:52:09
|
Hello, I build a library say A with mingw and then another library B which depends on libA. Now libA has been sucessful in building with mingw. It has proper dllexport and dllimport symbols defined. and class uses it class EXPORT_OF_A classOfA { }; so far so good. Now when building libB with same mingw toolchain. I dont need to use EXPORT defines. This seems to me a bit strange. I could build my dll linked with libA and no issue. But when building an exe on top of dlls from libB I want to proper export. This part seems fair. I dont understand why dllexport/dllimport macro is not required to build dll which are linked with a dll having classes properly exported? Is it by design or am I missing something very important. Could anyone explain this to me.? So far I had read: http://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/ http://mingw.5.n7.nabble.com/More-fun-w-dllexport-and-dllimport-td11559.html http://stackoverflow.com/questions/2810118/how-to-tell-the-mingw-linker-not-to-export-all-symbols -- Regards, Rashad |
From: Keith M. <kei...@us...> - 2014-05-26 09:02:36
|
On 26/05/14 07:51, Rashad M wrote: > I dont understand why dllexport/dllimport macro is not required to build > dll which are linked with a dll having classes properly exported? It works on a per DLL basis; each has its own exports table. When you build any DLL with MinGW tools, if no symbol added bears the dllexport attribute, then *all* symbols added will be exported, by default. As soon as you add just one symbol qualified with this attribute, (either explicitly, or by .def file inference), then only symbols so qualified will be included in the exports table, (unless you build with the --export-all-symbols option). > Is it by design or am I missing something very important. Could anyone > explain this to me.? It is by design; see the description for --export-all-symbols, in the ld documentation. -- Regards, Keith. |