4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

Mark:

I cannot build and use (link, etc.) 64-bit shared libraries on  
powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615  
(prerelease).  This is a regression from 4.0.0 on the same platform.

I couldn't come up with a short example, sorry, but it is easy to  
reproduce if you have the right hardware/software combo (G5 with  
Xcode 2.1 on MacOS X 10.4.1).

This was assigned

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Andrew Pinski]

On Jun 15, 2005, at 2:19 PM, Bradley Lucier wrote:

> Mark:
>
> I cannot build and use (link, etc.) 64-bit shared libraries on 
> powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 
> (prerelease).  This is a regression from 4.0.0 on the same platform.

This is not a regression, in fact in the last couple days before 4.0.0 
was released,
multilib support for the 64bit shared libraries was turned off.

-- Pinski

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Jun 15, 2005, at 1:26 PM, Andrew Pinski wrote:

>
> On Jun 15, 2005, at 2:19 PM, Bradley Lucier wrote:
>
>
>> Mark:
>>
>> I cannot build and use (link, etc.) 64-bit shared libraries on  
>> powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615  
>> (prerelease).  This is a regression from 4.0.0 on the same platform.
>>
>
> This is not a regression, in fact in the last couple days before  
> 4.0.0 was released,
> multilib support for the 64bit shared libraries was turned off.

???.  It works just fine with

[descartes:~/programs/gambc40b13] lucier% /pkgs/gcc-4.0.0/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0.0 --with-gmp=/ 
pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.0

So why you say it's not a regression, I don't know.

And 4.0.0 is now the *only* version of gcc that will compile Gambit-C  
correctly;

[descartes:~/programs/gambc40b13] lucier% /pkgs/gcc-4.0.0-apple/bin/ 
gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0.0-apple --with- 
gmp=/pkgs/gmp-4.1.4 --with-mpfr=/pkgs/gmp-4.1.4 --enable-languages=c,c 
++,f95
Thread model: posix
gcc version 4.0.0 (Apple Computer, Inc. build 5018)

gives me the same error; the Xcode 2.0 gcc compiler was a POS; and with

[descartes:~/programs/gambc40b13] lucier% /usr/bin/gcc -v
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)

I get

[descartes:~/programs/gambc40b13] lucier% gsi
Illegal instruction

The last two are not the FSF gcc team's problem, of course, but why  
go from a compiler that works on PowerPC darwin to one that doesn't I  
don't know.

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Mike Stump]

On Wednesday, June 15, 2005, at 11:19  AM, Bradley Lucier wrote:
> I cannot build and use (link, etc.) 64-bit shared libraries on 
> powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 > (prerelease).

If you remove the # that comment out the -m64 multilibs, does it then 
work perfectly?  If so, then, that is the solution to make it work, you 
just won't be able to do java (not that you care).

Also, I do wonder if there was a specs files that is polluting your 
gcc-4.0.0 build, to check that, if you want, you can install in a new 
prefix directory, and then see if it remains working.

