undefined symbol ....

undefined symbol ....

Post by Wes Grolea » Thu, 12 Oct 2000 04:00:00



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

 
 
 

undefined symbol ....

Post by Wes Grolea » Sat, 14 Oct 2000 04:00:00


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

 
 
 

undefined symbol ....

Post by Drazen Kac » Sun, 15 Oct 2000 10:33:23



> 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?

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.
(_  \ /  _)


 
 
 

undefined symbol ....

Post by Wes Grolea » Fri, 20 Oct 2000 04:00:00


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

 
 
 

undefined symbol ....

Post by Drazen Kac » Sun, 22 Oct 2000 04:00:00



> > 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.

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.
(_  \ /  _)


 
 
 

1. undefined symbol: gdk_imlib_get_cache_info

Hello,
I have RedHat 5.2 and I recently installed the GNOME RPM's for version
1.01. When I did the install I could not Upgrade (Update?) the gtk-1.06
version that was installed originally so I installed gtk-1.2 (rpm -i
rather than rpm -U). After the install I tried to exec gnome-session but
I always get the following error:  'undefined symbol:
gdk_imlib_get_cache_info'

Can anyone help me out with this problem?

Thanks,
Eusebio

2. Please...Need Help with X

3. ioconf.o Undefined symbol in '_btintr' ????

4. Test the serail modem ...

5. Unable to load shared library due to undefined symbol cerr

6. Modem Elsa Microlink ISDN/TL V.34

7. Linker problems:spurious undefined symbols error

8. redhat support

9. g++ returns Undefined symbol error

10. Mandrake: undefined symbol _t24__default_alloc_template2b1i0.free_list

11. undefined symbol: gnome_window_icon_set_default_from_file

12. Undefined Symbol

13. Undefined symbol error?