public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: John Garrison <jeg@visi.net>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Libraries not working
Date: Sat, 31 Jul 1999 18:34:00 -0000	[thread overview]
Message-ID: <199907061953.OAA32457@mercury.xraylith.wisc.edu> (raw)
Message-ID: <19990731183400.ixnRqs14H1u3yCgq_yaMt_drnebViJXV7lLRXbkCU8Y@z> (raw)
In-Reply-To: <3782524D.4971CB17@visi.net>

John Garrison <jeg@visi.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@sourceware.cygnus.com

  reply	other threads:[~1999-07-31 18:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-06 12:01 John Garrison
1999-07-06 12:53 ` Mumit Khan [this message]
1999-07-06 13:21   ` John Garrison
1999-07-06 14:27     ` Mumit Khan
1999-07-31 18:34       ` Mumit Khan
1999-07-31 18:34     ` John Garrison
1999-07-31 18:34   ` Mumit Khan
1999-07-31 18:34 ` John Garrison
  -- strict thread matches above, loose matches on Subject: below --
1999-07-06 14:31 DJ Delorie
1999-07-06 14:50 ` Mumit Khan
1999-07-06 15:04   ` John Garrison
1999-07-06 15:23     ` Mumit Khan
1999-07-06 15:47       ` John Garrison
1999-07-06 19:31         ` Mumit Khan
1999-07-31 18:34           ` Mumit Khan
1999-07-31 18:34         ` John Garrison
1999-07-31 18:34       ` Mumit Khan
1999-07-31 18:34     ` John Garrison
1999-07-31 18:34   ` Mumit Khan
1999-07-31 18:34 ` DJ Delorie
1999-07-05 13:21 John Garrison
1999-07-06 11:15 ` Mumit Khan
1999-07-31 18:34   ` Mumit Khan
1999-07-31 18:34 ` John Garrison
1999-07-03 22:42 John Garrison
1999-07-04  9:57 ` tjoen
1999-07-04 17:51   ` Mumit Khan
1999-07-05 11:02     ` tjoen
1999-07-31 18:34       ` tjoen
1999-07-31 18:34     ` Mumit Khan
1999-07-31 18:34   ` tjoen
1999-07-31 18:34 ` John Garrison

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199907061953.OAA32457@mercury.xraylith.wisc.edu \
    --to=khan@xraylith.wisc.edu \
    --cc=cygwin@sourceware.cygnus.com \
    --cc=jeg@visi.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).