public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Barada <peter@baradas.org>
To: drow@mvista.com
Cc: zack@codesourcery.com, dank@kegel.com, pinskia@physics.uc.edu,
	wilson@tuliptree.org, gcc@gcc.gnu.org
Subject: Re: cross-compilation documentation
Date: Mon, 23 Jun 2003 09:10:00 -0000	[thread overview]
Message-ID: <20030623024805.6D3E998DFD@baradas.org> (raw)
In-Reply-To: <20030622194204.GA7163@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 22 Jun 2003 15:42:04 -0400)


>> 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

  parent reply	other threads:[~2003-06-23  2:49 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-18  0:36 Dan Kegel
2003-06-18 14:58 ` Joel Sherrill
2003-06-22 17:10   ` Dan Kegel
2003-06-19  0:00 ` Jim Wilson
2003-06-22 17:12   ` Dan Kegel
2003-06-22 17:19     ` Andrew Pinski
2003-06-22 17:21       ` Dan Kegel
2003-06-22 17:35       ` Peter Barada
2003-06-22 17:50         ` Andrew Pinski
2003-06-22 17:56           ` Jan-Benedict Glaw
2003-06-22 18:07           ` Zack Weinberg
2003-06-22 20:15             ` Dan Kegel
2003-06-22 20:27               ` Zack Weinberg
2003-06-22 20:36                 ` Peter Barada
2003-06-22 21:10                   ` Daniel Jacobowitz
2003-06-23  3:06                     ` Dan Kegel
2003-06-23  4:08                       ` Jan-Benedict Glaw
2003-06-23  4:22                         ` Dan Kegel
2003-06-23  9:10                     ` Peter Barada [this message]
2003-06-23 12:20                       ` Dan Kegel
2003-06-23 12:15                         ` Peter Barada
2003-06-23 12:20                           ` Dan Kegel
2003-06-23 14:14                             ` Peter Barada
2003-06-23 15:38                               ` Hans-Peter Nilsson
2003-06-23 16:04                                 ` Dan Kegel
2003-06-23 16:11                                   ` Hans-Peter Nilsson
2003-06-23 15:57                               ` Dan Kegel
2003-06-23 13:01                           ` Daniel Jacobowitz
2003-06-23 14:14                             ` Peter Barada
2003-06-23 14:50                               ` Daniel Jacobowitz
2003-06-23 14:10                       ` Daniel Jacobowitz
2003-06-22 18:41           ` Daniel Jacobowitz
2003-06-22 17:30     ` Jan-Benedict Glaw
  -- strict thread matches above, loose matches on Subject: below --
2004-05-29  6:25 Dan Kegel
2004-05-29  6:57 ` Zack Weinberg
2004-06-01 16:35   ` Dan Kegel
2004-06-01 17:38 ` Dave Korn
2004-06-01 17:45   ` Peter Barada
2003-06-22 17:43 Dara Hazeghi
2003-06-22 17:49 ` Andrew Pinski
2003-06-22 17:53   ` Jan-Benedict Glaw
2003-06-24  5:26     ` Jim Wilson
2003-06-22 19:36   ` Dara Hazeghi
2003-06-27 12:13     ` Gerald Pfeifer
2003-06-22 17:49 ` Jan-Benedict Glaw
2001-11-13 16:21 Cross-compilation documentation Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030623024805.6D3E998DFD@baradas.org \
    --to=peter@baradas.org \
    --cc=dank@kegel.com \
    --cc=drow@mvista.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pinskia@physics.uc.edu \
    --cc=wilson@tuliptree.org \
    --cc=zack@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).