SUMMARY: undefined procedure in shared lib

From: Quang Dangtran (quangd@mailhost.adaclabs.com)
Date: Thu Aug 20 1992 - 22:49:15 CDT


The answer is:
>put value.o in lib*.so.*

What I found out was that you really dont need lib*.sa.*, just only lib*.so.*.
Solaris 2.0 does not require lib*.sa.*. And since we will be going to
Solaries 2.0 soon, this works out fine.

More detailed answers below.
--------------
Thank you very much for those who replied and mostly to casper@fwi.uva.nl:

poffen@sj.ate.slb
guy@auspex.com
birger@vest.sdata.no
cynthia@ll.mit.edu

A while ago, I asked the question:

--------------
>Hello Sunmanager,

>Does any know why the ld.so complains on when I try to run test_app.
>test_app was built as: acc -o test_app test_app.o -lfoo_lib...

>ld.so: call to undefined procedure _foo from 0xf776306c.

>Although foo() is defined in the shared lib file.c.
>file.c is compiled and archived with flags:

>acc -Xc -pic ... file.c
>ar rv foo_lib.sa.1.1 file.o
>ranlib foo_lib.sa.1.1

>I am using 4.1.1, sparc 2

>Thank you very much.
-------------

But since the question was vague and most of the answers I've got
was different from everybody else. So I resubmited a more detailed
question to those that replied:

--------------

| Thank you for all your responses. I guess that I owe you guys
| an apology for not elaborating the problems I was asking.
|
| So please let me elaborate it a little bit. I have three simple files:
|
| main.c - Set a value defined in static library(libvalue.sa.1.1)
| set_it.c - Shared function, defined in libvalue.so.1.1
| value.c - Just a file which defines a global variable(int value)
|
| The built was successfull, but when I try to run, "main", I got:
|
| ld.so: Undefined symbol: _value
| ---------------------------------------------------------
|
| file: main.c Built as:
| acc -Xc -c main.c
| acc -o main main.o -L. -lvalue
|
| -------------------
| main()
| {
| set_it(2);
| get_set_value();
| }
| --------------------
|
| file: set_it.c Built as:
| acc -Xc -c -pic set_it.c
| ld -o libvalue.so.1.1 -assert pure-text set_it.o
| --------------------
| #include <stdio.h>
| extern int value;
|
| set_it (int i)
| {
| print ("set_it %d\n", i);
| value = i;
| }
|
| get_set_value(void)
| {
| printf ("get_set_value %d\n", value);
| }
| ---------------------
|
| file: value.c Built as:
| acc -Xc -c -pic value.c
| ar cq libvalue.sa.1.1 value.o
| ranlib libvalue.sa.1.1
| ---------------------
| int value;
| ---------------------
|
|
| Thank you very much for your help.
-------------

And here is the answer:

> You must also include ``int value'' in the shared library.
>
> The lib*.sa.* part should contain all functions/data that you
> want to be statically linked. (In fact, it should contain all
> exported initialised data of a library). Those functions and data
> should also be present in the lib*.so.* part. This may not
> be obvious from the documentation.
>
> A number of libraries (e.g., X11) didn't obey this rule, because
> it wasn't enforced by the compiletime linker (ld). During runtime
> no problems arose, because of the special construction of the libraries.
>
> With SunOS 4.1.2 I get:
>
> cc -o main main.o -L. -lvalue
> ld: Undefined symbol
> _value
>
> With SunOS 4.1.1 I get:
> cc -o main main.o -L. -lvalue
> ./main
> ld.so: Undefined symbol: _value
>
> You need to put the exported data in the .sa part, if they are used
> by the library functions themselves. The .sa part is not loaded
> at runtime, but only at compile time. If, as in your case, the
> exported data is only in the .sa part AND the exported data is not
> referenced from the executable, the exported data is not loaded in
> the resulting executable. Since all data have to be bound at the
> start of execution, ld.so fails immediately with an undefined symbol.
>
> The fix is simple: put value.o in lib*.so.*



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:48 CDT