Anyway, while this is a regression for you, we meant for gcc-4.0.0 to 
not work for -m64, so I would not expect that it'll work for 4.0.1.   
:-(.

I'm sorry libjava and -m64 didn't get along well enough to turn -m64 
multilibbing on, I tried, but failed.  :-(

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Jun 15, 2005, at 7:12 PM, Mike Stump wrote:

> On Wednesday, June 15, 2005, at 11:19  AM, Bradley Lucier wrote:
>> I cannot build and use (link, etc.) 64-bit shared libraries on 
>> powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 > 
>> (prerelease).
>
> If you remove the # that comment out the -m64 multilibs, does it then 
> work perfectly?  If so, then, that is the solution to make it work, 
> you just won't be able to do java (not that you care).

Thank you for your reply.  I plan to test mainline after removing the 
#'s.

> Also, I do wonder if there was a specs files that is polluting your 
> gcc-4.0.0 build, to check that, if you want, you can install in a new 
> prefix directory, and then see if it remains working.

Yes, it does.  I did that this afternoon.  There is a rather long 
exchange between me and Andrew in the bug report.  I don't know why it 
works, but it does.  Perhaps you might know how one can have a shared 
library for which otool64 doesn't report a link to libgcc_s.

> Anyway, while this is a regression for you, we meant for gcc-4.0.0 to 
> not work for -m64, so I would not expect that it'll work for 4.0.1.   
> :-(.

I understand now that -m64 was not meant to work with Darwin.  I didn't 
realize this before, tried it, and was happy when it worked.

I've found the discussion about 64-bit java not working, beginning at

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02396.html

The reasons given for disabling ppc64 multilib instead of java on 
darwin were

> - it involves changing configury that affects every darwin target, not
>   just darwin8
> - I think that people using FSF GCC are more likely to want to use gcj
>   than 64-bit, since they can use Apple's compiler for 64-bit but not
>   for gcj
> - java worked for 3.4, but ppc64 didn't

I think the second justification was a mistake.  In my opinion, the FSF 
shouldn't be asking people to rely on a company's compiler for certain 
features (64-bit support).  And Apple's 64-bit support in both Xcode 
2.0 and Xcode 2.1 has been broken for me.  I wasn't terribly worried 
since FSF gcc-4.0.0 seemed to work.

It's not clear to me that the third reason was persuasive, either.  
Fortran worked on 3.4, but not on 4.0.0.  It's a matter of what one 
decides one has to break.

Would it be possible to disable multilib by default on Darwin 8, but 
leave it as a configure option? Then one could

./configure --prefix=/pkgs/gcc-4.0.0
make bootstrap
make install

to build a complete 32-bit compiler suite and

./configure --enable-multilib --enable-languages=c,c++,objc,objc++,f95

to build 64-bit versions of languages except java and ada.

It would be good if 64-bit applications got tested in the FSF gcc tree 
for darwin, too.

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Mike Stump]

On Wednesday, June 15, 2005, at 06:37  PM, Bradley Lucier wrote:
> The reasons given for disabling ppc64 multilib instead of java on 
> darwin were

I think it might be possible to use GNU make to setup the MULTILIB 
options depending upon wether or not LANGUAGES (CONFIG_LANGUAGES) 
includes java.  Include java, no multilib, don't include it, and 
multilib.  Please try something like:

Doing diffs in .:
--- ./config/rs6000/t-darwin8.~1~       2005-04-07 15:58:23.000000000 
-0700
+++ ./config/rs6000/t-darwin8   2005-06-15 23:14:38.000000000 -0700
@@ -1,5 +1,10 @@
  # 64-bit libraries can only be built in Darwin 8.x or later.
  # Unfortunately, though, libjava and libffi haven't been ported to -m64
  # yet.
+ifneq (,$(findstring java, $(CONFIG_LANGUAGES)))
  # MULTILIB_OPTIONS = m64
  # MULTILIB_DIRNAMES = ppc64
+else
+MULTILIB_OPTIONS = m64
+MULTILIB_DIRNAMES = ppc64
+endif
--------------

and let me know if it works.  Quick testing indicates it should.  I'll 
test the java version of it to ensure that it doesn't break the 
bootstrap.  If both builds work, we can ask if anyone else knows of a 
reason the above would be bad.  If not, we can put this into mainline.  
 From there, we can push for it to make it into 4.0.x.

Sound ok?

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Jun 16, 2005, at 1:30 AM, Mike Stump wrote:

>  Please try something like:
> ...
> and let me know if it works.

Thank you, I will try it today.

Last night I unconditionally allowed multilibs and configured with

Compiler version: 4.1.0 20050615 (experimental)
Platform: powerpc-apple-darwin8.1.0
configure flags: --prefix=/pkgs/gcc-4.0-mainline  
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3  
--enable-languages=c,c++,f95,objc,obj-c++
BOOT_CFLAGS=-g -O2 -mdynamic-no-pic

There were many -m64 failures in some of the testsuites; e.g.,

                 === g++ Summary for unix/-m64 ===

# of expected passes            8438
# of unexpected failures        1370
# of expected failures          60
# of unresolved testcases       68
# of unsupported tests          114
...
                 === gfortran Summary for unix/-m64 ===

# of expected passes            517
# of unexpected failures        3320
# of unexpected successes       3
# of expected failures          9
# of untested testcases         1472
# of unsupported tests          17
...
                 === objc Summary for unix/-m64 ===

# of expected passes            493
# of unexpected failures        576
# of unresolved testcases       533
# of unsupported tests          1

It seems that the 64-bit libgcc_s can't be found many times; a typical  
failure from the top of the c++ test suite looks like

Test Run By lucier on Wed Jun 15 21:35:15 2005
Native configuration is powerpc-apple-darwin8.1.0

                 === g++ tests ===

Schedule of variations:
     unix/-m64
     unix

Running target unix/-m64
Using /pkgs/dejagnu/share/dejagnu/baseboards/unix.exp as board  
description file for target.
Using /pkgs/dejagnu/share/dejagnu/config/unix.exp as generic interface  
file for target.
Using  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/config/ 
default.exp as tool-and-target-specific interface file.
Running  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/g++.dg/bprob/ 
bprob.exp ...
set_ld_library_path_env_vars:  
ld_library_path=.:/Users/lucier/programs/gcc/gcc-mainline/objdir/ 
powerpc-apple-darwin8.1.0/ppc64/libstdc++-v3/src/.libs:/Users/lucier/ 
programs/gcc/gcc-mainline/objdir/gcc
ALWAYS_CXXFLAGS set to {additional_flags=-nostdinc++  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include/powerpc-apple-darwin8.1.0  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite}  
{ldflags=  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/src/.libs  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libiberty } additional_flags=-fmessage-length=0  
{ldflags=-multiply_defined suppress}
Executing on host:  
/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../g++  
-B/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/g++.dg/bprob/g++- 
bprob-1.C  -nostdinc++  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include/powerpc-apple-darwin8.1.0  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite  
-fmessage-length=0  -g   -fprofile-arcs     
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/src/.libs  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libiberty  -multiply_defined suppress -lm   -m64 -o  
/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/g++-bprob 
-1.x01    (timeout = 300)
ld64 failed: library not found for -lgcc_s_ppc64^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld64 failed: library not found for -lgcc_s_ppc64^M
collect2: ld returned 1 exit status^M

even though

[descartes:gcc/gcc-mainline/objdir] lucier% find . -name 'libgcc_s*'
./gcc/libgcc_s.1.0.dylib
./gcc/libgcc_s.1.0.dylib.backup
./gcc/libgcc_s.dylib
./gcc/libgcc_s_ppc64.1.0.dylib
./gcc/libgcc_s_ppc64.1.0.dylib.backup
./gcc/libgcc_s_ppc64.dylib
...

Is the testsuite failing to set up to set the DYLD_LIBRARY_PATH  
appropriately?

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Mike Stump]

On Jun 16, 2005, at 10:04 AM, Bradley Lucier wrote:
> On Jun 16, 2005, at 1:30 AM, Mike Stump wrote:
>>  Please try something like:
>> ...
>> and let me know if it works.
>
> Thank you, I will try it today.

Actually, by try, I meant try your application.  :-)

