trouble building gcc-3.2 --target=m68k-linux from scratch

trouble building gcc-3.2 --target=m68k-linux from scratch

[Peter Barada]

I'm attempting to build a m68k-linux compiler from scratch using stock
versions of:

linux-2.5.1
binutils-2.13
gcc-3.2
glibc-2.2.5
gdb-5.2.1

building with bill Gatliff's script to config the kernel, copy over
the hears, config/binud binutils, config/build gcc-bootstrap...

The kernel headers copy over fine, binutils-builds, and gcc-bootstrap
is configured as: 

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/version.c --host=i686-pc-linux-gnu --target=m68k-linux --prefix=/tmp/junk --enable-languages=c --with-local-prefix=/tmp/junk/m68k-linux --without-headers --with-newlib --disable-shared --verbose --norecursion 
#  using "mt-frag"

And it fails building gcc/unwind-dw2.c:

/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/junk/m68k-linux/gcc-bootstrap/gcc/xgcc -B/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/junk/m68k-linux/gcc-bootstrap/gcc/ -B/tmp/junk/m68k-linux/bin/ -B/tmp/junk/m68k-linux/lib/ -isystem /tmp/junk/m68k-linux/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/config -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/../include -fexceptions -c /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2.c:26:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-pe.h: In function `size_of_encoded_value':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-pe.h:76: warning: implicit declaration of function `abort'
In file included from gthr-default.h:1,
                 from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/gthr.h:98,
                 from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2.c:28:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/gthr-posix.h:37:21: pthread.h: No such file or directory

Configure created ghtr-default.h with '#include <pthread.h>' since it
found a pthread.h that can be used, but that was by using the *host*
compiler to find a phtreads.h, not the *target* compiler.

Since a stock linux source doesn't have pthread.h in its headers, and
glibc hasn't been built yet, there's no pthread.h that can be used at
this time.

If I add --disable-threads to the configure for the bootstrap, it
completes.

1) Why does configure think that it has a valid pthreads.h(or that is
   should use the host compiler to find one)?
2) Is --disable-threads necessary for the bootstrap step?

All suggestions are appreciated...

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Loren James Rittle]

In article < 200208191724.g7JHOoS19048@hyper.wm.sps.mot.com > Peter Barada
writes:

> [...] gthr-posix.h:37:21: pthread.h: No such file or directory

> Configure created ghtr-default.h with '#include <pthread.h>' since it
> found a pthread.h that can be used, but that was by using the *host*
> compiler to find [phtread.h], not the *target* compiler. [...]

Hi Peter,

Oops.  This is related to a recent change in the default compiler
configuration.  I believe that all cross ports are actually latently
affected by the underlying issue you found.

The original test in configure.in:

AC_CHECK_HEADER(pthread.h, [have_pthread_h=yes], [have_pthread_h=])

presumes that it is configuring for native bootstrap since it uses the
default autoconf expansion which itself knows nothing about the gcc
bootstrap process (and alternate system headers to use)...

Seems that the test would have to be written to set have_pthread_h
using a check based on the headers to be used by the installed
compiler (i.e. path provided with --with-headers).  Perhaps (formed
via cut-n-paste of other constructs in configure.in):

if [test x$host != x$target]; then
       if [test x$with_headers = x]; then
               have_pthread_h=
       else
               # set have_pthread_h with a test based on value of with_headers
       fi
else
       AC_CHECK_HEADER(pthread.h, [have_pthread_h=yes], [have_pthread_h=])
fi

Regards,
Loren

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Peter Barada]

>> [...] gthr-posix.h:37:21: pthread.h: No such file or directory
>
>> Configure created ghtr-default.h with '#include <pthread.h>' since it
>> found a pthread.h that can be used, but that was by using the *host*
>> compiler to find [phtread.h], not the *target* compiler. [...]
>
>Hi Peter,
>
>Oops.  This is related to a recent change in the default compiler
>configuration.  I believe that all cross ports are actually latently
>affected by the underlying issue you found.
>
>Seems that the test would have to be written to set have_pthread_h
>using a check based on the headers to be used by the installed
>compiler (i.e. path provided with --with-headers).  Perhaps (formed
>via cut-n-paste of other constructs in configure.in):

The config is done --without-headers, so the test for any target
header should be written to fail since --without-headers is on the
configure line. Of course I don't know if that will mess up anything
else.

Is there anyway to get this 'fixed' for gcc-3.2.1 so those of use
doing cross-compilation don't get bit again(even if its just a
documentation change)?

Thanx...

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Loren James Rittle]

In article < 200208192246.g7JMkl909384@hyper.wm.sps.mot.com >,
Peter Barada <pbarada@mail.wm.sps.mot.com> writes:

>> Seems that the test would have to be written to set have_pthread_h
>> using a check based on the headers to be used by the installed
>> compiler (i.e. path provided with --with-headers).  Perhaps (formed
>> via cut-n-paste of other constructs in configure.in):

> The config is done --without-headers, so the test for any target
> header should be written to fail since --without-headers is on the
> configure line. Of course I don't know if that will mess up anything
> else.

FYI, AFAIS there are really only two such target headers being checked
incorrectly: have_pthread_h and have_thread_h.  My proposed solution
should cover both although I only showed the change as it affects
have_pthread_h.  How about this instead:

