From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mumit Khan To: John Garrison Cc: cygwin@sourceware.cygnus.com Subject: Re: Libraries not working Date: Sat, 31 Jul 1999 18:34:00 -0000 Message-ID: <199907061953.OAA32457@mercury.xraylith.wisc.edu> References: <3782524D.4971CB17@visi.net> X-SW-Source: 1999-07n/msg00106.html Message-ID: <19990731183400.ixnRqs14H1u3yCgq_yaMt_drnebViJXV7lLRXbkCU8Y@z> John Garrison writes: > What I am creating is a game programming library. I am using the low > level library called SDL. SDL has a demo lib that > loads in images, that lib is call IMGLib. I have compiled IMGLib using > the Makefile provided and the cross-compiler. I'm with you so far. We have two libraries -- SDL and IMGLib. We have to of course keep in mind the dependencies when linking against these two libraries. Remember that Unix linkers are single pass (uni-directional), and processes left-to-right. There are times it's necessary to supply the same library multiple times on the link command line to resolve inter-dependencies between archives (it usually points to bad design decision, but that's not relevant here). > It > compiled and linked fine. (IMG.h is where IMG_Load_RW is defined, it is > implemented in IMG.c) So I have a compiled library > which had IMG_Load_RW defined and implemented. I installed the IMGLib > library in my cross-compiler's paths (include and > lib) > When I compile my library (which includes code from IMGLib) It compiles > and links fine under the cross-compiler. Sidebar: in the C language, `defined' has a very specific meaning; functions and variables are declared and defined, not defined and implemented. C++ added a few more tweaks to this to handle the case of template instantiations, but still essentially the same. I was confused when I saw your message the first about a function being defined in the header file (which can happen, but not very usual). How can you "link" a library? I'm assuming you mean that you could build the archive libIMG.a correctly. $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW (or, i386-mingw32-nm if you're using Mingw cross-compiler). shows what? > However, > if I try to build the IMGLib example directly with IMGLib, or one of my > libs examples, which would use IMGLib indirectly, > it brings the error 'undefined reference to IMG_Load_RW' I have > included IMG.h, which declares IMG_Load_RW and I have > included -lIMG which is the libIMG.a file that implements IMG_Load_RW. > As I said everything compiles fine under GCC and IMG_Load_RW being the > only function from IMGLib it can't find confuses me, > if it were a linker error then it would complain about all of the > functions being passed from IMGLib wouldn't it? > Although the problem only exists when trying to compile a binary, so it > only makes since that it is in the linker, but if > it can find all the other functions why can't it find IMG_Load_RW? > I've asked Sam Lantinga (the guy that created SDL) the only suggestion > he had was that I was using an older version of his > library which I am not. (and that would make little difference anyway > because I compiled IMGLib with the same libSDL.a as I > am trying to compile and link my examples with) Yes I am using a windows > version of SDL. > What really baffles me is that even the Makefile for the show.c IMGLib > examples gives the error, if I were leaving out > something it would make since, but the Makefile wouldn't leave something > out. > And yes I am also included -lSDL because other parts of the program need > it. > The language is C by the way. > Here is the gcc command I am giving (actually I am using a Makefile, but > here is the result of what make is giving) > > (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -I/usr/win32/include Have you tried: (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]? Where is the module that gets the undefined reference? In ex1.c, libPD.a, libSDL.a or libttf.a? That is a crucial piece of information. > > I have tried changing the position of -lIMG to the middle and the back I > have try putting -I before the -l's and after the > -l's, I just can't figure out why it would work fine on Linux GCC and > not Win32 GCC. Because Linux and Windows32 are two different OSs, use different shared library mechanisms, and there are bugs in GCC/binutils on both (albeit more under Windows32 than on Linux) ... Impossible to guess from the information at hand; however, if you're building shared libraries for Linux, then it makes perfect sense since ELF shared libraries don't need to have all symbols resolved at link time. > Is this enough info? I am trying to keep it relatively short. More is always better than not enough in my book. At this point, without taking a look at the code and the way it's being built, I'm afraid I can't be of any more help. Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com