[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting 'undefined reference' errors during linking but I think I in
Re: Getting 'undefined reference' errors during linking but I think I included all libraries?!?
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
(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
> 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
> 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
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
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 Makefile.am to reflect
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.)