Bug 22110 - Wrong ld search paths passed to libtool for 64-bit compiles
Summary: Wrong ld search paths passed to libtool for 64-bit compiles
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-18 04:52 UTC by lucier
Modified: 2006-11-09 23:47 UTC (History)
1 user (show)

See Also:
Host: powerpc-apple-darwin8.1.0
Target: powerpc-apple-darwin8.1.0
Build: powerpc-apple-darwin8.1.0
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lucier 2005-06-18 04:52:49 UTC
It seems that the libtool command line may be wrong.  Here's a simple test.

[descartes:~/programs] lucier% cat conftest.c
int main2() { return 0;}
[descartes:~/programs] lucier% gcc -m64 -mcpu=970 -o conftest -dynamiclib
conftest.c -v -save-temps
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0-mainline
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
--enable-languages=c,c++,objc,obj-c++,f95
Thread model: posix
gcc version 4.1.0 20050615 (experimental)
 /pkgs/gcc-4.0-mainline/libexec/gcc/powerpc-apple-darwin8.1.0/4.1.0/cc1 -E
-quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -m64 -mcpu=970
-fpch-preprocess -o conftest.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../../../powerpc-apple-darwin8.1.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /pkgs/gcc-4.0-mainline/include
 /pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
 /pkgs/gcc-4.0-mainline/libexec/gcc/powerpc-apple-darwin8.1.0/4.1.0/cc1
-fpreprocessed conftest.i -fPIC -quiet -dumpbase conftest.c -m64 -mcpu=970
-auxbase conftest -version -o conftest.s
GNU C version 4.1.0 20050615 (experimental) (powerpc-apple-darwin8.1.0)
        compiled by GNU C version 4.1.0 20050615 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 856564be1b7d2e1a3d0c80ce3c26789d
 as -arch ppc64 -o conftest.o conftest.s
 /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load
-weak_reference_mismatches non-weak -o conftest
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/ppc64
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../../ppc64
conftest.o -lgcc_s_ppc64 -lgcc -lSystemStubs -lmx -lSystem
/usr/bin/libtool: can't locate file for: -lgcc_s_ppc64
/usr/bin/libtool: file: -lgcc_s_ppc64 is not an object file (not allowed in a
library)

However, if I add by hand /pkgs/gcc-4.0-mainline/lib, where
libgcc_s_ppc64.1.0.dylib is installed, to the link path to libtool, I get

[descartes:~/programs] lucier% /usr/bin/libtool -dynamic -arch_only ppc64
-noall_load -weak_reference_mismatches non-weak -o conftest
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/ppc64
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../../ppc64
conftest.o -lgcc_s_ppc64 -lgcc -lSystemStubs -lmx -lSystem
-L/pkgs/gcc-4.0-mainline/lib
[descartes:~/programs] lucier% file conftest
conftest: Mach-O 64-bit dynamically linked shared library ppc64
[descartes:~/programs] lucier% otool64 -L conftest
conftest:
        conftest (compatibility version 0.0.0, current version 0.0.0)
        /pkgs/gcc-4.0-mainline/lib/libgcc_s_ppc64.1.0.dylib (compatibility
version 1.0.0, current version 1.0.0)
        /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.0.0)

Compare the libtool command line from Xcode 2.1's gcc:

[descartes:~/programs] lucier% /usr/bin/!!
/usr/bin/gcc -m64 -mcpu=970 -o conftest -dynamiclib conftest.c -v -save-temps
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/configure
--disable-checking --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^+.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/gcc/darwin/4.0/c++ --build=powerpc-apple-darwin8
--host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.0 (Apple Computer, Inc. build 5026)
 /usr/libexec/gcc/powerpc-apple-darwin8/4.0.0/cc1 -E -quiet -v -D__DYNAMIC__
conftest.c -fPIC -m64 -mcpu=970 -fpch-preprocess -o conftest.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../../../powerpc-apple-darwin8/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
 /usr/libexec/gcc/powerpc-apple-darwin8/4.0.0/cc1 -fpreprocessed conftest.i
-fPIC -quiet -dumpbase conftest.c -m64 -mcpu=970 -auxbase conftest -version -o
conftest.s
GNU C version 4.0.0 (Apple Computer, Inc. build 5026) (powerpc-apple-darwin8)
        compiled by GNU C version 4.0.0 (Apple Computer, Inc. build 5026).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -arch ppc64 -o conftest.o conftest.s
 /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load
-weak_reference_mismatches non-weak -o conftest
-L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/ppc64
-L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0
-L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/ppc64
-L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0
-L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../.. conftest.o -lgcc_s_ppc64
-lgcc -lSystemStubs -lmx -lSystem

In fact, libgcc_s_ppc64 is in 

$prefix/lib/gcc/powerpc-apple-darwin8.1/4.1.0/../../..

not

$prefix/lib/gcc/powerpc-apple-darwin8.1/4.1.0/../../../ppc64

I have no clue about how to change the search paths for libtool.
Comment 1 lucier 2005-06-18 04:53:42 UTC
I re-enabled 64-bit multilib before building and installing gcc.
Comment 2 lucier 2005-06-18 19:37:22 UTC
This is fixed in today's cvs sources, perhaps because of

http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00681.html
Comment 3 lucier 2005-06-19 02:02:23 UTC
This is a simple patch that can and probably should be back-ported to 4.0.2
after the 4.0 branch is re-opened.

It seems that I probably made a mistake when I marked it resolved.  It is still
open on the 4.0 branch, I think.
Comment 4 lucier 2005-06-19 02:21:41 UTC
Well, I made more than one mistake today.

While Geoff's patch allows gcc to find libgcc_s_ppc64.dylib when running the
test suite, the installed compiler can't seem to find this library when trying
to build an executable.

So I'm re-opening the bug.  Sorry for the confusion.
Comment 5 Andrew Pinski 2006-11-09 23:47:16 UTC
This was a bug in cctools.