Bug 17133 - ld (Linker) '-static' option less then helpful on Solaris
ld (Linker) '-static' option less then helpful on Solaris
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: binutils (Show other bugs)
6.2
sparc Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-31 11:02 EDT by kestes
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-11 12:13:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kestes 2000-08-31 11:02:48 EDT
It is very difficult to remove any lib shared library dependencies on
solaris.  While compiling the RPM sources on Solaris I wished to
ensure my resulting executable was not dependent on there being a libz
or berkeley DB installed on the system.  One of my problems in
compiling this was the linker options. (Other bug tickets are being
opended with libtool and automake which caused other 'obvious'
solutions to not work as well)

The -static LDFLAG is interpred that the resulting binary
MUST be static.  It would be far more useful if the linkerdid its best
to create a static binary.  I wish to adjust this seach order for some
of my compilations:

>    Specifically, on ELF and SunOS systems, `ld' will search a directory
>    for a library with an extension of `.so' before searching for one
>    with an extension of `.a'.



Here is an example of my problems:


      1) If I add '-static' to LDFLAGS I get an error:

      make LDFLAGS="-static"

      /bin/sh ../libtool --mode=link gcc  -O2 -D_GNU_SOURCE -Wall
-Wpointer-arith
      -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -static
-o dump 
      dump.o ../build/librpmbuild.la       ../lib/librpm.la       
      ../rpmio/librpmio.la    ../popt/libpopt.la       
      mkdir .libs
      gcc -O2 -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes
      -Wmissing-prototypes -Wno-char-subscripts -o dump dump.o
      ../build/.libs/librpmbuild.a ../lib/.libs/librpm.a -ldb-3.1
      ../rpmio/.libs/librpmio.a -L/usr/local/lib -L/usr/ucblib -lnsl
-lsocket -lz
      ../popt/.libs/libpopt.a -R/usr/local/lib -R/usr/ucblib
-R/usr/local/lib
      -R/usr/ucblib
      Undefined                       first referenced
       symbol                             in file
      stpcpy                             
../rpmio/.libs/librpmio.a(rpmio.o)
      ld: fatal: Symbol referencing errors. No output written to dump


      2) If I use 

      make LDFLAGS="'-Wl,-Bstatic'"


      /bin/sh ../libtool --mode=link gcc  -O2 -D_GNU_SOURCE -Wall
-Wpointer-arith
      -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts
'-Wl,-Bstatic' -o
      dump  dump.o ../build/librpmbuild.la        ../lib/librpm.la       
      ../rpmio/librpmio.la    ../popt/libpopt.la       
      mkdir .libs
      gcc -O2 -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes
      -Wmissing-prototypes -Wno-char-subscripts -Wl,-Bstatic -o .libs/dump
dump.o
      ../build/.libs/librpmbuild.so ../lib/.libs/librpm.so -ldb-3.1
      ../rpmio/.libs/librpmio.so -L/usr/local/lib -L/usr/ucblib -lnsl
-lsocket -lz
      ../popt/.libs/libpopt.so -R/usr/local/lib -R/usr/ucblib
      ld: fatal: input of shared object `../build/.libs/librpmbuild.so' in
static mode
      ld: fatal: input of shared object `../lib/.libs/librpm.so' in static
mode
      ld: fatal: input of shared object `../rpmio/.libs/librpmio.so' in
static mode
      ld: fatal: input of shared object `../popt/.libs/libpopt.so' in
static mode
      ld: fatal: File processing errors. No output written to .libs/dump
      make[2]: *** [dump] Error 1
Comment 1 Bill Nottingham 2000-08-31 18:12:34 EDT
Is this the gcc linker on Solaris, or Sun's?

Obviously, we can't do much about Sun's compiler. :)
Comment 2 kestes 2000-08-31 18:22:14 EDT
I believe it is GNU linker.  Definiatly GCC.  To be honest it is really
hard to tell what linker GCC is using or to set the linker properly when
compiling. I have had major headaches compiling CGG so I may have a version
which using the sun linker.

Comment 3 Jakub Jelinek 2000-09-01 04:57:32 EDT
ld's -static affects all libraries and the resulting binary present on the
command line, while -Bstatic and -Bdynamic is position dependent and you can just
surround all occurences of -lz and -ldb* with -Wl,-Bstatic and -Wl,-Bdynamic.
Alternatively, you can also replace -lz with full_path_to_your_libz_a/libz.a
and similarly with the DB libraries, then that particular library will be linked
in statically while the rest will be a dynamically linked application.
I'm closing this because this is certainly not a bug in either binutils nor
gcc.
Comment 4 kestes 2000-09-01 08:45:06 EDT
I understand why you closed this ticket.  Unfoturnatly there is some very
poor interaction between libtool and ld because of the Solaris shared library
model.  Your suggestion just does not work in the context I need it to
(see 
     http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=16381
     Additional comments from kestes@staff.mail.com 2000-08-17 12:17
)
The problem for me as a user is that both the libtool people and the ld
people can easily complain that the bug is in the others tool.  I opened a bug
in both tools hoping someone would see that there was a reasonable fix
in some tool.  Now both tickets are closed and there are no fixes coming.


Why is it so hard to get gcc to tell me what linker it uses?



Note You need to log in before you can comment on or make changes to this bug.