It was thus said that the Great Philippe Verdy once stated:
> Le sam. 24 nov. 2018 à 23:20, Sean Conner <sean@conman.org> a écrit :
% uname
Linux
% cc -c -o main.o main.c
% cc -c -o myfunc2.o myfunc2.c
% cc -shared -fPIC -o func.ss func.c
% ar rv libfuncall.so func.ss
% ar: creating libfuncall.so
% a - func.ss
% cc -Wl,-rpath,/tmp/foo -o smain2 main.o myfunc2.o libfuncall.so
% ./smain2
Hello from main
Hello from func1
Hello from myfunc2
Back to func1
Back to main
Hello from myfunc2
Back to main
Happy now?
That's what I wanted. And demonstrates what I wanted to show: this is the only portable and expected behavior !
>> There's no such limitation and portability issue when you don't use ANY
>> static library but only use "prelinked" shared libraries (like DLL on
>> windows or ELF libraries on Linux.. note that executable and DLL modules on
>> Windows, as well as on OS/2, are based on directly on the ELF format) !
> Citation needed.
I gave citations as examples, because there's nowhere any other counter example using shared/prelinked libraries (or archive formats containing an explicit manifest of the expected link order) any example I can find where this is not true.
So instead I ask you to demonstrate the existence of any counter-example !
The C standard itself does not really indicate how we will link units into a working program: it does not even need the existence of "libraries", it just speaks the possibility of creating programs using collections of units compilable separately (that's thbe meaning of the "extern" keyword in C), and then it needs to use an external linker and to specify the units you need for a working program in a well defined resolution order (and basic libaries which are only collections of units in unspecified order are not compatible with this goal).
But shared libaries/ prelinked libraries are compatible with this goal as their role is to prelink them partially, using also the same linker and the same specified order, which then gives a predictable resolution order for symbols in the library (something impossible to reach using only basic static libraries containining arbitrary number of object units in random order).
It's not a basic "librarian" tool that resolves symbols (the librarian is just a way to archive and pack multiple files into a single one, because it is generally faster to process than large collections of small files, from which they can be extracted without modification; the speed of processing was certinaly true with past filesystems, but it's no longer the case with modern filesystems). Only a true linker (actually made for building programs) does that work of resolving symbols accurately and predictably!
