From: Rob L. <rl...@ar...> - 2001-06-28 16:53:32
|
Greetings, I have the MinGW Linux-to-Win32 cross compiler I built using this recipe I found this link under the MinGW FAQ: http://www.devolution.com/~slouken/SDL/Xmingw32/crossgcc/index.html Here's my question: How do I get the linker to output a Win32 EXE which dynamically links at run-time (under Windows) with a third party Win32 DLL? The linker is complaining about undefined references which are located in the third party Win32 DLL. Here are the commands: i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o test.o test.cpp i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o testmain.o testmain.cpp i386-mingw32msvc-gcc -mwindows -o test.exe test.o testmain.o test.o(.text+0x44):test.cpp: undefined reference to `...' test.o(.text+0x44):test.cpp: undefined reference to `...' test.o(.text+0x44):test.cpp: undefined reference to `...' ...etc., etc., etc... Thanks in advance, Rob |
From: Mumit K. <khan@NanoTech.Wisc.EDU> - 2001-06-29 00:52:07
|
On Thu, 28 Jun 2001, Rob Light wrote: > Here's my question: How do I get the linker to output a Win32 EXE which > dynamically links at run-time (under Windows) with a third party Win32 > DLL? Typical first step is to create an import library. Note that GNU linker is smart enough to directly link with the DLL, so you can just specify the DLL file directly on the command line. I'm more used to using an import library, so don't really know what the caveats are in linking directly to a DLL. MSVC as far as I know can't do that, and you have to have an import library. Of course, I'm assuming that the 3rd party DLL is not C++, in which case it simply won't work. > The linker is complaining about undefined references which are located > in the third party Win32 DLL. Here are the commands: > > i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o test.o test.cpp > i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o testmain.o > testmain.cpp > i386-mingw32msvc-gcc -mwindows -o test.exe test.o testmain.o Add the DLL at the end of the command line. Mumit |
From: <dan...@ya...> - 2001-06-29 02:30:57
|
--- Mumit Khan <khan@NanoTech.Wisc.EDU> wrote: > On Thu, 28 Jun 2001, Rob Light wrote: > > > Here's my question: How do I get the linker to output a Win32 EXE > which > > dynamically links at run-time (under Windows) with a third party > Win32 > > DLL? > > Typical first step is to create an import library. Note that GNU > linker > is smart enough to directly link with the DLL, so you can just > specify > the DLL file directly on the command line. I'm more used to using an > import library, so don't really know what the caveats are in linking > directly to a DLL. Don't try linking directly with DLL if stdcall (PASCAL) names are only visible as undecorated alias. This includes most most of w32api. For example setupapi.dll exports a function SearchForInfFile. To link against this lib you need an implib with the stdcall decoration, ie, SearchForInfFile@24. Also some Pascal compilers use different name decoration (add _ to start of external name. Here again you will need an implib. Danny > MSVC as far as I know can't do that, and you have > to > have an import library. > > Of course, I'm assuming that the 3rd party DLL is not C++, in which > case > it simply won't work. > > > The linker is complaining about undefined references which are > located > > in the third party Win32 DLL. Here are the commands: > > > > i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o test.o > test.cpp > > i386-mingw32msvc-gcc -c -I/home/rlight/test/include -o testmain.o > > testmain.cpp > > i386-mingw32msvc-gcc -mwindows -o test.exe test.o testmain.o > > Add the DLL at the end of the command line. > > Mumit > > > > _______________________________________________ > 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! |
From: Rob L. <rl...@ar...> - 2001-06-29 16:21:39
|
Mumit Khan wrote: > > On Thu, 28 Jun 2001, Rob Light wrote: > > > Here's my question: How do I get the linker to output a Win32 EXE which > > dynamically links at run-time (under Windows) with a third party Win32 > > DLL? > > Typical first step is to create an import library. Note that GNU linker > is smart enough to directly link with the DLL, so you can just specify > the DLL file directly on the command line. I'm more used to using an > import library, so don't really know what the caveats are in linking > directly to a DLL. MSVC as far as I know can't do that, and you have to > have an import library. What version of the GNU linker supports direct linking to DLLs? I have tried this but it still can't find the symbols. It may be because it's a C++ DLL :( > Of course, I'm assuming that the 3rd party DLL is not C++, in which case > it simply won't work. Can you elaborate why this won't work for C++? Is this because of mangled symbol names? So if I can't link to a C++ DLL, what then can I do? Do I need the import libraries? Can I just use a module definition files and create the import libraries myself? Thanks for the help! Rob |
From: <dan...@ya...> - 2001-06-29 21:00:57
|
--- Rob Light <rl...@ar...> wrote: > Mumit Khan wrote: > > > > On Thu, 28 Jun 2001, Rob Light wrote: > > > > What version of the GNU linker supports direct linking to DLLs? 2.10 and above I > have > tried this but it still can't find the symbols. It may be because > it's > a C++ DLL :( > > > Of course, I'm assuming that the 3rd party DLL is not C++, in which > case > > it simply won't work. > > Can you elaborate why this won't work for C++? Is this because of > mangled symbol names? > This used to be in G++ faq, but I couldn't find recent version on-line, so: "Why can't I link g++-compiled programs against libraries compiled by some other C++ compiler?" "Some people think that, if only the FSF and Cygnus Support folks would stop being stubborn and mangle names the same way that, say, cfront does, then any g++-compiled program would link successfully against any cfront-compiled library and vice versa. Name mangling is the least of the problems. Compilers differ as to how objects are laid out, how multiple inheritance is implemented, how virtual function calls are handled, and so on, so if the name mangling were made the same, your programs would link against libraries provided from other compilers but then crash when run. For this reason, the ARM encourages compiler writers to make their name mangling different from that of other compilers for the same platform. Incompatible libraries are then detected at link time, rather than at run time. " Danny _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |