Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Lars Sonchocky-Helldorf]

I tried to bootstrap gcc-4.0-20040919 on powerpc-apple-darwin6.8:

I installed cctools-528 and then:

mkdir gcc-build
cd gcc-build/
../gcc-4.0-20040919/configure --prefix=/tmp/gcc
make bootstrap STAGE1_CFLAGS="-no-cpp-precomp -Wa,-force_cpusubtype_ALL"


It all stops here:

/bin/sh ./libtool --tag=CXX --mode=link  
/Volumes/Data/Projekte/GCC/FSF/gcc-build/gcc/xgcc -shared-libgcc  
-B/Volumes/Data/Projekte/GCC/FSF/gcc-build/gcc/ -nostdinc++  
-L/Volumes/Data/Projekte/GCC/FSF/gcc-build/powerpc-apple-darwin6.8/ 
libstdc++-v3/src  
-L/Volumes/Data/Projekte/GCC/FSF/gcc-build/powerpc-apple-darwin6.8/ 
libstdc++-v3/src/.libs -B/tmp/gcc/powerpc-apple-darwin6.8/bin/  
-B/tmp/gcc/powerpc-apple-darwin6.8/lib/ -isystem  
/tmp/gcc/powerpc-apple-darwin6.8/include -isystem  
/tmp/gcc/powerpc-apple-darwin6.8/sys-include  
-L/Volumes/Data/Projekte/GCC/FSF/gcc-build/powerpc-apple-darwin6.8/ 
libjava -g -O2  -o libgcj.la -rpath /tmp/gcc/lib -rpath /tmp/gcc/lib   
-lpthread ./libltdl/libltdlc.la  -version-info `grep -v '^#'  
../../../gcc-4.0-20040919/libjava/libtool-version` prims.lo jni.lo  
exception.lo resolve.lo defineclass.lo interpret.lo verify.lo  
gnu/gcj/natCore.lo gnu/gcj/convert/JIS0208_to_Unicode.lo
.
[73317 chars deleted]
.
javax/transaction/TransactionRolledbackException.lo  
javax/transaction/UserTransaction.lo java/lang/ConcreteProcess.lo  
gnu/classpath/Configuration.lo boehm.lo   posix.lo   posix-threads.lo    
../libffi/libffi_convenience.la ../zlib/libzgcj_convenience.la  
../boehm-gc/libgcjgc_convenience.la  
gnu/regexp/MessagesBundle.properties.lo  
gnu/regexp/MessagesBundle_fr.properties.lo
make[3]: execvp: /bin/sh: Argument list too long
make[3]: *** [libgcj.la] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-target-libjava] Error 2
make: *** [bootstrap] Error 2
[Lars-Sonchocky-Helldorfs-Computer:GCC/FSF/gcc-build] lars%

Is there some trick to avoid that error?

TIA, Lars

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Andrew Pinski]

On Sep 22, 2004, at 2:45 PM, Lars Sonchocky-Helldorf wrote:

> I tried to bootstrap gcc-4.0-20040919 on powerpc-apple-darwin6.8:
>
> I installed cctools-528 and 
> then:javax/transaction/TransactionRolledbackException.lo 
> javax/transaction/UserTransaction.lo java/lang/ConcreteProcess.lo 
> gnu/classpath/Configuration.lo boehm.lo   posix.lo   posix-threads.lo  
>  ../libffi/libffi_convenience.la ../zlib/libzgcj_convenience.la 
> ../boehm-gc/libgcjgc_convenience.la 
> gnu/regexp/MessagesBundle.properties.lo 
> gnu/regexp/MessagesBundle_fr.properties.lo
> make[3]: execvp: /bin/sh: Argument list too long
> make[3]: *** [libgcj.la] Error 127


Yes disable the java language as it is almost not usable on darwin6.x 
anyways.
This is a bug in the kernel or the sh which darwin6.x uses.


Thanks,
Andrew Pinski

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Kelley Cook]

Andrew Pinski wrote:

