Re: cross-compilation documentation

Re: cross-compilation documentation

[Dan Kegel]

Tonight's post by Kaz on crossgcc got me reading old threads,
and I came across this one from last June:
http://gcc.gnu.org/ml/gcc/2003-06/msg01875.html
in which Zach Weinberg said
>We want to decouple libgcc build from compiler build for
>other reasons, but that's sufficiently invasive that it's probably a
>3.5 item at this point (the way I wanna do it, it needs bootstrap to
>run at top level, and it involves moving a lot of files).
Back then, 3.5 seemed impossibly far off.  Now it's at our
doorstep.  Has there been any motion on getting libgcc
build decoupled from basic gcc build?  It would be highly
appreciated.  It's getting harder and harder to bootstrap
the gcc/glibc combination with each new release.  cvs glibc
looks like it currently requires you to have a good target
gcc *just to install the headers*, so my old tricks won't
work.  Getting rid of the need for glibc headers to build
plain old gcc would really cut through the Gordian knot.
Pretty please?

I'll gladly buy anyone working on this a beer at the summit...
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

Re: cross-compilation documentation

[Zack Weinberg]

Dan Kegel <dank@kegel.com> writes:

> Tonight's post by Kaz on crossgcc got me reading old threads,
> and I came across this one from last June:
> http://gcc.gnu.org/ml/gcc/2003-06/msg01875.html
> in which Zach Weinberg said

"Zachary" or "Zack", never "Zach", please. 

>  >We want to decouple libgcc build from compiler build for other
>  >reasons, but that's sufficiently invasive that it's probably a 3.5
>  >item at this point (the way I wanna do it, it needs bootstrap to
>  >run at top level, and it involves moving a lot of files).
>
> Back then, 3.5 seemed impossibly far off.  Now it's at our doorstep.
> Has there been any motion on getting libgcc build decoupled from
> basic gcc build?  It would be highly appreciated.

There is ongoing work on moving the bootstrap control logic to the top
level, which is a prerequisite for decoupling libgcc from gcc.  The
people working on it are Paolo Bonzini and Nathanael Nerode, as far as
I know.  If you would like to lend a hand with that I'm sure they
would be delighted for the help.

zw

Re: cross-compilation documentation

[Dan Kegel]

Zack Weinberg wrote:
> There is ongoing work on moving the bootstrap control logic to the top
> level, which is a prerequisite for decoupling libgcc from gcc.  The
> people working on it are Paolo Bonzini and Nathanael Nerode, as far as
> I know.  If you would like to lend a hand with that I'm sure they
> would be delighted for the help.

Thanks for the info.  I see at
http://cia.navi.cx/stats/author/bonzini
http://cia.navi.cx/stats/author/neroden
that they are indeed doing quite a bit of configury changes.
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

RE: cross-compilation documentation

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Dan Kegel
> Sent: 29 May 2004 06:22

> Back then, 3.5 seemed impossibly far off.  Now it's at our
> doorstep.  Has there been any motion on getting libgcc
> build decoupled from basic gcc build?  It would be highly
> appreciated.  It's getting harder and harder to bootstrap
> the gcc/glibc combination with each new release.  cvs glibc
> looks like it currently requires you to have a good target
> gcc *just to install the headers*, so my old tricks won't
> work.  Getting rid of the need for glibc headers to build
> plain old gcc would really cut through the Gordian knot.

  Why would decoupling the libgcc build make building glibc any easier or
more difficult?  Don't quite see it myself.

  Anyway, does the old "--without-headers --with-newlib" trick still work
for making a bootstrap compiler these days?  I haven't tried it since 2.95.x
days.


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

Re: cross-compilation documentation

[Peter Barada]

>  Why would decoupling the libgcc build make building glibc any easier or
>more difficult?  Don't quite see it myself.
>
>  Anyway, does the old "--without-headers --with-newlib" trick still work
>for making a bootstrap compiler these days?  I haven't tried it since 2.95.x
>days.

Because right now to build a full linux cross-compiler requires
building a bootstrap compiler which needs a set of headers installed
to build libgcc.  Once a bootstrap compiler is built, then glibc can be built
and installed, and then go back and build up the full compiler.

Since the headers are needed *before* a compiler is built, its a
chicken and egg process.  The current method convinces glibc to just
install its headers which are used to build libgcc as part of the
bootstrap compiler creation.

The newer versions of glibc don't have an easy method to just install
the headers so if the requirement of building libgcc as part fo the
compiler can be relaxed(at least for the bootstrap compiler), then the
process would look like:

1) build/install binutils
2) build/install bootstrap compiler
3) build/install glibc
4) build/install full compiler(w/c++, etc).
5) build/install libgcc for full compiler.

-- 
Peter Barada
peter@the-baradas.com

Re: cross-compilation documentation

[Gerald Pfeifer]

On Sun, 22 Jun 2003, Dara Hazeghi wrote:
>> It is documented, just not fully:
>>
>> "that each --with option has a corresponding
>> --without option"
>>
> Precisely my point. This interpretation does not seem at all obvious to
> me, and, I suspect, to others. IMHO, we should have a much clearer
> description for options like these.

Well, if someone could submit a patch, I'll happily apply it. ;-)

Gerald

Re: cross-compilation documentation

[Jim Wilson]

Jan-Benedict Glaw wrote:
> <USER type="newbie">
> 	Say I want to give --with-headers, what exactly should I place
> 	there, in which structure?

--with-headers assumes you have access to the target.  You copy the 
entire contents of the target's /usr/include to the build machine, and 
then you use --with-headers to point at the copied tree.

If you are trying to build a glibc based cross compiler from scratch, 
then --with-headers by itself doesn't help you much, because you don't 
have a target /usr/include directory to copy.  You need a more 
complicated build process for this.

Jim

Re: cross-compilation documentation

[Hans-Peter Nilsson]

On Mon, 23 Jun 2003, Dan Kegel wrote:
> Hans-Peter Nilsson wrote:
> > Maybe you guys could help fixing this (i.e. the install-headers
> > make-all bug) properly, i.e. *in glibc*.
>
> Yes.  Is there a PR yet against glibc for this?

I don't know.

brgds, H-P

Re: cross-compilation documentation

[Dan Kegel]

Hans-Peter Nilsson wrote:
> On Mon, 23 Jun 2003, Peter Barada wrote:
> 
>>>>But this fragment *requires* a cross-compiler to build it.
>>>
>>>Hmm.  That's odd.  I do almost the same thing, but I don't require a cross-compiler.
>>>Maybe the step you're missing is the following kludge:
>>>        make sysdeps/gnu/errlist.c
>>>        mkdir -p stdio-common
>>>        touch stdio-common/errlist-compat.c
>>>That goes between the configure and the make of glibc, and keeps anything
>>>real from being compiled by the install-headers.
>>
>>If that's in the source tree then its *really* a kludge and won't work
>>too well for me since I keep my source in a CVS controlled tree.
> 
> 
> Maybe you guys could help fixing this (i.e. the install-headers
> make-all bug) properly, i.e. *in glibc*.

