Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156256 - ld produces invalid statically linked executable
Summary: ld produces invalid statically linked executable
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: binutils
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-28 14:52 UTC by Joshua Weage
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-29 12:08:37 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Joshua Weage 2005-04-28 14:52:05 UTC
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/ 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 14:59:38 UTC
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/ 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 11:59:17 UTC
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\"
-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/ -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/ 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 12:08:37 UTC
g++ -g -O2 -o hello -static hello.o  -L/usr/X11R6/lib /usr/lib/libFOX-1.2.a
-lpthread -lbz2 /usr/lib/ -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/, 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, 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 20:43:15 UTC
Thanks for the response.  I didn't notice that before.  The g++ command is
executed by libtool, so libtool is adding 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.