Very Computer

Undefined first referenced
symbol in file
socket   big/long/path/file.o  (symbol belongs to implicit dependency
more/path/usr/lib/libsocket.so.1)

If I got the environment set up so that it actually found libsocket
in the non-standard location, and the link knows the symbol is in
there, why doesn't it go ahead and link it?

More important, what should I do about it?

(The library was copied from /usr/lib -- this is an attempt to
keep linking the old one should an O.S. upgrade happen to change it.)

--
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

All righty then, let me try another question:

   What's the name or URI of a really good reference on all the
painful details of how shared libraries are handled at compile time,
link time, and run-time?

In Ada, when I need to call A_Func from libFF.so, I just put
pragma ("-L<path> -lFF"); in my Ada.  The guy that calls my code
doesn't have to know every library I use directly or indirectly.

Isn't there any way to do something similar in C?  The guy that
writes the main program has to recursively identify anything used
by any called code and list all of them in his Makefile?

How does he identify what is needed by libFF ?  By trying to link
and looking at the error messages?

--
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Linker and Libraries guide. Available on your documentation CD or
on-line at <URL:http://docs.sun.com>.

Use Solaris 8 reference because the latest and greatest linker subsystem is
backported in patches to older releases. In case your application needs
some dynamic linker feature which is not present in the original OS release,
simply require suitable linker patch.

Quote:> In Ada, when I need to call A_Func from libFF.so, I just put
> pragma ("-L<path> -lFF"); in my Ada.  The guy that calls my code
> doesn't have to know every library I use directly or indirectly.

> Isn't there any way to do something similar in C?  The guy that

Certainly.

Quote:> writes the main program has to recursively identify anything used
> by any called code and list all of them in his Makefile?

That guy should never be put in that position.

Quote:> How does he identify what is needed by libFF ?  By trying to link
> and looking at the error messages?

Suppose your libFF.so depends on libfoo.so, which lives in /opt/foo/lib.
You should link libFF like this:

cc -G *.o -o libFF.so.1 -h libFF.so.1 -L/opt/foo/lib -R/opt/foo/lib -lfoo -lc
ln -s libFF.so.1 libFF.so

Now, when someone wants to use libFF, all he needs to do is supply -lFF
(and possibly -L and -R flags needed to find libFF, but not for libfoo), ie.

cc *.o -o my_app -L/opt/FF/lib -R/opt/FF/lib -lFF

Run-time linker will look at libFF.so.1 object and it will see that
it requires libfoo, so it will try to load that one, using runpath
encoded in libFF.so.1 (/opt/foo/lib). Which should be sucessful.
The main application doesn't have to be linked with libfoo and it doesn't
have to have /opt/foo/lib in its runpath.

Each shared object should be self-contained, ie. all libraries it needs
should be recorded in the object itself, not in the main application.
If you don't do it, then the only remaining thing to do is to record
dependencies in the main application. But that's a bug, actually.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

Quote:> Suppose your libFF.so depends on libfoo.so, which lives in /opt/foo/lib.
> You should link libFF like this:

> cc -G *.o -o libFF.so.1 -h libFF.so.1 -L/opt/foo/lib -R/opt/foo/lib -lfoo -lc
> ln -s libFF.so.1 libFF.so

> Now, when someone wants to use libFF, all he needs to do is supply -lFF
> (and possibly -L and -R flags needed to find libFF, but not for libfoo), ie.

> cc *.o -o my_app -L/opt/FF/lib -R/opt/FF/lib -lFF

> Run-time linker will look at libFF.so.1 object and it will see that
> it requires libfoo, so it will try to load that one, using runpath
> encoded in libFF.so.1 (/opt/foo/lib). Which should be sucessful.
> The main application doesn't have to be linked with libfoo and it doesn't
> have to have /opt/foo/lib in its runpath.

Well, this is certainly better than what I had before.  Thanks.
But the problem still is that at link time, all the libraries
(including libfoo and libc) are under configuration control.
The path the libraries are in at link time does not exist
at runtime on another machine.

Quote:> Each shared object should be self-contained, ie. all libraries it needs
> should be recorded in the object itself, not in the main application.

Definitely.  And your message helps me get closer to that goal.
But not quite there.

--
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

That could be a problem and there are several things you can do, but it
depends on the actual situation. libc will always be in /usr/lib, so
you don't have to do anything special to find it.

Could you describe the exact situation with your libraries?

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)