Just felt like sharing... (no pun intended)

[dhd@tarwebok] ~/src/parisc$ cat libhello.c
int foo(int bar)

{
	return bar + 42;
}

[dhd@tarwebok] ~/src/parisc$ cat hello-shared.c
int main()

{
	extern int foo(int bar);
	int (*gar)(int) = foo;
	printf("Hello shared library world!\n");
	printf("The answer is %d, or maybe %d\n", foo(0), (*gar)(0));
	return 0;
}

[dhd@tarwebok] ~/src/parisc$ hppa-linux-gcc -fPIC -shared -o /home/nfsroot/parisc/libhello.so libhello.c
[dhd@tarwebok] ~/src/parisc$ hppa-linux-gcc -o /home/nfsroot/parisc/hello-shared hello-shared.c /usr/local/lib/gcc-lib/hppa-linux/2.96/libgcc.a -L/home/nfsroot/parisc -lhello

(... and, over on the serial console window ...)

# uname -a
Linux 10.160.240.101 2.3.99-pre8 #230 Fri Aug 11 13:59:53 EDT 2000 parisc unknown
# ls -l ld.so
-rwxr-xr-x    1 1000     103        405189 Aug 12 18:58 ld.so
# ./ld.so
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

--list list all dependencies and how they are resolved
--verify verify that given object really is a dynamically linked
object we can handle
--library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST

# ls -l hello-shared libhello.so
-rwxr-xr-x    1 1000     103       1338314 Aug 12 17:23 hello-shared
-rwxr-xr-x    1 1000     103          8486 Aug 11 19:02 libhello.so
# export LD_LIBRARY_PATH=/
# ./ld.so --list hello-shared
        libhello.so => /libhello.so (0x40001000)
# ./ld.so hello-shared
Hello shared library world!
The answer is 42, or maybe 42

There's still a lot of work to be done, of course - glibc doesn't completely build with --enable-shared yet, and libdl.so is going to be somewhat more challenging (luckily the IA-64 people have already encountered some of the same issues). Also note the kludgy way we have to explicitly link libgcc.a, which was mentioned in a previous thread.

I just thought this was pretty cool :-)

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Good work!

Also Linux/Alpha probably has most of the same issues solved for a long time.

Indeed.

Dave

 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on       |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 ____________________________|___ http://www.treblig.org  |________/

Well, Alan Modra did most of the work. Getting binutils up to snuff was certainly a lot more complicated than writing a few lines of assembly code in dl-machine.h :-)

Not really, because on Alpha, function pointers are actually function pointers, branches are longer than 256K, the linker and the assembler know how to give you the offset from the GP to the PC, all code is PIC, and perhaps most importantly, Digital Unix's runtime architecture is reasonably sane ;-)

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.