Yes.  Is there a PR yet against glibc for this?
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Dan Kegel]

Peter Barada wrote:
>>>But this fragment *requires* a cross-compiler to build it.
>>
>>Hmm.  That's odd.  I do almost the same thing, but I don't require a cross-compiler.
>>Maybe the step you're missing is the following kludge:
>>        make sysdeps/gnu/errlist.c
>>        mkdir -p stdio-common
>>        touch stdio-common/errlist-compat.c
>>That goes between the configure and the make of glibc, and keeps anything
>>real from being compiled by the install-headers.
> 
> 
> If that's in the source tree then its *really* a kludge and won't work
> too well for me since I keep my source in a CVS controlled tree.

Well, yes, it is *really* a kludge.  The cleaner way to approach
that would be a patch the glibc's makefile to prevent the
install-headers step from generating any .c files, by breaking
that out into an install-generated-sources step, maybe.

>>I think the powers that be are suggesting that the fix for gcc-3.5
>>might be to separate out the building of libgcc from the building of
>>gcc.  Hmm, and then separate out the building of anything in glibc
>>that requires libgcc into a separate target.  Then we could do
>>   make bootstrap gcc without libgcc
>>   make whatever parts of glibc that don't depend on libgcc
>>   make real gcc including libgcc
>>   make whatever parts of glibc that depend on libgcc
> 
> That's what I described as *two* bootstrap compilers and *two*
> configure/builds of glibc...

No, it's a bit different. When they do this for 3.5, it'll
be done cleanly, so you're really only building any particular
part once (except for the bootstrap gcc, which is a duplication
of the final gcc).
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Hans-Peter Nilsson]

On Mon, 23 Jun 2003, Peter Barada wrote:
> >> But this fragment *requires* a cross-compiler to build it.
> >
> >Hmm.  That's odd.  I do almost the same thing, but I don't require a cross-compiler.
> >Maybe the step you're missing is the following kludge:
> >         make sysdeps/gnu/errlist.c
> >         mkdir -p stdio-common
> >         touch stdio-common/errlist-compat.c
> >That goes between the configure and the make of glibc, and keeps anything
> >real from being compiled by the install-headers.
>
> If that's in the source tree then its *really* a kludge and won't work
> too well for me since I keep my source in a CVS controlled tree.

Maybe you guys could help fixing this (i.e. the install-headers
make-all bug) properly, i.e. *in glibc*.

brgds, H-P

Re: cross-compilation documentation

[Daniel Jacobowitz]

On Mon, Jun 23, 2003 at 09:09:06AM -0400, Peter Barada wrote:
> 
> >> But this fragment *requires* a cross-compiler to build it.  I'm sure I
> >
> >Not really.  I do it with a sufficiently new native compiler to run
> >configure.  Configure determines $target by the command line arguments,
> >not by querying the $CC you specify.
> 
> Huh?  what do you mean by a 'sufficently new *native* compiler to run
> configure'.  Is that native compiler for x86(BUILD) or
> ppc-linux(TARGET)?

Yes, build.  Just one which passes the version checks in glibc's configure
script, or one slightly older and disable the checks.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: cross-compilation documentation

[Peter Barada]

>> But this fragment *requires* a cross-compiler to build it.  I'm sure I
>
>Not really.  I do it with a sufficiently new native compiler to run
>configure.  Configure determines $target by the command line arguments,
>not by querying the $CC you specify.

Huh?  what do you mean by a 'sufficently new *native* compiler to run
configure'.  Is that native compiler for x86(BUILD) or
ppc-linux(TARGET)?

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Peter Barada]

>> But this fragment *requires* a cross-compiler to build it.
>
>Hmm.  That's odd.  I do almost the same thing, but I don't require a cross-compiler.
>Maybe the step you're missing is the following kludge:
>         make sysdeps/gnu/errlist.c
>         mkdir -p stdio-common
>         touch stdio-common/errlist-compat.c
>That goes between the configure and the make of glibc, and keeps anything
>real from being compiled by the install-headers.

If that's in the source tree then its *really* a kludge and won't work
too well for me since I keep my source in a CVS controlled tree.

>> ... I'm hoping people see that there *is* a
>> problem making blanket statements that "its perfectly normal to insist
>> that the system headers be installed when building the bootstrap".
>
>Indeed.
>
>> I don't know what the solution is, but I trying to figure out the
>> minimal set of changes necessary to make a(or most/if not
>> all -linux toolchains).  That way hopefully with the next release of
>> gcc/glibc I won't have to go through this mess all over again...
>
>I think the powers that be are suggesting that the fix for gcc-3.5
>might be to separate out the building of libgcc from the building of
>gcc.  Hmm, and then separate out the building of anything in glibc
>that requires libgcc into a separate target.  Then we could do
>    make bootstrap gcc without libgcc
>    make whatever parts of glibc that don't depend on libgcc
>    make real gcc including libgcc
>    make whatever parts of glibc that depend on libgcc

That's what I described as *two* bootstrap compilers and *two*
configure/builds of glibc...

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Daniel Jacobowitz]

On Sun, Jun 22, 2003 at 10:48:05PM -0400, Peter Barada wrote:
> 
> >> What am I missing here?
> >
> >Unless the code ends up _included_ in glibc.
> >
> >Or in any of the dozens of little applications built at the same time
> >as glibc, for instance.
> 
> what 'dozens of little applications' are built by glibc, and are they
> installed and used by glibc?

Things like rpcgen, iconv, et cetera.

You also run the risk of getting parts of libgcc linked into libc and
related libraries.  If those copies don't support unwinding, you lose
later.

> 1) first bootstrap compiler that has *no* libgcc which is used for the:
> 2) first glibc configurd/built only to install-headers
> 3) second bootstrap compiler can now be built(and build ligbcc) since the
>    headers are in place
> 4) second glibc that is fully built using the second bootstrap
>    compiler
> 5) full gcc with c++ using the second bootstrap compiler.
> 
> Is there a more efficient method that *doesn't* require building two
> bootstrap compilers or effectively building glibc twice?

The way I'm describing and Dan K is also describing works.  I use it
daily.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: cross-compilation documentation

[Daniel Jacobowitz]

