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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]