Bug 148837 - /usr/bin/ld has problem finding library, -L search path set properly
/usr/bin/ld has problem finding library, -L search path set properly
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-15 20:10 EST by Marie
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-16 02:38:43 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)
X11 program used to in problem description (2.37 KB, text/plain)
2005-02-15 20:22 EST, Marie
no flags Details
Verbose output of gcc (2.06 KB, text/plain)
2005-02-15 20:25 EST, Marie
no flags Details

  None (edit)
Description Marie 2005-02-15 20:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041110 Firefox/1.0

Description of problem:
When compiling C programs on a FC3 64 bit architecture,
/usr/X11R6/lib/libX11.so.6 is not found by the linker even though it
exists and the -L directive is specified to include /usr/X11R6/lib in
the search path.



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

How reproducible:
Always

Steps to Reproduce:
1.  Have an X11 program ready.  A program hi.c is provided as an
attachment, but I suspect any old X program will do.

2.  gcc -o hi hi.c -L/usr/X11R6/lib -lX11
    

Actual Results:  /usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status


Expected Results:  program compiles :-)

Additional info:

The same program compiles without issue on a 32 bit FC2 machine. 
Thinking that perhaps it was a 64 bit library issue, I tried compiling
with 32 bits:

> gcc -m32 -o hi hi.c -L/usr/X11R6/lib -lX11
/usr/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status

Unless ld looks for crt1.o before the library, this would seem to
suggest that ld was able to find the library.  (If this is indeed the
case, suggestions on what package I need to install to support 32 bit
compilation would be appreciated.  32 bit compilation is better than
no compilation at all.)

In case it is somehow related to gcc, here are the versions of the gcc
rpms:

> rpm -q -a | grep gcc
libgcc-3.4.2-6.fc3
gcc-g77-3.4.2-6.fc3
libgcc-3.4.2-6.fc3
gcc-c++-3.4.2-6.fc3

gcc verbose output is provided as an attachment
Comment 1 Marie 2005-02-15 20:22:59 EST
Created attachment 111119 [details]
X11 program used to in problem description
Comment 2 Marie 2005-02-15 20:25:02 EST
Created attachment 111120 [details]
Verbose output of gcc
Comment 3 Jakub Jelinek 2005-02-16 02:38:43 EST
This is just misunderstanding how gcc and linker work.
Linker doesn't append any path suffixes to -L arguments based on the target
format and neither does gcc driver do that.
Linker just has target dependent list of default search directories (see
gcc -Wl,--verbose 2>&1 | grep SEARCH_DIR
gcc -m32 -Wl,--verbose 2>&1 | grep SEARCH_DIR
) and so does gcc driver.  Furthermore, when gcc driver searches for e.g.
crtfiles, it uses the multilib OS and GCC style path suffixes to find them.

So, if you want to link 64-bit program against X, you just pass
-L/usr/X11R6/lib64, as that's where the libraries really are.
Look at any of the X programs in the distro how they do that.
E.g.
gcc -print-multi-os-directory; gcc -m32 -print-multi-os-directory
shows you the OS path suffix that you can then append to /usr/X11R6/lib,
but there are many other options how to do that.

gcc -m32 -o hi hi.c -L/usr/X11R6/lib -lX11
failed for you because you don't have glibc-devel 32-bit package installed,
just 64-bit:
rpm -qf --qf '%{name}-%{version}-%{release}.%{arch}\n' /usr/lib{,64}/crt1.o
glibc-devel-2.3.4-2.fc3.i386
glibc-devel-2.3.4-2.fc3.x86_64
Install that (and maybe also xorg-x11-devel*.i386 too) and it will work.

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