Re: Libraries not working

[John Garrison <jeg@visi.net>]

Mumit Khan wrote:

>
> 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.
>

You're right that was a typo, as you read earlier I said it could be a linker
problem becuase it only happens when building executables :)

>
>   $ i586-cygwin32-nm libIMG.a | grep IMG_Load_RW
>
> (or, i386-mingw32-nm if you're using Mingw cross-compiler).
>
> shows what?
>

[bin]# ./i586-mingw32-nm /usr/win32/lib/libIMG.a | grep IMG_Load_RW
./i586-mingw32-nm: IMG.c: File format not recognized
./i586-mingw32-nm: IMG_tif.c: File format not recognized
./i586-mingw32-nm: IMG_xxx.c: File format not recognized
./i586-mingw32-nm: IMG_bmp.c: File format not recognized

What does it mean file format not recognized? it's  C code, compiled for windows
with mingw32. I would say maybe there were some Linux object files in the
directory that wouldn't have gotten recompiled, but that isn't likely, it would
be all the objects or nothing, make clean wipes out all .o files and make
creates all .o files.

> Have you tried:
>
> (CC) -Wall -O6 ex1.c -o ex1.exe -lIMG -lPD -lSDL -lttf -lIMG [...]?
>

Yes I have, makes no difference.

>
> 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.
>

When compiling ex1.c as the above example shows the problem is in libPD.a
When compiling show.c (the example for IMGLib) the problem is in show.c


>
> >
> > 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.
>

I have no problem sending code, but I'd need to know how much of it you'd need
to see. The problem is with IMGLib so I could send that directory tree, or
I could just send show.c and the command I'm using to compile it.

>
> Regards,
> Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com