> 
> On Sep 22, 2004, at 2:45 PM, Lars Sonchocky-Helldorf wrote:
> 
...
>> gnu/regexp/MessagesBundle_fr.properties.lo
>> make[3]: execvp: /bin/sh: Argument list too long
>> make[3]: *** [libgcj.la] Error 127
> 
> Yes disable the java language as it is almost not usable on darwin6.x 
> anyways.  This is a bug in the kernel or the sh which darwin6.x uses.
> 

Respectfully, I disagree with the final statement.

I believe that it is unreasonable to assume that a shell can handle a 
line length of 70,000+ characters.

Note that this bug also occurs under Cygwin (upon which libgcj is also 
pretty much unuseable).

It is PR libgcj/17222.

Kelley Cook

RE: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Kelley Cook
> Sent: 23 September 2004 12:54
> To: Andrew Pinski; Lars Sonchocky-Helldorf

> Andrew Pinski wrote:
> 
> > 
> > On Sep 22, 2004, at 2:45 PM, Lars Sonchocky-Helldorf wrote:
> > 
> ...
> >> gnu/regexp/MessagesBundle_fr.properties.lo
> >> make[3]: execvp: /bin/sh: Argument list too long
> >> make[3]: *** [libgcj.la] Error 127
> > 
> > Yes disable the java language as it is almost not usable on 
> darwin6.x 
> > anyways.  This is a bug in the kernel or the sh which 
> darwin6.x uses.
> > 
> 
> Respectfully, I disagree with the final statement.
> 
> I believe that it is unreasonable to assume that a shell can handle a 
> line length of 70,000+ characters.
> 
> Note that this bug also occurs under Cygwin (upon which 
> libgcj is also pretty much unuseable).


  Although I kind of feel the same, that it's asking an awful lot of a
shell, and in particular of the cygwin shell, which has to live with certain
limits imposed on it by the underlying OS, the POSIX spec suggests that it
ought to be acceptable:

http://www.opengroup.org/onlinepubs/009695399/idx/shell.html

"  2.3 Token Recognition
The shell shall read its input in terms of lines from a file, from a
terminal in the case of an interactive shell, or from a string in the case
of sh -c or system(). The input lines can be of unlimited length. "


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Andreas Schwab]

Kelley Cook <kcook@gcc.gnu.org> writes:

> Andrew Pinski wrote:
>
>> On Sep 22, 2004, at 2:45 PM, Lars Sonchocky-Helldorf wrote:
>> 
> ...
>>> gnu/regexp/MessagesBundle_fr.properties.lo
>>> make[3]: execvp: /bin/sh: Argument list too long
>>> make[3]: *** [libgcj.la] Error 127
>> Yes disable the java language as it is almost not usable on darwin6.x
>> anyways.  This is a bug in the kernel or the sh which darwin6.x uses.
>> 
>
> Respectfully, I disagree with the final statement.
>
> I believe that it is unreasonable to assume that a shell can handle a line
> length of 70,000+ characters.

Not that in the case above the shell hasn't even been started yet, the
kernel refused to execute it in the first place.  Shells that have command
line length limits independent of the kernel are long being dying already.
Modern shells have no such limit.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Andrew Haley]

Dave Korn writes:
 > > I believe that it is unreasonable to assume that a shell can handle a 
 > > line length of 70,000+ characters.
 > > 
 > > Note that this bug also occurs under Cygwin (upon which 
 > > libgcj is also pretty much unuseable).
 > 
 > 
 >   Although I kind of feel the same, that it's asking an awful lot of a
 > shell, and in particular of the cygwin shell, which has to live with certain
 > limits imposed on it by the underlying OS, the POSIX spec suggests that it
 > ought to be acceptable:
 > 
 > http://www.opengroup.org/onlinepubs/009695399/idx/shell.html
 > 
 > "  2.3 Token Recognition
 > The shell shall read its input in terms of lines from a file, from a
 > terminal in the case of an interactive shell, or from a string in the case
 > of sh -c or system(). The input lines can be of unlimited length. "

But this doesn't really matter, because although the shell may be able
to read very long lines, there's no reason to suggest that the linker
will be able to handle them.  We need to fix this bug, one way or
another.

Andrew.

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Peter O'Gorman]

Andrew Haley wrote:


> But this doesn't really matter, because although the shell may be able
> to read very long lines, there's no reason to suggest that the linker
> will be able to handle them.  We need to fix this bug, one way or
> another.