if [test x$host != x$target]; then
	if [test x$with_headers = x]; then
		have_thread_h=
		have_pthread_h=
	else
		# set have_*thread_h with a test based on value of with_headers
	fi
else
	AC_CHECK_HEADER(thread.h, [have_thread_h=yes], [have_thread_h=])
	AC_CHECK_HEADER(pthread.h, [have_pthread_h=yes], [have_pthread_h=])
fi

> Is there anyway to get this 'fixed' for gcc-3.2.1 so those of use
> doing cross-compilation don't get bit again(even if its just a
> documentation change)?

If an autoconf guru for gcc agrees with my analysis, then we could
submit a formal patch.  However, I still don't know what actual code
should go in the shell comment above without more investigation.

Regards,
Loren

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Dan Kegel]

Peter Barada wrote:
> I'm attempting to build a m68k-linux compiler from scratch using stock
> versions of:
> 
> linux-2.5.1
> binutils-2.13
> gcc-3.2
> glibc-2.2.5
> gdb-5.2.1
> 
> building with bill Gatliff's script to config the kernel, copy over
> the hears, config/binud binutils, config/build gcc-bootstrap...
> ...
> And it fails building gcc/unwind-dw2.c:
> ...
> Since a stock linux source doesn't have pthread.h in its headers, and
> glibc hasn't been built yet, there's no pthread.h that can be used at
> this time.

I ran into something like this on ppc on gcc-3.0.4; the fix was
to do a glibc "make install-headers" before building gcc, I think.  See
http://www.kegel.com/xgcc3/
- Dan

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Kai Henningsen]

pbarada@mail.wm.sps.mot.com (Peter Barada)  wrote on 19.08.02 in < 200208191724.g7JHOoS19048@hyper.wm.sps.mot.com >:

> Since a stock linux source doesn't have pthread.h in its headers, and

That should be completely irrelevant. User programs (such as gcc) aren't  
supposed to include the raw kernel headers, they're supposed to - if  
anything - use copies provided by libc. (And no, /usr/include/linux is  
*NOT* supposed to be a symlink. That was a design error in ancient history  
that has been fixed *years* ago.)

> glibc hasn't been built yet, there's no pthread.h that can be used at
> this time.

That, OTOH, is of course completely relevant.

> If I add --disable-threads to the configure for the bootstrap, it
> completes.

I believe 3.2 does include the change that made pthreads default on  
practically every variant of Linux, so as to get everyone on a common ABI.


MfG Kai

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Richard Zidlicky]

On Mon, Aug 19, 2002 at 01:24:50PM -0400, Peter Barada wrote:
> 
> I'm attempting to build a m68k-linux compiler from scratch using stock
> versions of:
> 
> linux-2.5.1

why that?? Try current 2.4 or maybe late 2.5

> binutils-2.13

ok.

> gcc-3.2

patches required

> 
> And it fails building gcc/unwind-dw2.c:

I was unable to get a clean crosscompiler because of header problems
since a few weeks. Imho libgcc should be a bit less header-demanding
when just languages=c is requested, otherwise even trivial tasks like 
crosscompiling kernels will turn into rocket science.

Btw why is unwind-dw2 compiled at all for platforms that do sjlj
exceptions anyway?

I am sending you my random patch collection per PM.

Richard

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Peter Barada]

>> Since a stock linux source doesn't have pthread.h in its headers, and
>> glibc hasn't been built yet, there's no pthread.h that can be used at
>> this time.
>
>I ran into something like this on ppc on gcc-3.0.4; the fix was
>to do a glibc "make install-headers" before building gcc, I think.  See
> http://www.kegel.com/xgcc3/

Just adding --disable-threads to the configure line allowed the
bootstrap compiler to build.  Why create more interdependencies?

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Peter Barada]

>> linux-2.5.1
>
>why that?? Try current 2.4 or maybe late 2.5

Its what I have, and it seems to work for ColdFire v4e (so far).

>> gcc-3.2
>
>patches required

Why the patches?  How can these patches get back into the FSF tree so
I don't need a crystal ball to get a working build when gcc-3.2.1 or
gcc-3.3 comes out?

>Btw why is unwind-dw2 compiled at all for platforms that do sjlj
>exceptions anyway?

Since I'm just building a C compiler why is exception handling getting
built at all?

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: trouble building gcc-3.2 --target=m68k-linux from scratch

[Richard Zidlicky]

On Tue, Aug 20, 2002 at 10:27:46AM -0400, Peter Barada wrote:
> 
> >> linux-2.5.1
> >
> >why that?? Try current 2.4 or maybe late 2.5
> 
> Its what I have, and it seems to work for ColdFire v4e (so far).
> 
> >> gcc-3.2
> >
> >patches required
> 
> Why the patches?  How can these patches get back into the FSF tree so
> I don't need a crystal ball to get a working build when gcc-3.2.1 or
> gcc-3.3 comes out?

good question.

> >Btw why is unwind-dw2 compiled at all for platforms that do sjlj
> >exceptions anyway?
> 
> Since I'm just building a C compiler why is exception handling getting
> built at all?

another good question.

Richard