> Last night I unconditionally allowed multilibs and configured with

> ld64 failed: library not found for -lgcc_s_ppc64

:-(

> Is the testsuite failing to set up to set the DYLD_LIBRARY_PATH  
> appropriately?

Don't worry about this, I think this won't hit the use of the tool,  
only the testing of the tool.

I see can't find share library problems on mainline on linux as well,  
so, certainly, there are issues there that have yet to be fixed.

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

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)

Perhaps someone moved libgcc_s_ppc64.1.0.dylib but didn't change the  
script that builds the libtool command line to tell libtool where to  
find it?

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Jun 16, 2005, at 3:06 PM, Mike Stump wrote:

> Actually, by try, I meant try your application.  :-)

I can't seem to build any 64-bit shared library on powerpc-apple- 
darwin8.1.0, although I can now run the test suite more effectively; see

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110

and

http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01124.html

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Mike Stump]

On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote:
> I can't seem to build any 64-bit shared library on powerpc-apple- 
> darwin8.1.0, although I can now run the test suite more  
> effectively; see
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
>
> and
>
> http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01124.html

So, I thought I'd ping you and see if everything is nearer to normal  
now.

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Dec 16, 2005, at 6:23 PM, Mike Stump wrote:

> On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote:
>> I can't seem to build any 64-bit shared library on powerpc-apple- 
>> darwin8.1.0, although I can now run the test suite more  
>> effectively; see
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
>>
>> and
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01124.html
>
> So, I thought I'd ping you and see if everything is nearer to  
> normal now.

Thanks!  Unfortunately not.

Geoff thinks that not being able to build a 64-bit shared library is  
a libtool problem; the discussion seems to have ended in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082

Unfortunately, even with my Apple Developer account I can't seem to  
figure out how to look up radar reports that I haven't submitted.

And there seem to be a large number of 64-bit failures in the 4.1  
test suite; the results from the 10th can be found at

http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-12-10-2005.gz

About my earlier e-mail regarding the test results on the 6th:

http://gcc.gnu.org/ml/gcc/2005-12/msg00182.html

Geoff commented:

http://gcc.gnu.org/ml/java/2005-12/msg00093.html

Brad

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Eric Christopher]

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
>
> Unfortunately, even with my Apple Developer account I can't seem to  
> figure out how to look up radar reports that I haven't submitted.

I took a look at the radar. Says, effectively, that the bug has been  
fixed in ld64 and will be in the next release.

-eric

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Dec 16, 2005, at 8:25 PM, Eric Christopher wrote:

>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
>>
>> Unfortunately, even with my Apple Developer account I can't seem  
>> to figure out how to look up radar reports that I haven't submitted.
>
> I took a look at the radar. Says, effectively, that the bug has  
> been fixed in ld64 and will be in the next release.

Great!  Thanks.

Brad