On Sat, 2007-11-03 at 01:18 -0400, al davis wrote: > On Saturday 03 November 2007, DJ Delorie wrote: > > In Windows, you have to create an import library to link > > against. Look for a program called "dlltool" (or > > mingw-dlltool); it should have options for reading a DLL and > > creating a suitable .a to link against. > > > > Alternately, you should be able to list the dll as a regular > > library (I don't know if the -lfoo syntax works), and the > > linker will synthesize the import library for you. > > > > I'm still confused.
It confused the heck out of me when I was building a windows version of gschem. Basically, in that case, it wouldn't work, because of some not very portable coding in the libgeda library. In that case (and I realise not yours, as those are plugins), it was possible to statically link libgeda. In the gschem case, it didn't work because libgeda (what would have become the dll) needed to resolve symbols exported by gschem. Is this the issue here? As I understand it (and probably just saying what DJ has done with different words...) When dynamic linking in windows, you have to compile a small "stub" library and statically link that into your program which wants to load the DLL. The stub library will contain (symbols?) for every symbol that makes up your DLL interface. So, it appears that all your symbols are now statically resolved at compile time, however the (stub / import) library actually gets bent into pointing at the DLL symbols at load time. This site has an explanation of windows dynamic linking (at the bottom of the page), and I've read others on Microsoft's MSDN site too: http://www.iecc.com/linker/linker10.html So... it sounds like you may need to define all the interfaces which your DLL may have (and are imported by gnucap), to built an import library (some "foo.dll.o" building with libtool?, I think this is where the example used "exports.o"). Just remembering the real issue here.. the extern symbols which come from gnucap (or other DLLs?). I'm not sure how to fix that, but perhaps the following articles are of interest: http://msdn2.microsoft.com/en-us/library/fdy23fx6(vs.80).aspx http://support.microsoft.com/kb/131313 http://cygwin.com/ml/cygwin/2002-01/msg00236.html > In the dlltool man page, it gives an example: > ========= > gcc -c dll.c > dlltool -e exports.o -l dll.lib dll.o > gcc dll.o exports.o -o dll.dll > gcc program.o dll.lib -o program > ========= > (it's actually i586-mingw32msvc-gcc, and so on, > but that is a non-issue) > > > [EMAIL PROTECTED]:/tmp/al>i586-mingw32msvc-g++ -c foo.cc > [EMAIL PROTECTED]:/tmp/al>i586-mingw32msvc-dlltool -e exports.o -l foo.lib > foo.o > [EMAIL PROTECTED]:/tmp/al>i586-mingw32msvc-g++ foo.o exports.o -o foo.dll > foo.o:foo.cc:(.text+0x7): undefined reference to `bar()' > /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib/libmingw32.a(main.o):(.text+0x85): > undefined reference to [EMAIL PROTECTED]' > collect2: ld returned 1 exit status > > ok ... the first two steps seem to work, but not the third. > > The fourth is not practical because the program > cannot know about the dll. It knows an interface, > but nothing else. It cannot know which dll's will > be used, or how many of them. As it sounds like you're looking at this for loading plugins, I'll just quickly say that I've no idea how to make it dlopen the file at runtime, and looking at Igor's GPMI library would be a useful thing to do. > > Note that the "will be resolved later" stuff is different > > with DLLs; check google to see if it's even possible to do > > lasy resolution (find "bar" after the program loads, so that > > the program's bar is called). You might have to hand-edit an > > import description file and use it to build an import library > > for that one symbol. > > In the real file, there are hundreds of symbols needing > lazy resolution. There are also hundreds of dll's being built. > The program can not know anything about the dll's, > other than the calling mechanism, which is really C++ > virtual functions, with a dispatcher. It is working great > on Linux now. > > Are you telling me that Windows cannot do lazy resolution? For really lazy resolving (as symbols are used, not as the program loads), "thunk" functions are used for each symbol, and these do the resolving when they are first called. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
