Mail Archives: cygwin/1999/07/06/15:55:12
John Garrison <jeg AT visi DOT net> 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 AT sourceware DOT cygnus DOT com
- Raw text -