As far as I know the kernel on Mac OS X 10.2 and earlier supported 64KB 
command lines 10.3 supports 256KB.

There is code in GNU libtool to shorten overly long command lines using ld 
-r, or use a linker script if using GNU ld, this should probably be taken 
into gcc, along with proper command line length checking.

Peter
-- 
Peter O'Gorman - http://www.pogma.com

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Peter O'Gorman]

Peter O'Gorman wrote:

> As far as I know the kernel on Mac OS X 10.2 and earlier supported 64KB 
> command lines 10.3 supports 256KB.
> 
> There is code in GNU libtool to shorten overly long command lines using 
> ld -r, or use a linker script if using GNU ld, this should probably be 
> taken into gcc, along with proper command line length checking.

(hittimg myself on the head)

Of course it dies trying to run the libtool script because there are simply 
too many files, so I'll run away in embarrassment.

Sorry,
Peter

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Peter O'Gorman]

Peter O'Gorman wrote:


> Of course it dies trying to run the libtool script because there are 
> simply too many files, so I'll run away in embarrassment.

The really annoying thing about this one is that it was fixed in 2001 but 
was unfixed again here:

2004-08-19  Thomas Fitzsimmons  <fitzsim@redhat.com>
             Michael Koch  <konqueror@gmx.de>

         * configure.in,
         Makefile.am: Ported to automake 1.9.
         * Makefile.in:
         aclocal.m4
         configure
         gcj/Makefile.in
         include/Makefile.in
         testsuite/Makefile.in
         include/config.h.in:
         Regenerated.
         * gcc/doc/install.texi: Update entry about automake for libjava.

Part of the diff is here:

-## Pass the list of object files to libtool in a temporary file to
-## avoid tripping platform command line length limits.
-libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
-	@echo Creating list of files to link...
-	@: $(call write_entries_to_file,$(libgcj_la_OBJECTS) 
$(libgcj_la_LIBADD),libgcj.objectlist)
-	$(libgcj_la_LINK) -objectlist libgcj.objectlist \
-	@GCLIBS@ @LIBFFI@ @ZLIBS@ \
-	-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
-

The libgcj.la target was there to override what automake would put in so 
that the -objectlist flag would be used to call libtool which could then 
deal appropriately with the extra long argument list.

Peter
-- 
Peter O'Gorman - http://www.pogma.com

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Tom Tromey]

>>>>> "Peter" == Peter O'Gorman <peter@pogma.com> writes:

Peter> The really annoying thing about this one is that it was fixed in 2001
Peter> but was unfixed again here:

Peter> Part of the diff is here:
Peter> [ ... ]

Could you try putting that code back and seeing if it helps?
If so I'll check it in.

Tom

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Peter O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Tom Tromey wrote:

>>>>>>"Peter" == Peter O'Gorman <peter@pogma.com> writes:
> 
> 
> Peter> The really annoying thing about this one is that it was fixed in 2001
> Peter> but was unfixed again here:
> 
> Peter> Part of the diff is here:
> Peter> [ ... ]
> 
> Could you try putting that code back and seeing if it helps?
> If so I'll check it in.

Sorry that it took me so long to reply, I tried just adding this back and it 
did not work, however the attached patch built perfectly fine (on my Mac OS 
X 10.3 system which already worked anyway). I retested having edited the 
generated libtool's idea of max_cmd_len to 16 Kb and removing my libgcj.la 
files and it built using ld -r and ar cq with a couple of warnings:

using piecewise archive linking...
libtool: link: warning: object name conflicts; overriding AR_FLAGS to 'cq'
libtool: link: warning: to ensure that POSIX-compatible ar will work

and

ld: warning multiple definitions of symbol _sqrt
./.libs/libgcj.dylib(libgcj.la-6.o) definition of _sqrt
/usr/lib/libpthread.dylib(sqrt970.o) definition of _sqrt

(the _sqrt warnings were there before too).

Hope this helps someone somewhere :)

Peter
-- 
Peter O'Gorman - http://www.pogma.com

