ld: how to force symbol resolution in shlibs on Linux

ld: how to force symbol resolution in shlibs on Linux

[skaller]

Hi, I have a problem trying to figure out if it even possible to force
linkage against shared libraries to resolve all 'user' symbols on Linux.

The option --[no-]allow-shlib-undefined controls this but seems useless
because it forces resolution of gcc compiler internal symbols related
to the GOT etc which must remain unresolved until runtime linkage.

Linkage on Cygwin and MinGW and with MS linkers does not exhibit 
this behaviour, which is highly undesirable in most circumstances.
This makes it impossible to predict the failure of linkage on other
platforms when building on Linux .. and as a side effect delays
error detection on Linux until load time.

Surely ld supports forcing resolution of some symbols and not
others? In which case one can lay the blame on gcc for failing
to correctly annotate the symbols?

[Pls CC to me as I don't read this list]

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net

Re: ld: how to force symbol resolution in shlibs on Linux

[Daniel Jacobowitz]

On Sun, Mar 05, 2006 at 02:06:32PM +1100, skaller wrote:
> Hi, I have a problem trying to figure out if it even possible to force
> linkage against shared libraries to resolve all 'user' symbols on Linux.
> 
> The option --[no-]allow-shlib-undefined controls this but seems useless
> because it forces resolution of gcc compiler internal symbols related
> to the GOT etc which must remain unresolved until runtime linkage.

Sorry, you're using phrases that don't accurately describe anything.
You'll get a better response if you provide an example of what you're
doing, what you want to happen, and what is happening instead.

-z defs may be what you want.

-- 
Daniel Jacobowitz
CodeSourcery

Re: ld: how to force symbol resolution in shlibs on Linux

[skaller]

On Sat, 2006-03-04 at 20:42 -0500, Daniel Jacobowitz wrote:
> On Sun, Mar 05, 2006 at 02:06:32PM +1100, skaller wrote:
> > Hi, I have a problem trying to figure out if it even possible to force
> > linkage against shared libraries to resolve all 'user' symbols on Linux.
> > 
> > The option --[no-]allow-shlib-undefined controls this but seems useless
> > because it forces resolution of gcc compiler internal symbols related
> > to the GOT etc which must remain unresolved until runtime linkage.
> 
> Sorry, you're using phrases that don't accurately describe anything.

Ok, sorry! Here is an example:


skaller@budgie:/work/felix/flx$ cat g.c
void g(){}

skaller@budgie:/work/felix/flx$ cat f.c
extern void g();
void f(){ g(); }

skaller@budgie:/work/felix/flx$ gcc -shared -fPIC -o g.so g.c
skaller@budgie:/work/felix/flx$ gcc -shared -fPIC -o f.so f.c

It failed to report an unresolved symbol. Notice that
I forgot to link f.so against g.so like I should have!

Now watch this .. various experiments to make it work:

skaller@budgie:/work/felix/flx$ gcc -Wl,--no-allow-shlib-undefined
--shared -fPIC -o f.so f.c
/lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE'
/lib/libc.so.6: undefined reference to
`__libc_enable_secure@GLIBC_PRIVATE'/lib/libc.so.6: undefined reference
to `_rtld_global_ro@GLIBC_PRIVATE'
/lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE'
/lib/libc.so.6: undefined reference to `_r_debug@GLIBC_2.2.5'
/lib/libc.so.6: undefined reference to `__tls_get_addr@GLIBC_2.3'
/lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'

Argg... mess around.. finally:

skaller@budgie:/work/felix/flx$ gcc -Wl,--no-allow-shlib-undefined
--shared -fPIC -o f.so f.c /lib/ld-linux-x86-64.so.2

No error. Hopeless!! This is all wrong. And there is no way
I am going to name the loader like that in a portable
build script!

THIS is correct:

skaller@budgie:/work/felix/flx$ cat m.c
extern void g();
int main(){ g(); }

skaller@budgie:/work/felix/flx$ gcc -o m m.c
/tmp/ccKnJ1Xk.o: In function `main':
m.c:(.text+0xa): undefined reference to `g'
collect2: ld returned 1 exit status

except of course that's a mainline static link.
I want exactly the above result, which is the only
acceptable result for almost all application links,
whether building a shared library or not -- and it's
what I get with Cygwin, MinGW, and MSVC++. So my code
can build .. and even run .. on Linux, but fail on
other platforms (it can also fail on Linux .. at run
time, which is not desirable).

There is, of course, no guarantee with shared libraries
I won't drop in an incompatible version at run time,
and break everything.

With -z defs it still doesn't work:

skaller@budgie:/work/felix/flx$ gcc -z defs -shared -fPIC -o f.so f.c
-L. -lg
/tmp/cc83tWg8.o: In function `f':
f.c:(.text+0xa): undefined reference to `g'
collect2: ld returned 1 exit status

[There is no error -- -lg is specified this time :]

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net