On Sun, Jun 22, 2003 at 10:59:52PM -0400, Peter Barada wrote:
> 
> >Well, sure!  My script at http://kegel.com/crosstool does this:
> >1) configure glibc and do 'make install-headers'; a wee bit of hackery
> >    circumvents its urge to build everything
> >2) build and install bootstrap compiler
> >3) build and install real glibc
> >4) build and install real gcc
> >
> >My step #1 isn't pretty, but it only takes a couple minutes, and I'm
> >sure it's faster than what you described.  I thought you knew about
> >that already...
> 
> Yes I did.  I use the following Makefile fragment to get the headers:
> 
> glibc1: ${GLIBC_BUILDDIR1} glibc1-fix
> 	export PATH=${INSTALL_DIR}/bin:${HOST_INSTALL_DIR}/bin:$$PATH; \
> 	cd ${GLIBC_BUILDDIR1}; \
> 	CC=${TARGET}-gcc AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \
> 	${GLIBC_SOURCE_PATH}/configure --host=${TARGET} \
> 	--prefix=/usr --without-cvs --disable-sanity-checks \
> 	--with-headers=${INSTALL_DIR}/${TARGET}/include ; \
> 	make cross-compiling=yes install_root=${INSTALL_DIR}/${TARGET} prefix="" install-headers
> 
> glibc1-fix:
> 	mkdir -p ${INSTALL_DIR}/${TARGET}/include/gnu ; \
> 	touch ${INSTALL_DIR}/${TARGET}/include/gnu/stubs.h ; \
> 	cp -f ${GLIBC_SOURCE_PATH}/include/features.h ${INSTALL_DIR}/include/features.h
> 
> 
> But this fragment *requires* a cross-compiler to build it.  I'm sure I

Not really.  I do it with a sufficiently new native compiler to run
configure.  Configure determines $target by the command line arguments,
not by querying the $CC you specify.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: cross-compilation documentation

[Dan Kegel]

Peter Barada wrote:
> I've had ssucess building a toolchain vor ppc-linux by building *two*
> bootstrap compilers and *two* glibcs:
> 
> 1) first bootstrap compiler that has *no* libgcc which is used for the:
> 2) first glibc configurd/built only to install-headers
> 3) second bootstrap compiler can now be built(and build ligbcc) since the
>    headers are in place
> 4) second glibc that is fully built using the second bootstrap
>    compiler
> 5) full gcc with c++ using the second bootstrap compiler.
> 
> Is there a more efficient method that *doesn't* require building two
> bootstrap compilers or effectively building glibc twice?

Well, sure!  My script at http://kegel.com/crosstool does this:
1) configure glibc and do 'make install-headers'; a wee bit of hackery
    circumvents its urge to build everything
2) build and install bootstrap compiler
3) build and install real glibc
4) build and install real gcc

My step #1 isn't pretty, but it only takes a couple minutes, and I'm
sure it's faster than what you described.  I thought you knew about
that already...
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Dan Kegel]

Peter Barada wrote:
> glibc1: ${GLIBC_BUILDDIR1} glibc1-fix
> 	export PATH=${INSTALL_DIR}/bin:${HOST_INSTALL_DIR}/bin:$$PATH; \
> 	cd ${GLIBC_BUILDDIR1}; \
> 	CC=${TARGET}-gcc AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \
> 	${GLIBC_SOURCE_PATH}/configure --host=${TARGET} \
> 	--prefix=/usr --without-cvs --disable-sanity-checks \
> 	--with-headers=${INSTALL_DIR}/${TARGET}/include ; \
> 	make cross-compiling=yes install_root=${INSTALL_DIR}/${TARGET} prefix="" install-headers
> 
> glibc1-fix:
> 	mkdir -p ${INSTALL_DIR}/${TARGET}/include/gnu ; \
> 	touch ${INSTALL_DIR}/${TARGET}/include/gnu/stubs.h ; \
> 	cp -f ${GLIBC_SOURCE_PATH}/include/features.h ${INSTALL_DIR}/include/features.h
> 
> 
> But this fragment *requires* a cross-compiler to build it.

Hmm.  That's odd.  I do almost the same thing, but I don't require a cross-compiler.
Maybe the step you're missing is the following kludge:
         make sysdeps/gnu/errlist.c
         mkdir -p stdio-common
         touch stdio-common/errlist-compat.c
That goes between the configure and the make of glibc, and keeps anything
real from being compiled by the install-headers.

> ... I'm hoping people see that there *is* a
> problem making blanket statements that "its perfectly normal to insist
> that the system headers be installed when building the bootstrap".

Indeed.

> I don't know what the solution is, but I trying to figure out the
> minimal set of changes necessary to make a(or most/if not
> all -linux toolchains).  That way hopefully with the next release of
> gcc/glibc I won't have to go through this mess all over again...

I think the powers that be are suggesting that the fix for gcc-3.5
might be to separate out the building of libgcc from the building of
gcc.  Hmm, and then separate out the building of anything in glibc
that requires libgcc into a separate target.  Then we could do
    make bootstrap gcc without libgcc
    make whatever parts of glibc that don't depend on libgcc
    make real gcc including libgcc
    make whatever parts of glibc that depend on libgcc
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Peter Barada]

>Well, sure!  My script at http://kegel.com/crosstool does this:
>1) configure glibc and do 'make install-headers'; a wee bit of hackery
>    circumvents its urge to build everything
>2) build and install bootstrap compiler
>3) build and install real glibc
>4) build and install real gcc
>
>My step #1 isn't pretty, but it only takes a couple minutes, and I'm
>sure it's faster than what you described.  I thought you knew about
>that already...

Yes I did.  I use the following Makefile fragment to get the headers:

glibc1: ${GLIBC_BUILDDIR1} glibc1-fix
	export PATH=${INSTALL_DIR}/bin:${HOST_INSTALL_DIR}/bin:$$PATH; \
	cd ${GLIBC_BUILDDIR1}; \
	CC=${TARGET}-gcc AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \
	${GLIBC_SOURCE_PATH}/configure --host=${TARGET} \
	--prefix=/usr --without-cvs --disable-sanity-checks \
	--with-headers=${INSTALL_DIR}/${TARGET}/include ; \
	make cross-compiling=yes install_root=${INSTALL_DIR}/${TARGET} prefix="" install-headers

glibc1-fix:
	mkdir -p ${INSTALL_DIR}/${TARGET}/include/gnu ; \
	touch ${INSTALL_DIR}/${TARGET}/include/gnu/stubs.h ; \
	cp -f ${GLIBC_SOURCE_PATH}/include/features.h ${INSTALL_DIR}/include/features.h


But this fragment *requires* a cross-compiler to build it.  I'm sure I
could futz it further, but I'm hoping people see that there *is* a
problem making blanket statements that "its perfectly normal to insist
that the system headers be installed when building the bootstrap".

I don't know what the solution is, but I trying to figure out the
minimal set of changes necessary to make a(or most/if not
all -linux toolchains).  That way hopefully with the next release of
gcc/glibc I won't have to go through this mess all over again...

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Peter Barada]