[-- Attachment #2: libjava_Makefile_am.diff --]
[-- Type: text/plain, Size: 1093 bytes --]

Index: Makefile.am
===================================================================
RCS file: /cvsroot/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.414
diff -u -3 -p -u -r1.414 Makefile.am
--- Makefile.am	24 Sep 2004 06:41:55 -0000	1.414
+++ Makefile.am	27 Sep 2004 13:05:06 -0000
@@ -211,6 +211,17 @@ libgcj_la_DEPENDENCIES = libgcj-@gcc_ver
 	java/lang/fdlibm.h java/lang/ieeefp.h java/lang/mprec.h \
 	$(LIBLTDL) $(LIBFFI) $(ZLIBS) $(GCLIBS) $(propertyo_files)
 
+
+## Pass the list of object files to libtool in a temporary file to
+## avoid tripping platform command line length limits.
+libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
+	@echo Creating list of files to link...
+	@: $(call write_entries_to_file,$(libgcj_la_OBJECTS),libgcj.objectlist)
+	$(libgcj_la_LINK) -objectlist libgcj.objectlist \
+	$(libgcj_la_LIBADD) \
+	-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
+
+
 # Include THREADLIBS here to ensure that the correct version of
 # certain linuxthread functions get linked:
 ## The mysterious backslash in the grep pattern is consumed by make.

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Tom Tromey]

>>>>> "Peter" == Peter O'Gorman <peter@pogma.com> writes:

Peter> Sorry that it took me so long to reply, I tried just adding this back
Peter> and it did not work, however the attached patch built perfectly fine
Peter> (on my Mac OS X 10.3 system which already worked anyway).

Just to clear up any vagueness that might linger: after adding the
patch to Makefile.am, did you re-run automake?  And if so did it then
fail in the same way (command line too long)?  It wasn't clear to me.

I'll test this patch here too, I'll probably add it back as it seems
like the only reasonable way to address PR 17222.

Peter> using piecewise archive linking...
Peter> libtool: link: warning: object name conflicts; overriding AR_FLAGS to 'cq'
Peter> libtool: link: warning: to ensure that POSIX-compatible ar will work

Don't worry about these.

Peter> ld: warning multiple definitions of symbol _sqrt
Peter> ./.libs/libgcj.dylib(libgcj.la-6.o) definition of _sqrt
Peter> /usr/lib/libpthread.dylib(sqrt970.o) definition of _sqrt
Peter> (the _sqrt warnings were there before too).

Yeah, we define our own sqrt() (from fdlibm).  I'm amenable to
renaming it if that is needed on your platform, if you want to write a
patch.  Usually we just slap a "_Jv_" prefix on things and add a
comment explaining why.

Tom

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Kelley Cook]

--- Tom Tromey <tromey@redhat.com> wrote:

> >>>>> "Peter" == Peter O'Gorman <peter@pogma.com> writes:
> 
> Peter> Sorry that it took me so long to reply, I tried just adding
> this back
> Peter> and it did not work, however the attached patch built
> perfectly fine
> Peter> (on my Mac OS X 10.3 system which already worked anyway).
> 
> Just to clear up any vagueness that might linger: after adding the
> patch to Makefile.am, did you re-run automake?  And if so did it then
> fail in the same way (command line too long)?  It wasn't clear to me.
> 
> I'll test this patch here too, I'll probably add it back as it seems
> like the only reasonable way to address PR 17222.

Tom,

My work computer is in process of an overnight bootstrap on
pentium4-pc-cygwin where the error occur.  I'll report back in the
morning.

KC

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Peter O'Gorman]

Tom Tromey wrote:

> Just to clear up any vagueness that might linger: after adding the
> patch to Makefile.am, did you re-run automake?  And if so did it then
> fail in the same way (command line too long)?  It wasn't clear to me.

autoreconf, but same thing. The original patch failed because -objectlist 
does not like to see .la's, only .lo's. With the slightly modified version I 
posted the libtool line became just a few lines long rather than 80Kb.

> 
> I'll test this patch here too, I'll probably add it back as it seems
> like the only reasonable way to address PR 17222.

Cool, thanks.

> Yeah, we define our own sqrt() (from fdlibm).  I'm amenable to
> renaming it if that is needed on your platform, if you want to write a
> patch.  Usually we just slap a "_Jv_" prefix on things and add a
> comment explaining why.

