|
Home > Archive > Unix Programming > January 2004 > strange gcc compile/link issues
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
strange gcc compile/link issues
|
|
| John Galt 2004-01-23, 5:36 pm |
| Okay, so I began with a simple problem:
$ g++ -o client client.o stun.o udp.o
Undefined first referenced
symbol in file
HMAC stun.o
EVP_sha1 stun.o
recvfrom udp.o
ld: fatal: Symbol referencing errors. No output written to client
collect2: ld returned 1 exit status
Now, recognizing the 3 undefined symbols, I said:
$ g++ -L/lib/openssl -lcrypto -lssl -lxnet -o client client.o stun.o
udp.o
Undefined first referenced
symbol in file
EVP_sha1 stun.o
HMAC stun.o
ld: fatal: Symbol referencing errors. No output written to client
collect2: ld returned 1 exit status
Note that the "recvfrom" error has vanished. But the 2 others remain.
And now:
$ g++ -L/lib/openssl -lxnet -o client client.o stun.o udp.o -lcrypto
-lssl
$ ### it works !! ###
I had asked a similar question (ref. openssl) on this group some time
ago, and the net of the resulting discussion was that I shouldn't have
specified linker libraries before the object files. So, I ask 3 new
questions:
1. What should come first in cases like this? Link lib options like
-llib or the object files?
2. Does the rule apply to all libraries or just specific ones, e.g.
ones that were (or were not) created using gcc
3. Why does -lxnet work before the objs but -lcrypto -lssl work only
when specified after the objs
TIA,
John Galt
P.S. for what it's worth, all this happened on Solaris 9 with gcc 3.3
| |
| Paul Pluzhnikov 2004-01-23, 5:36 pm |
| johngalt__@hotmail.com (John Galt) writes:
quote:
> 1. What should come first in cases like this? Link lib options like
> -llib or the object files?
Objects should *always* preceede any libraries on the link line.
quote:
> 2. Does the rule apply to all libraries or just specific ones, e.g.
> ones that were (or were not) created using gcc
The rule aplies to *all* libraries, regardless of the compiler.
quote:
> 3. Why does -lxnet work before the objs but -lcrypto -lssl work only
> when specified after the objs
Probably because libxnet is shared, but crypto and ssl are archive.
Read this for an explanation of why shared libraries should follow objects:
http://groups.google.com/groups?thr...d.earthlink.net
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Casper H.S. Dik 2004-01-23, 5:36 pm |
| johngalt__@hotmail.com (John Galt) writes:
quote:
>1. What should come first in cases like this? Link lib options like
>-llib or the object files?
The linker libraries are not really "options" but they are shorthand for
"library pathnames"; they are searched as they are encountered
on the command line.
quote:
>2. Does the rule apply to all libraries or just specific ones, e.g.
>ones that were (or were not) created using gcc
All libraries.
quote:
>3. Why does -lxnet work before the objs but -lcrypto -lssl work only
>when specified after the objs
That's because shared libraries are linked completely and
unconditionally; all their symbols become and stay known;
archive (.a) libraries are used only partially; those objects
known to be needed at the time the library is encountered are
loaded and all the others are ignored.
So "cc -lsharedlib foo.o" appears to work but "cc -larchivelib foo.o"
will generally completely ignore archivelib unless it happens to
satisfy some of the symbols in the runtime startup (crt0.o)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|