>> What am I missing here?
>
>Unless the code ends up _included_ in glibc.
>
>Or in any of the dozens of little applications built at the same time
>as glibc, for instance.

what 'dozens of little applications' are built by glibc, and are they
installed and used by glibc?

I've had ssucess building a toolchain vor ppc-linux by building *two*
bootstrap compilers and *two* glibcs:

1) first bootstrap compiler that has *no* libgcc which is used for the:
2) first glibc configurd/built only to install-headers
3) second bootstrap compiler can now be built(and build ligbcc) since the
   headers are in place
4) second glibc that is fully built using the second bootstrap
   compiler
5) full gcc with c++ using the second bootstrap compiler.

Is there a more efficient method that *doesn't* require building two
bootstrap compilers or effectively building glibc twice?

BTW, the patch suggested by Andrew Pinkski:

> Index: linux.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux.h,v
> retrieving revision 1.41
> diff -u -r1.41 linux.h
> --- linux.h	17 Jun 2003 15:53:33 -0000	1.41
> +++ linux.h	22 Jun 2003 17:17:41 -0000
> @@ -91,7 +91,7 @@
>  /* Do code reading to identify a signal frame, and set the frame
>     state data appropriately.  See unwind-dw2.c for the structs.  */
>  
> -#ifdef IN_LIBGCC2
> +#if defined (IN_LIBGCC2) && !defined (inhibit_libc)
>  #include <signal.h>
>  
>  /* During the 2.5 kernel series the kernel ucontext was changed, but
>

fails to build a bootstrap compiler when configure for --target=ppc-linux with: 

	${GCC_SOURCE_PATH}/configure --target=${TARGET} \
	--prefix=${INSTALL_DIR} \
	--with-local-prefix=${INSTALL_DIR}/${TARGET} \
        --without-headers \
	--disable-shared --enable-languages=c \
	--disable-threads

It barfs with:

/home/peter/work/cvs-local/xgcc/obj/ppc-linux/ppc-linux-bootstrap2/gcc/xgcc -B/home/peter/work/cvs-local/xgcc/obj/ppc-linux/ppc-linux-bootstrap2/gcc/ -B/home/mylocal/xcomp/target/ppc-linux/bin/ -B/home/mylocal/xcomp/target/ppc-linux/lib/ -isystem /home/mylocal/xcomp/target/ppc-linux/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc -I/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/. -I/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/config -I/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/../include -fPIC -mstrict-align -fexceptions -c /home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
In file included from /home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c:26:
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-pe.h: In function `size_of_encoded_value':
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-pe.h:76: warning: implicit declaration of function `abort'
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c: In function `extract_cie_info':
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c:247: warning: implicit declaration of function `strlen'
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c: In function `uw_frame_state_for':
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c:928: warning: implicit declaration of function `memset'
/home/peter/work/cvs-local/xgcc/gcc-3.3/gcc/unwind-dw2.c:939: error: `SIGNAL_FRAMESIZE' undeclared (first use in this function)
...

So not including the headers won't cut it.  The code that refers to
any defintions(such as the size of the SIGNALE_FRAMESIZE) has to be
disabled under #if !defined(inhibit_libc), and that doesn't sound like
a very elegant solution...

Any other suggestions?

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Dan Kegel]

Jan-Benedict Glaw wrote:
> Dan Kegel <dank@kegel.com> wrote:
>>
>>OK, your wish is granted, I think.  Even that last part.
>>See http://kegel.com/crosstool for my all-singing, all-dancing build script.
>>(I don't have m68k support yet, but since you asked, I'll try to add it 
>>today.)
> 
> I'm basically interested in toolchains for all Linux-supported targets
> (think vax-linux :-) For now, I don't have hardware to test all targets,
> but I'm really collecting them...

Me, too.  My goal is a script that can build full cross-toolchains from
scratch *and* run remote regression tests on *any* platform supported
by glibc.  Hopefully this could be used as a regression test before new releases.
I want this to be as easy as opening a can of beer, which is very much
not the case currently.

(Why stop at vax?  Think PDP-10 :-)
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Jan-Benedict Glaw]

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

On Sun, 2003-06-22 13:25:51 -0700, Dan Kegel <dank@kegel.com>
wrote in message <3EF610CF.2030506@kegel.com>:
> Jan-Benedict Glaw wrote:
> 
> OK, your wish is granted, I think.  Even that last part.
> See http://kegel.com/crosstool for my all-singing, all-dancing build script.
> (I don't have m68k support yet, but since you asked, I'll try to add it 
> today.)

I'm basically interested in toolchains for all Linux-supported targets
(think vax-linux :-) For now, I don't have hardware to test all targets,
but I'm really collecting them...

> >http://lug-owl.de/~jbglaw/linux-ports/#EasilyBuildableCrossToolchains
> 
> Very nice!  I now link to that from http://www.kegel.com/crosstool/

Thanks. I've done that the other way around.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cross-compilation documentation

[Dan Kegel]

Jan-Benedict Glaw wrote:
>> That first step, installing bootstrap glibc headers, is a new
>> and annoying prerequisite as of gcc-3.3. See
>> http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html
>> for my rant on the subject.
> 
> ACK.
> 
> _But_ it's even worse that there's no[1] strict documentation on how to
> get a working cross-compiler. There are some "interesting"
> configurations which should have easily findable documentation.
> (Extensive --with-sysroot docs?).
> 
> For me, toying mostly with around with Linux, my top wishlist is:
> 
> 	- Building a Linux kernel-only cross compiler on my i386-linux
> 	  box for some {mips|ppc|m68k|...}-linux target running
> 	  efficiently on the box I build it on (BUILD == HOST).
> 	- Building a Linux kernel-only cross compiler on my i386-linux
> 	  box for some {mips|ppc|m68k|...}-linux target running
> 	  on any i386-like Linux machine (BUILD != HOST). So I can
> 	  easily copy this binutils/compiler suite to some other box.
> 
> 	- Building a full cross compiler (including userland and all
> 	  sensefull languages) with BUILD == HOST as well as BULID !=
> 	  HOST, but also keeping in mind that BUILD and HOST are nearly
> 	  identical:)

OK, your wish is granted, I think.  Even that last part.
See http://kegel.com/crosstool for my all-singing, all-dancing build script.
(I don't have m68k support yet, but since you asked, I'll try to add it today.)

> For all those who are trying to build cross compilers, you may find
> helpfull hints at my link list here:
> http://lug-owl.de/~jbglaw/linux-ports/#EasilyBuildableCrossToolchains

Very nice!  I now link to that from http://www.kegel.com/crosstool/

- Dan

[ Please cc me, as I'm not subscribed to gcc. ]

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Daniel Jacobowitz]

On Sun, Jun 22, 2003 at 03:36:07PM -0400, Peter Barada wrote:
> 
> >Yes, probably.  But Dan raises a valid point.  I wonder if it would
> >make sense to disable the unwind library entirely when inhibit_libc 
> >is true.  The trouble with that is I don't know what unwind-related
> >things are lurking in corners of glibc.
> 
> All this talk is aboutn trying to get a 'bootstrap' compiler useful to
> build glibc.  Once glibc is build, the standard cross-compiler build
> method is to go back and build up a complete compiler(that includes
> the unwind stuff). So not having the unwind library shouldn't impose
> any problems on *building* glibc.  Running glibc is another matter.
> 
> What am I missing here?

Unless the code ends up _included_ in glibc.

Or in any of the dozens of little applications built at the same time
as glibc, for instance.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: cross-compilation documentation

[Peter Barada]

>Yes, probably.  But Dan raises a valid point.  I wonder if it would
>make sense to disable the unwind library entirely when inhibit_libc 
>is true.  The trouble with that is I don't know what unwind-related
>things are lurking in corners of glibc.

All this talk is aboutn trying to get a 'bootstrap' compiler useful to
build glibc.  Once glibc is build, the standard cross-compiler build
method is to go back and build up a complete compiler(that includes
the unwind stuff). So not having the unwind library shouldn't impose
any problems on *building* glibc.  Running glibc is another matter.

What am I missing here?

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Zack Weinberg]

Dan Kegel <dank@kegel.com> writes:

> Zack Weinberg wrote:
>> Andrew Pinski <pinskia@physics.uc.edu> writes:
>>>RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux.h,v
>>> -#ifdef IN_LIBGCC2
>>>+#if defined (IN_LIBGCC2) && !defined (inhibit_libc)
>>> #include <signal.h>
>>> ...
>> For what it's worth, that looks like the right fix to this immediate
>> problem.  We want to decouple libgcc build from compiler build for
>> other reasons, but that's sufficiently invasive that it's probably a
>> 3.5 item at this point (the way I wanna do it, it needs bootstrap to
>> run at top level, and it involves moving a lot of files).
>
> If this is the right way to go, then you need to patch
> not just rs6000, but also just about every other architecture,
> don't you?

Yes, probably.  But Dan raises a valid point.  I wonder if it would
make sense to disable the unwind library entirely when inhibit_libc 
is true.  The trouble with that is I don't know what unwind-related
things are lurking in corners of glibc.

zw

Re: cross-compilation documentation

[Dan Kegel]

Zack Weinberg wrote:
> Andrew Pinski <pinskia@physics.uc.edu> writes:
>>RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux.h,v
>> 
>>-#ifdef IN_LIBGCC2
>>+#if defined (IN_LIBGCC2) && !defined (inhibit_libc)
>> #include <signal.h>
>> ...
> 
> For what it's worth, that looks like the right fix to this immediate
> problem.  We want to decouple libgcc build from compiler build for
> other reasons, but that's sufficiently invasive that it's probably a
> 3.5 item at this point (the way I wanna do it, it needs bootstrap to
> run at top level, and it involves moving a lot of files).

If this is the right way to go, then you need to patch
not just rs6000, but also just about every other architecture,
don't you?
I did verify just now that --without-headers fails with gcc-3.3
when building for alpha, for instance.  The error message is

In file included from tconfig.h:18,
                  from /build/alpha-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/gcc-3.3/gcc/libgcc2.c:36:
/build/alpha-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/gcc-3.3/gcc/config/alpha/linux.h:68:20: signal.h: No such file or directory
/build/alpha-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/gcc-3.3/gcc/config/alpha/linux.h:69:26: sys/ucontext.h: No such file or directory
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory `/home3/dank/crosstool-0.7/build/alpha-unknown-linux-gnu/gcc-3.3-glibc-2.3.2/build-gcc-core/gcc'

I'm going to keep on installing bootstrap glibc headers
for now, even though it's arcane and undocumented.

BTW, there is a PR for --without-headers not working; see
http://gcc.gnu.org/PR8180
IMHO this is a regression from gcc-3.2.3, and deserves
at least a documented workaround for the very next release,
even if we can't do a real fix until 3.5.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Dara Hazeghi]

--- Andrew Pinski <pinskia@physics.uc.edu> wrote:
> It is documented, just not fully:
> 
> "that each --with option has a corresponding
> --without option"
> 
Precisely my point. This interpretation does not seem
at all obvious to me, and, I suspect, to others. IMHO,
we should have a much clearer description for options
like these.

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: cross-compilation documentation

[Daniel Jacobowitz]

On Sun, Jun 22, 2003 at 01:21:51PM -0400, Andrew Pinski wrote:
> 
> On Sunday, Jun 22, 2003, at 13:09 US/Eastern, Peter Barada wrote:
> 
> >
> >>No you do not have install the headers because you can pass to gcc
> >>--without-headers and that will make sure that you do not compile
> >>the sources that require glibc's headers.
> >>
> >>So total process is:
> >>cd gccobjdir
> >>.../gcc-sources/configure --without-headers --target=???-linux-gnu
> >>--prefix=??? --enable-languages=c
> >
> >That doesn't work (at least for ppc-linux) since
> >gcc-3.3/config/rs6000/linux.h #includes <signal.h> when building
> >libgcc2, which causes it to fail since there are no headers(yet).
> >
> >The *real* solution is to suppress building libgcc as part of the
> >cross compilation bootstrap so the circular dependency of
> >compiler-headers-compiler is broken.
> >I have succeeded in building a ppc-linux target by tweaking the
> >obj/gcc-bootstrap/gcc/Makefile to suppress the definitions of LIBGCC
> >and INSTALL_LIBGCC(the following fragment from my master build 
> >Makefile):
> >
> >fix-bootstrap1-makefile:
> >	cd ${BOOTSTRAP1_BUILDDIR}/gcc ; \
> >	sed -e '1,$$s/^LIBGCC =/# LIBGCC =/;1,$$s/^INSTALL_LIBGCC =/# 
> >INSTALL_LIBGCC =/' < Makefile > Makefile.new ; \
> >	mv Makefile.new Makefile
> >
> >I'm working(slowly) on adding a --without-libgcc to gcc/configure to
> >do this...
> 
> That is a bug in the config of rs6000 of gcc which should be fixed,
> I have a patch for it and there is no need for --without-libgcc:
> 
> try this patch:

This has been discussed numerous times.  The conclusion was that, no,
it is _NOT_ a bug in the rs6000 port to require these headers.  I filed
one PR about it which was eventually closed.

Dan's doing it the right way.  Building a libgcc which doesn't support
signal unwinding can get you into all sorts of subtle trouble later.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: cross-compilation documentation

[Zack Weinberg]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> try this patch:
>
> Index: linux.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux.h,v
> retrieving revision 1.41
> diff -u -r1.41 linux.h
> --- linux.h	17 Jun 2003 15:53:33 -0000	1.41
> +++ linux.h	22 Jun 2003 17:17:41 -0000
> @@ -91,7 +91,7 @@
>  /* Do code reading to identify a signal frame, and set the frame
>     state data appropriately.  See unwind-dw2.c for the structs.  */
>  
> -#ifdef IN_LIBGCC2
> +#if defined (IN_LIBGCC2) && !defined (inhibit_libc)
>  #include <signal.h>
>  
>  /* During the 2.5 kernel series the kernel ucontext was changed, but
>

For what it's worth, that looks like the right fix to this immediate
problem.  We want to decouple libgcc build from compiler build for
other reasons, but that's sufficiently invasive that it's probably a
3.5 item at this point (the way I wanna do it, it needs bootstrap to
run at top level, and it involves moving a lot of files).

zw

Re: cross-compilation documentation

[Jan-Benedict Glaw]

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

On Sun, 2003-06-22 13:21:51 -0400, Andrew Pinski <pinskia@physics.uc.edu>
wrote in message <02F74B2F-A4D6-11D7-AD8C-000393A6D2F2@physics.uc.edu>:
> On Sunday, Jun 22, 2003, at 13:09 US/Eastern, Peter Barada wrote:
> 
> That is a bug in the config of rs6000 of gcc which should be fixed,
> I have a patch for it and there is no need for --without-libgcc:
[...]

grepping a bit, I think this is not only a problem of pcc-linux:

jbglaw@b132l-1:~/toolchain-sources/gcc/gcc/config$ find . -type f -name linux.h -exec grep -Hi -B 5 signal.h {} \;
./alpha/linux.h-
./alpha/linux.h-/* Do code reading to identify a signal frame, and set the frame
./alpha/linux.h-   state data appropriately.  See unwind-dw2.c for the structs.  */
./alpha/linux.h-
./alpha/linux.h-#ifdef IN_LIBGCC2
./alpha/linux.h:#include <signal.h>
./i386/linux.h-/* There's no sys/ucontext.h for some (all?) libc1, so no
./i386/linux.h-   signal-turned-exceptions for them.  There's also no configure-run for
./i386/linux.h-   the target, so we can't check on (e.g.) HAVE_SYS_UCONTEXT_H.  Using the
./i386/linux.h-   target libc1 macro should be enough.  */
./i386/linux.h-#ifndef USE_GNULIBC_1
./i386/linux.h:#include <signal.h>
./ia64/linux.h-
./ia64/linux.h-/* Do code reading to identify a signal frame, and set the frame
./ia64/linux.h-   state data appropriately.  See unwind-dw2.c for the structs.  */
./ia64/linux.h-
./ia64/linux.h-#ifdef IN_LIBGCC2
./ia64/linux.h:#include <signal.h>
./rs6000/linux.h-
./rs6000/linux.h-/* Do code reading to identify a signal frame, and set the frame
./rs6000/linux.h-   state data appropriately.  See unwind-dw2.c for the structs.  */
./rs6000/linux.h-
./rs6000/linux.h-#ifdef IN_LIBGCC2
./rs6000/linux.h:#include <signal.h>
./sh/linux.h-
./sh/linux.h-/* Do code reading to identify a signal frame, and set the frame
./sh/linux.h-   state data appropriately.  See unwind-dw2.c for the structs.  */
./sh/linux.h-
./sh/linux.h-#ifdef IN_LIBGCC2
./sh/linux.h:#include <signal.h>
jbglaw@b132l-1:~/toolchain-sources/gcc/gcc/config$


Iff the fix correctly fixes this behavior, it would be nice if you could
please also fix the other architectures gcc has Linux support for.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cross-compilation documentation

[Jan-Benedict Glaw]

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

On Sun, 2003-06-22 13:19:50 -0400, Andrew Pinski <pinskia@physics.uc.edu>
wrote in message <BB15CB3A-A4D5-11D7-AD8C-000393A6D2F2@physics.uc.edu>:
> It is documented, just not fully:
> 
> "that each --with option has a corresponding --without option"
> 
> --with-headers
> --with-headers=dir
> Deprecated in favor of --with-sysroot.  Specifies that target headers 
> are available when building a cross compiler.  The dir argument 
> specifies a directory which has the target include files.  These 
> include files will be copied into the gcc install directory.  This 
> option with the dir argument is required when building a cross 
> compiler, if prefix/target/sys-include doesn't pre-exist.  If 
> prefix/target/sys-include does pre-exist, the dir argument may be 
> omitted.  fixincludes will be run on these files to make them 
> compatible with GCC.

<USER type="newbie">
	Say I want to give --with-headers, what exactly should I place
	there, in which structure? Let's start with some example
	combination: Linux as the OS and arm as it's platform. I do have
	nothing but kernel and glibc sources.

	How (and which) glibc headers shall I fetch? Taken those which
	would appear in /usr/include/ at a target system, should I place
	these into the directory I specify at --with-headers? ...or do I
	have to place them into <--with-headers-DIR>/usr/include/ ?
	
	How do I have to treat Linux headers? All headers? Only the
	./include/linux/ part? The ./include/linux/asm part? (How shall
	I do this for ARM where, in 2.5.x, we have subarch support?)
	What's about the asm-generic part? Where to place those?
</USER>

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cross-compilation documentation

[Andrew Pinski]

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


On Sunday, Jun 22, 2003, at 13:09 US/Eastern, Peter Barada wrote:

>
>> No you do not have install the headers because you can pass to gcc
>> --without-headers and that will make sure that you do not compile
>> the sources that require glibc's headers.
>>
>> So total process is:
>> cd gccobjdir
>> .../gcc-sources/configure --without-headers --target=???-linux-gnu
>> --prefix=??? --enable-languages=c
>
> That doesn't work (at least for ppc-linux) since
> gcc-3.3/config/rs6000/linux.h #includes <signal.h> when building
> libgcc2, which causes it to fail since there are no headers(yet).
>
> The *real* solution is to suppress building libgcc as part of the
> cross compilation bootstrap so the circular dependency of
> compiler-headers-compiler is broken.
> I have succeeded in building a ppc-linux target by tweaking the
> obj/gcc-bootstrap/gcc/Makefile to suppress the definitions of LIBGCC
> and INSTALL_LIBGCC(the following fragment from my master build 
> Makefile):
>
> fix-bootstrap1-makefile:
> 	cd ${BOOTSTRAP1_BUILDDIR}/gcc ; \
> 	sed -e '1,$$s/^LIBGCC =/# LIBGCC =/;1,$$s/^INSTALL_LIBGCC =/# 
> INSTALL_LIBGCC =/' < Makefile > Makefile.new ; \
> 	mv Makefile.new Makefile
>
> I'm working(slowly) on adding a --without-libgcc to gcc/configure to
> do this...