It is not a failure, just a warning, but it seemed a little strange to be 
redifining sqrt. I might have a look, but probably not :)

Thanks,
Peter
-- 
Peter O'Gorman - http://www.pogma.com

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Andrew Haley]

Peter O'Gorman writes:
 > it seemed a little strange to be redifining sqrt. I might have a
 > look, but probably not :)

This confuses many people.  The routines are in libgcj because not all
systems had sufficiently accurate routines for elementary functions.
This is perhaps less impoertant than it used to be.  However, a linker
shouldn't complain if it sees the same symbol in two different
libraries.

Andrew.

Re: Bootstrap difficulties on powerpc-apple-darwin6.8 (Mac OS X 10.2.8)

[Di-an JAN]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 598 bytes --]

On Mon, 27 Sep 2004, Tom Tromey wrote:

> I'll test this patch here too, I'll probably add it back as it seems
> like the only reasonable way to address PR 17222.

http://gcc.gnu.org/ml/gcc/2004-09/msg01520.html

Could the addition be moved back to where it was originally,
next to the rule for lib-gnu-awt-xlib.la which also use the same
technique?  Patch attached.  Tested with full bootstrap on
i686-pc-cygwin.

While we're touching that file, I noticed the list of java files
is out of order starting wit gnu/regexp/CharIndexed.java
I'm unable to test a patch for that at the moment.

Di-an Jan

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2109 bytes --]

Index: libjava/Makefile.am
===================================================================
RCS file: /cvsroot/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.417
diff -c -3 -p -r1.417 Makefile.am
*** libjava/Makefile.am	28 Sep 2004 20:37:39 -0000	1.417
--- libjava/Makefile.am	29 Sep 2004 07:16:19 -0000
*************** libgcj_la_DEPENDENCIES = libgcj-@gcc_ver
*** 211,225 ****
  	java/lang/fdlibm.h java/lang/ieeefp.h java/lang/mprec.h \
  	$(LIBLTDL) $(LIBFFI) $(ZLIBS) $(GCLIBS) $(propertyo_files)
  
- ## Pass the list of object files to libtool in a temporary file to
- ## avoid tripping platform command line length limits.
- libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
- 	@echo Creating list of files to link...
- 	@: $(call write_entries_to_file,$(libgcj_la_OBJECTS),libgcj.objectlist)
- 	$(libgcj_la_LINK) -objectlist libgcj.objectlist \
- 	$(libgcj_la_LIBADD) \
- 	-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
- 
  # Include THREADLIBS here to ensure that the correct version of
  # certain linuxthread functions get linked:
  ## The mysterious backslash in the grep pattern is consumed by make.
--- 211,216 ----
*************** $(gtk_awt_peer_sources:.java=.lo): %.lo:
*** 571,576 ****
--- 562,575 ----
  gnu/gcj/runtime/StackTrace.lo: gnu/gcj/runtime/StackTrace.java
  	$(LTGCJCOMPILE) -fno-optimize-sibling-calls -o $@ -c $<
  
+ ## Pass the list of object files to libtool in a temporary file to
+ ## avoid tripping platform command line length limits.
+ libgcj.la: $(libgcj_la_OBJECTS) $(libgcj_la_DEPENDENCIES)
+ 	@echo Creating list of files to link...
+ 	@: $(call write_entries_to_file,$(libgcj_la_OBJECTS),libgcj.objectlist)
+ 	$(libgcj_la_LINK) -objectlist libgcj.objectlist $(libgcj_la_LIBADD) \
+ 	-rpath $(toolexeclibdir) $(libgcj_la_LDFLAGS) $(LIBS)
+ 
  lib-gnu-awt-xlib.la: $(lib_gnu_awt_xlib_la_OBJECTS) $(lib_gnu_awt_xlib_la_DEPENDENCIES)
  	@echo Creating list of files to link...
  	@: $(call write_entries_to_file,$(lib_gnu_awt_xlib_la_OBJECTS) $(lib_gnu_awt_xlib_la_LIBADD),lib_gnu_awt_xlib.objectlist)