From: <dan...@ya...> - 2001-06-02 01:03:37
|
Thanks for the example. FWIW, when you have dllexport attributes marked in the code, as per your example, there are simpler ways of building and using the dll. This builds a working exe from your example: g++ -shared -o test.dll -Wl,--out-implib,libtest.dll.a test.cc g++ -o test1.exe test1.cc -L. -ltest.dll Danny --- Andrew Begel <ab...@ee...> wrote: > I found the bug here. It turns out that my a2dll looked like: > > CC=g++ a2dll libfoo.a -o foo.dll -Wl,--whole-archive -L/blah > -lcommon.dll -Wl,--no-whole-archive > > The whole-archive flag caused the linker to try to rexport the symbols > in the import library libcommon.dll.a, which were already being exported > by the common.dll itself. Since they were used in libfoo.a, too, I got a > multiple definition error. Once I removed the --whole-archive (and > --no-whole-archive) linker flags, everything links perfectly. > > In case you're wondering, here's my small example: > > test.h: > > #if defined(__CYGWIN32__) || defined(__MINGW32__) > > #if defined(BAR_BUILD_DLL) && defined(BAR_USE_DLL) > #error "USING_DLL and BUILDING_DLL are simultaneously defined!" > #endif > > #ifdef BAR_BUILD_DLL > #define BAR_API __declspec (dllexport) > #endif BAR_BUILD_DLL > > #ifdef BAR_USE_DLL > #define BAR_API __declspec (dllimport) > #endif BAR_USE_DLL > > #if !defined(BAR_BUILD_DLL) && !defined(BAR_USE_DLL) > #define BAR_API > #endif > > #else __CYGWIN32__ > > #define BAR_API > > #endif __CYGWIN32__ > > class BAR_API Foo { > public: > int foo(); > int bar(); > }; > > inline int Foo::foo() { > return 6; > } > > ------------- > test.cc: > > #include "test.h" > > int Foo::bar() { > return 7; > } > > int joe(Foo *f) { > return f->foo(); > } > --------------- > test1.cc > > #include "test.h" > #include <stdio.h> > > int main(int argc, char **argv) { > Foo f; > printf("%d\n", f.foo()); > printf("%d\n", f.bar()); > } > ----------- > > command lines: > > g++ -c -DBAR_BUILD_DLL -fno-inline -fno-rtti -fno-exceptions > -fno-gnu-keywords -pipe -g -fno-default-inline -fno-inline-functions -o > test.o test.cc > > ar cru libtest.a test.o > > ranlib libtest.a > > a2dll libtest.a -o test.dll > > g++ -c -DBAR_USE_DLL -fno-inline -fno-rtti -fno-exceptions > -fno-gnu-keywords -pipe -g -fno-default-inline -fno-inline-functions > -fnative-struct -o test1.o test1.cc > > ar cru libtest1.a test1.o > > ranlib libtest1.a > > a2dll libtest1.a -o test1.dll -Wl,--whole-archive -L. -ltest.dll > -Wl,--no-whole-archive > > And the error message: > > Creating shared library 'test1.dll' > ./libtest.dll.a(d000002.o)(.text+0x0): multiple definition of > `Foo::foo(void)' > libtest1.a(test1.o)(.text$foo__3Foo+0x0): first defined here > Creating library file: libtest1.dll.a > > > > Andy > > > -----Original Message----- > > From: Danny Smith [mailto:dan...@ya...] > > Sent: Thursday, May 31, 2001 1:03 AM > > To: Andrew Begel; min...@li... > > Subject: Re: [Mingw-users] problem with inline C++ member functions in > > DLLs > > > > > > > > --- Andrew Begel <ab...@ee...> wrote: > I've > > built a DLL with a > > C++ class that defined an inline function, like > > > so: > > > > > > class DLLDECL Foo { > > > > > > ... > > > > > > public: > > > int hello(); > > > } > > > > > > inline Foo::hello() { > > > return 6; > > > } > > > > > > DLLDECL is __declspec(dllimport) or __declspec(dllexport) as > > > appropriate. > > > > > > > > > I compiled this into its .o, ar'd it into a .a, and then used Paul's > > > a2dll utility (extremely handy, thanks!) to turn it into a DLL. > > > > > > Then, I create another file (george.cc) that #include's this class, > > > along with the inline function definition. I compile and > > link that, but > > > when I used a2dll to try to turn that into a DLL, I get a multiple > > > definition error: hello() is defined twice, once in the > > import library > > > for the DLL that a2dll created, and once in the george.cc file. > > > > > > Looking in the import library for my first DLL, I see three > > definitions > > > re: hello: > > > > > > I __imp___hello__C3Foo... > > > I __nm__hello__C3Foo... > > > T _hello__C3Foo... > > > > > > This last definition is the problem I think. Should this > > really be in > > > the import library? I think that this definition causes the > > a2dll'ing of > > > george.cc to fail, since I'm sure that its .o contains the inline'd > > > definition of hello() as well. > > > > > > Is this a GCC bug (i'm using gcc 2.95.2-3 from the > > mingw.org web page) > > > where inline functions that are inlined after the class > > definition are > > > marked to be included in the import library, when they > > really shouldn't? > > > > > > > Inline class methods - whether defined inside or outside the > > class definition - > > "inherit" the dll[im/ex]port status of their class. Why > > shouldn't they be? > > I don't that that in itself is causing the problem. > > > > I'm not quite clear how you built your second dll. Could > > you send code for a > > minimal testcase that shows the same error. > > > > > > > > Danny > > > > > > > > > > > > > Thanks, > > > > > > Andrew > > > > > > _______________________________________________ > > > MinGW-users mailing list > > > Min...@li... > > > > > > You may change your MinGW Account Options at: > > > http://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > > ______________________________________________________________ > > _______________ > > http://messenger.yahoo.com.au - Yahoo! Messenger > > - Voice chat, mail alerts, stock quotes and favourite news > > and lots more! > > _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |