[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting 'undefined reference' errors during linking but I think I in

From: cs
Subject: Re: Getting 'undefined reference' errors during linking but I think I included all libraries?!?
Date: Fri, 2 May 2003 10:46:42 -0700 (MST)


I was thinking about your comment that -L's must come before -l's but
that it is /not/ necessary for -l's to go AFTER .o files and main()'s that
call thosefunctions......

(I verified this is true by making a toy program that uses pow function
and thentrying 'gcc -lm test.c' and 'gcc test.c -lm'. -> both worked.)

I wonder if we are just getting lucky putting -l's before function calls
by using gcc and g++.....
What do I mean??

I was having a conversation with a C guru and he told me that ANSI C standard
doesn't /require/ C compiler to do multiple passes when linking.  Multiple
passes meanthat compiler looks at /all/ junk on command line /before/ adding
libraries.  This is usefulbecause then compiler can see if program USES a 
library when deciding whether
to /ignore/ it or not.

It seems gcc/g++ are smart enough to look ahead at main() and .o files on
command line.Hence, you can put -l's anywhere!
(Why they can't look ahead in order to let you put -L's AFTER -l's as well
is beyond me.)
In summary, if one was *Really* obsessed with *portability across various
C compilers*, I wonder if one should get in habit of putting -l's after
object filesand main().... because there may be a C compiler out there that 
Just a thought.  Thanks again for the great help.  I'm happy now.



 -------- Original Message --------
   Subject: Re: Getting 'undefined reference' errors during linking but I
   think I included all libraries?!?   From: "Rusty Ballinger" <address@hidden>
   Date: Fri, May 2, 2003 1:08 am
   To: address@hidden

   > Did you know that when you link all the stuff to make
   > the executable that the *order matters*?!?!?

   (A more serious & deep-seated problem, I think, is that order matters
   when running individual commands.  For years I have been waiting for
   this sort of thing to get fixed:

     $ rm -f foo
     #  wait, I need that stuff!  better make a backup.
     $ cp foo foo.bak
     cp: cannot stat `foo': No such file or directory

   "You bastards!")

   > gcc -o myprogram myprogram.o func1.o func2.o
   >       -L $(srcdir)/libs -lsomearchive -lm -lX11
   >        -lpthread -L somepath ...etc.
   > The -L guys *must* be *after* the object files!!!!
   > The whole reason for my problem was that I put the
   > -L stuff in my name_LDFLAGS line instead of
   > name_LDADD!!!

   I don't think that's true:

     $ g++ -o foo foo.o -lsomeLib
     /tmp/cc2eBnZJ.o: In function `main':
     /tmp/cc2eBnZJ.o(.text+0x1e): undefined reference to [...]
     collect2: ld returned 1 exit status

     $ g++ -L/usr/tmp/somelibdir -o foo foo.o -lsomeLib

   That's with gcc 3.2, but I think any compiler will be the same.  I
   think all that matters is that the -L precedes the -l.

   > Not only that but if some libraries depend on other ones
   > then you must be careful of the /order/ you specify all the -l guys
   > in!!!

   Yes, "but", your compiler's man page or other documentation will tell
   you that.  (& although I think putting all your -L's in LDFLAGS is
   probably fine, you can get finer control, if you need it, by putting
   "-L/path/to/foolib -lfoo -L/path/to/barlib -lbar" etc. in LDADD.
   Also, automake's info page does say it's OK to put -L's in LDADD.)

   > I kept modifying the gcc link line and finally got one
   > that WORKED!!! The trick now is getting to reflect
   > that.

   You "should" be able to just put your -l's in the right order in LDADD
   or foo_LDADD; isn't automake leaving them alone?

   (also, in case it's not clear, although -L's and -l's can be
   intermixed, the -L which says where to find a library needs to precede
   the -l which gives the name of that library.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]