Bug 156256 - ld produces invalid statically linked executable
ld produces invalid statically linked executable
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: binutils (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2005-04-28 10:52 EDT by Joshua Weage
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-29 08:08:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joshua Weage 2005-04-28 10:52:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
I am building an application using GNU autotools.  When I give libtool the -all-static option, it produces excutables that will not run.  On 7.3 this works fine.

The programs produce "command not found" when I try to execute them.

ldd produces:

/usr/lib/libc.so.1: bad ELF interpreter: No such file or directory

The above URL has another example of this problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Add -all-static to the LDFLAGS for an application

Actual Results:  Application does not execute

Additional info:
Comment 1 Jakub Jelinek 2005-04-28 10:59:38 EDT
This is not a linker bug, but user error.
ld shipped in the distro is not a Linux/i386 linker, but a generic ELF/i386
linker.  /usr/lib/ld.so.1 is the right default dynamic linker for it.
But nobody should ever use the linker directly unless he is prepared to deal
with all the necessary details to get a successful link.
ld is a low level tool, the gcc driver (or g++, etc.) is meant to be used
as a linker frontend and that takes care of passing the right -dynamic-linker
option and many other details.
Comment 2 Joshua Weage 2005-04-29 07:59:17 EDT
I am not using the linker directly.

The URL just happened to explain the problem I'm seeing when running GNU
autotools and libtool with the -all-static option.

Here are the compiler switches and output:

warpc4:/home/jweage/source/libtool% make
source='hello.cpp' object='hello.o' libtool=no \
depfile='.deps/hello.Po' tmpdepfile='.deps/hello.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
g++ -DPACKAGE_NAME=\"Hello\ World\" -DPACKAGE_TARNAME=\"hello\"
-DPACKAGE_VERSION=\"1.0.0\" -DPACKAGE_STRING=\"Hello\ World\ 1.0.0\"
-DPACKAGE_BUGREPORT=\"joshua.weage@arup.com\" -DPACKAGE=\"hello\"
-I.     -g -O2 -c -o hello.o `test -f 'hello.cpp' || echo './'`hello.cpp
/bin/sh ./libtool --mode=link g++  -g -O2  -L/usr/X11R6/lib  -o hello
-all-static   hello.o  -lFOX-1.2 -lpng -ltiff -ljpeg -lz -lXcursor -lXrender
-lXext -lX11
mkdir .libs
g++ -g -O2 -o hello -static hello.o  -L/usr/X11R6/lib /usr/lib/libFOX-1.2.a
-lpthread -lbz2 /usr/lib/libGL.so -ldl -lGLU -lpng -ltiff /usr/lib/libjpeg.a -lz
-lXcursor -lXrender -lXext -lX11
/usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x9f4): In function
: Using 'gethostbyname' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
/usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x7b0): In function
: Using 'getservbyname' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking

warpc4:/home/jweage/source/libtool% ldd hello
/usr/bin/ldd: ./hello: /usr/lib/libc.so.1: bad ELF interpreter: No such file or

When I remove the FOX-1.2 library, I no longer get the warnings about a shared
glibc being required at runtime and the application runs.  For some odd reason,
g++/ld is not using the correct dynamic linker.
Comment 3 Jakub Jelinek 2005-04-29 08:08:37 EDT
g++ -g -O2 -o hello -static hello.o  -L/usr/X11R6/lib /usr/lib/libFOX-1.2.a
-lpthread -lbz2 /usr/lib/libGL.so -ldl -lGLU -lpng -ltiff /usr/lib/libjpeg.a -lz
-lXcursor -lXrender -lXext -lX11

is bogus.  When you are linking statically, you must never link against
any shared libraries obviously.  -lXXX works because the linker chooses if
it will pick a shared library or ar archive, in -static case always
just ar archive  and if it doesn't exist, complain and fail.
But you are forcing it to use /usr/lib/libGL.so, which is a shared library.

You need to use either /usr/lib/libGL.a or -lGL.

From the ordering of the command line, it looks like this comes from
libFOX-1.2.la, so the bug would be there.  But AFAIK this is not something
shipped in the distro.

Alternatively, you can link the program dynamically, i.e. remove the -all-static
option for libtool.
Comment 4 Joshua Weage 2005-04-29 16:43:15 EDT
Thanks for the response.  I didn't notice that before.  The g++ command is
executed by libtool, so libtool is adding libGL.so and GLU on its own.  I will
take this up with the libtool authors.

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