That is a bug in the config of rs6000 of gcc which should be fixed,
I have a patch for it and there is no need for --without-libgcc:

try this patch:

[-- Attachment #2: temp.linux.diff --]
[-- Type: application/octet-stream, Size: 585 bytes --]

Index: linux.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/linux.h,v
retrieving revision 1.41
diff -u -r1.41 linux.h
--- linux.h	17 Jun 2003 15:53:33 -0000	1.41
+++ linux.h	22 Jun 2003 17:17:41 -0000
@@ -91,7 +91,7 @@
 /* Do code reading to identify a signal frame, and set the frame
    state data appropriately.  See unwind-dw2.c for the structs.  */
 
-#ifdef IN_LIBGCC2
+#if defined (IN_LIBGCC2) && !defined (inhibit_libc)
 #include <signal.h>
 
 /* During the 2.5 kernel series the kernel ucontext was changed, but

[-- Attachment #3: Type: text/plain, Size: 64 bytes --]



I will submit it if it works for you.


Thanks,
Andrew Pinski

Re: cross-compilation documentation

[Jan-Benedict Glaw]

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

On Sun, 2003-06-22 10:10:25 -0700, Dara Hazeghi <dhazeghi@yahoo.com>
wrote in message <20030622171025.90489.qmail@web41110.mail.yahoo.com>:
> >No you do not have install the headers because you
> can pass to gcc
> >--without-headers and that will make sure that you do
> not compile
> >the sources that require glibc's headers.
> 
> Where is this documented? I don't see any reference at
> http://gcc.gnu.org/install/configure.html.

Wait on that:) Seems that doesn't even help always, see the signal.h
problem mentioned in this thread:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cross-compilation documentation

[Andrew Pinski]

It is documented, just not fully:

"that each --with option has a corresponding --without option"

--with-headers
--with-headers=dir
Deprecated in favor of --with-sysroot.  Specifies that target headers 
are available when building a cross compiler.  The dir argument 
specifies a directory which has the target include files.  These 
include files will be copied into the gcc install directory.  This 
option with the dir argument is required when building a cross 
compiler, if prefix/target/sys-include doesn't pre-exist.  If 
prefix/target/sys-include does pre-exist, the dir argument may be 
omitted.  fixincludes will be run on these files to make them 
compatible with GCC.

Thanks,
Andrew Pinski


On Sunday, Jun 22, 2003, at 13:10 US/Eastern, Dara Hazeghi wrote:

>> No you do not have install the headers because you
> can pass to gcc
>> --without-headers and that will make sure that you do
> not compile
>> the sources that require glibc's headers.
>
> Where is this documented? I don't see any reference at
> http://gcc.gnu.org/install/configure.html.
>
> Dara
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>

Re: cross-compilation documentation

[Dara Hazeghi]

>No you do not have install the headers because you
can pass to gcc
>--without-headers and that will make sure that you do
not compile
>the sources that require glibc's headers.

Where is this documented? I don't see any reference at
http://gcc.gnu.org/install/configure.html.

Dara

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: cross-compilation documentation

[Peter Barada]

>No you do not have install the headers because you can pass to gcc
>--without-headers and that will make sure that you do not compile
>the sources that require glibc's headers.
>
>So total process is:
>cd gccobjdir
>.../gcc-sources/configure --without-headers --target=???-linux-gnu 
>--prefix=??? --enable-languages=c

That doesn't work (at least for ppc-linux) since
gcc-3.3/config/rs6000/linux.h #includes <signal.h> when building
libgcc2, which causes it to fail since there are no headers(yet).

The *real* solution is to suppress building libgcc as part of the
cross compilation bootstrap so the circular dependency of
compiler-headers-compiler is broken.
I have succeeded in building a ppc-linux target by tweaking the
obj/gcc-bootstrap/gcc/Makefile to suppress the definitions of LIBGCC
and INSTALL_LIBGCC(the following fragment from my master build Makefile):

fix-bootstrap1-makefile:
	cd ${BOOTSTRAP1_BUILDDIR}/gcc ; \
	sed -e '1,$$s/^LIBGCC =/# LIBGCC =/;1,$$s/^INSTALL_LIBGCC =/# INSTALL_LIBGCC =/' < Makefile > Makefile.new ; \
	mv Makefile.new Makefile

I'm working(slowly) on adding a --without-libgcc to gcc/configure to
do this...

-- 
Peter Barada
peter@baradas.org

Re: cross-compilation documentation

[Jan-Benedict Glaw]

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

On Sun, 2003-06-22 09:31:32 -0700, Dan Kegel <dank@kegel.com>
wrote in message <3EF5D9E4.7020906@kegel.com>:
> The Linux target is interesting because you can build absolutely
> everything from virgin source tarballs.  It's a challenge, though:
> you have to install just the glibc headers so you can
> compile a bootstrap gcc so you can
> compile glibc so you can (finally!) compile gcc.
> That first step, installing bootstrap glibc headers, is a new
> and annoying prerequisite as of gcc-3.3. See
> http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html
> for my rant on the subject.

ACK.

_But_ it's even worse that there's no[1] strict documentation on how to
get a working cross-compiler. There are some "interesting"
configurations which should have easily findable documentation.
(Extensive --with-sysroot docs?).

For me, toying mostly with around with Linux, my top wishlist is:

	- Building a Linux kernel-only cross compiler on my i386-linux
	  box for some {mips|ppc|m68k|...}-linux target running
	  efficiently on the box I build it on (BUILD == HOST).
	- Building a Linux kernel-only cross compiler on my i386-linux
	  box for some {mips|ppc|m68k|...}-linux target running
	  on any i386-like Linux machine (BUILD != HOST). So I can
	  easily copy this binutils/compiler suite to some other box.

	- Building a full cross compiler (including userland and all
	  sensefull languages) with BUILD == HOST as well as BULID !=
	  HOST, but also keeping in mind that BUILD and HOST are nearly
	  identical:)

So basically I don't need a full Canadian Cross configuration. The
"simple" version would be enough for me.

For all those who are trying to build cross compilers, you may find
helpfull hints at my link list here:
http://lug-owl.de/~jbglaw/linux-ports/#EasilyBuildableCrossToolchains

MfG, JBG
[1] When I looked at GCCs docs, I either oversaw helpful hints, or they
simply didn't exist.

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cross-compilation documentation

[Dan Kegel]

Andrew Pinski wrote:
>> That first step, installing bootstrap glibc headers, is a new
>> and annoying prerequisite as of gcc-3.3. See
>> http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html
>> for my rant on the subject.
> 
> No you do not have install the headers because you can pass to gcc
> --without-headers and that will make sure that you do not compile
> the sources that require glibc's headers.
> 
> So total process is:
> cd gccobjdir
> .../gcc-sources/configure --without-headers --target=???-linux-gnu 
> --prefix=??? --enable-languages=c
> make
> make install
> cd glibcobjdir
> .../glibc-sources/configure --target=???-linux-gnu --prefix=???
> make
> make install
> cd gccobjdir
> .../gcc-sources/configure --prefix=???

Ahh, thanks.  I'll try it.  That should speed up my build times
noticably, too, since just installing the glibc headers takes
about 10% of my run time.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Andrew Pinski]

On Sunday, Jun 22, 2003, at 12:31 US/Eastern, Dan Kegel wrote:

> Jim Wilson wrote:
>> Dan Kegel wrote:
>>> I understand that at the recent summit, cross-compilation
>>> documentation was listed as being an item of high priority.
>>> I've been working on this a bit; my current efforts are at
>>> http://kegel.com/crosstool
>> This looks useful.  It only covers the case where the target is 
>> GNU/Linux, but that is the case that is least well documented.
>
> The Linux target is interesting because you can build absolutely
> everything from virgin source tarballs.  It's a challenge, though:
> you have to install just the glibc headers so you can
> compile a bootstrap gcc so you can
> compile glibc so you can (finally!) compile gcc.
> That first step, installing bootstrap glibc headers, is a new
> and annoying prerequisite as of gcc-3.3. See
> http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html
> for my rant on the subject.

No you do not have install the headers because you can pass to gcc
--without-headers and that will make sure that you do not compile
the sources that require glibc's headers.

So total process is:
cd gccobjdir
.../gcc-sources/configure --without-headers --target=???-linux-gnu 
--prefix=??? --enable-languages=c
make
make install
cd glibcobjdir
.../glibc-sources/configure --target=???-linux-gnu --prefix=???
make
make install
cd gccobjdir
.../gcc-sources/configure --prefix=???


Thanks,
Andrew Pinski

Re: cross-compilation documentation

[Dan Kegel]

Jim Wilson wrote:
> Dan Kegel wrote:
> 
>> I understand that at the recent summit, cross-compilation
>> documentation was listed as being an item of high priority.
>> I've been working on this a bit; my current efforts are at
>> http://kegel.com/crosstool
> 
> This looks useful.  It only covers the case where the target is 
> GNU/Linux, but that is the case that is least well documented.

The Linux target is interesting because you can build absolutely
everything from virgin source tarballs.  It's a challenge, though:
you have to install just the glibc headers so you can
compile a bootstrap gcc so you can
compile glibc so you can (finally!) compile gcc.
That first step, installing bootstrap glibc headers, is a new
and annoying prerequisite as of gcc-3.3. See
http://sources.redhat.com/ml/crossgcc/2003-06/msg00170.html
for my rant on the subject.

>> I'd like to get in touch with whoever is working on this
>> issue in the gcc team.
> 
> Which is probably no one.  You could try getting the process started by 
> submitting a patch for the documentation which covers the basic process. 
>  You could also consider contributing a script for the contrib directory.

Thanks, I will, once I have automated remote chroot testing working.
Gotta get that copyright assignment paperwork going, too.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Dan Kegel]

Joel Sherrill wrote:
> I have put a set of RPMs for a RedHat 7.3 hosted cross compiler
> targeting Solaris 2.8 at ftp://ftp.oarcorp.com/pub/rh73_to_solaris/.
> 
> There are source and binary RPMs for gcc and binutils but only a
> "nosrc" RPM for the libraries and include files you have to grab
> from Solaris.  You will have to provide that locally yourself since
> I shouldn't distribute those.
> 
> These RPMs are based upon binutils 2.13.2.1 and gcc 3.2.3.  They
> install into /opt/solaris and include C, C++, and Ada.

That does look pretty helpful for people targeting Solaris.
Worth linking to from the crossgcc faq.
You might consider adding an entry in the crossgcc wiki yourself;
see http://billgatliff.com/twiki/bin/view/Crossgcc/

Thanks,
Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: cross-compilation documentation

[Jim Wilson]

Dan Kegel wrote:
> I understand that at the recent summit, cross-compilation
> documentation was listed as being an item of high priority.
> I've been working on this a bit; my current efforts are at
> http://kegel.com/crosstool

This looks useful.  It only covers the case where the target is 
GNU/Linux, but that is the case that is least well documented.

> I'd like to get in touch with whoever is working on this
> issue in the gcc team.

Which is probably no one.  You could try getting the process started by 
submitting a patch for the documentation which covers the basic process. 
  You could also consider contributing a script for the contrib directory.

Jim

Re: cross-compilation documentation

[Joel Sherrill]

Dan Kegel wrote:
> 
> I understand that at the recent summit, cross-compilation
> documentation was listed as being an item of high priority.
> I've been working on this a bit; my current efforts are at
> http://kegel.com/crosstool
> I'd like to get in touch with whoever is working on this
> issue in the gcc team.

I have put a set of RPMs for a RedHat 7.3 hosted cross compiler
targeting Solaris 2.8 at ftp://ftp.oarcorp.com/pub/rh73_to_solaris/.

There are source and binary RPMs for gcc and binutils but only a
"nosrc" RPM for the libraries and include files you have to grab
from Solaris.  You will have to provide that locally yourself since
I shouldn't distribute those.

These RPMs are based upon binutils 2.13.2.1 and gcc 3.2.3.  They
install into /opt/solaris and include C, C++, and Ada.

I hope this helps someone out there.  

> Thanks,
> Dan
> 
> --
> Dan Kegel
> http://www.kegel.com
> http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

cross-compilation documentation

[Dan Kegel]

I understand that at the recent summit, cross-compilation
documentation was listed as being an item of high priority.
I've been working on this a bit; my current efforts are at
http://kegel.com/crosstool
I'd like to get in touch with whoever is working on this
issue in the gcc team.
Thanks,
Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Cross-compilation documentation

[Joseph S. Myers]

Is there anyone here familiar with the current practice for building
cross-compilers (including Canadian crosses, building in and out of common
source tree with binutils, dealing with libgcc depending on libc and libc
depending on libgcc, ...)?

If so, could you merge the existing old instructions in install-old.texi
into the current install manual install.texi, updating and expanding them
as necessary?  The continued presence of the old install documentation
that hasn't yet been merged into the new is now an obstacle to separating
the user and internals manuals (which I'd then follow by cleaning up the
structure of the internals manual and putting in the framework for proper
documentation of aspects not currently documented, such as the build
system and the front-end interface), since the structure of three manuals
(user, install, internals) for three different audiences has no place for
old install instructions in either the user of the internals manual.

-- 
Joseph S. Myers
jsm28@cam.ac.uk