Stephen,
I have been working on the x86_64-pc-mingw32 toolchain with Kai Tietz
(Kai is the main person, I am doing much more learning than helping).
I put together a built script that requires no tweaking whatsoever of
any of the projects incorporated in the toolchain. It is very
straightforward.
Rask Ingemann Lambertsen wrote:
On Sun, Aug 19, 2007 at 10:09:25AM +0200, Paolo Bonzini wrote:
Thanks for reminding me to ping that patch.
Could you try moving this case statement
+ case "$target" in
+ i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
+ libgloss_dir=i386
+
On Sun, Aug 19, 2007 at 10:09:25AM +0200, Paolo Bonzini wrote:
>
> > Thanks for reminding me to ping that patch.
>
> Could you try moving this case statement
>
> + case "$target" in
> + i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
> + libgloss_dir=i386
> + ;;
> + m
(Stephen typoed the gcc address, forwarding)
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: 21 augustus 2007 17:10:30 GMT+02:00
To: "Stephen M. Kenton" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Why is building a cross compiler "out-of-the-box&qu
On Mon, Aug 20, 2007 at 12:06:03PM +0300, Kai Ruottu wrote:
> If one tries to produce everything in the 'gcc' subdirectory, including
> 'libgcc',
> then headers may be needed. But if producing only the 'xgcc', 'cc1',
> 'collect2'
> etc binaries for the host is enough, then nothing for the target
Segher Boessenkool wrote:
The manual explicitly says you need to have target headers. With
all those --disable-XXX and especially --enable-sjlj-exceptions it
all works fine without, though.
If one tries to produce everything in the 'gcc' subdirectory, including
'libgcc',
then headers may be nee
Thanks, I git cloned buildall and it sure looks simple (now that you
have made it work) :-!
Good to see it is useful to more people than just me :-)
Although, that combination of options was not exactly obvious at first
glance.
Heh. Almost all of it is just "disable what we don't need". OT
Thanks, I git cloned buildall and it sure looks simple (now that you
have made it work) :-!
Although, that combination of options was not exactly obvious at first
glance. Time to re-read
all the config --help stuff.
I'll try it on my build system at work tomorrow and see what bites me
next. I
4. Use the minimal cross-compiler produced in step 3 to configure
glibc and do "make install-headers" to get glibc headers. At this
point you should be able to delete the minimal cross-compiler, it's
job has been done.
5. Make distclean and then configure, make, and install a normal gcc
cross
OK, let me recap as I understand the discussion up to now, realizing
that this is the gcc list we can really only hope to fix things, if
needed, by making changes to the gcc project. Other project will have
other priorities.
It sounds like the consensus is that bootstrapping a cross-compiler
Thanks for reminding me to ping that patch.
Could you try moving this case statement
+ case "$target" in
+ i[[3456]]86-*-elf* | i[[3456]]86-*-coff*)
+ libgloss_dir=i386
+ ;;
+ m68hc11-*-* | m6811-*-* | m68hc12-*-* | m6812-*-*)
+ libgloss_
On Sat, Aug 18, 2007 at 08:18:08PM +0200, Segher Boessenkool wrote:
> p.s. Any advice on how to get more targets working would be
> more than welcome :-)
With patch three from bug 32154
http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669>, the newlib
targets build out of the box in a combined
So, my open questions to the list are, what is/should be the preferred
way to bootstrap a cross compiler/glibc environment?
This likely isn't the preferred way, but the following builds
a cross toolchain for all but a few Linux targets:
$SRC/src/configure \
--target=$TARGET --prefix=$P
On Friday 17 August 2007 23:56:30 Ian Lance Taylor wrote:
> "Stephen M. Kenton" <[EMAIL PROTECTED]> writes:
>
> > However, the question
> > remains, why is the problem still there to be circumvented? Is there
> > some secret opposition to easy use of these tools, is there some law
> > of nature t
Andrew Haley wrote:
David Daney writes:
> Stephen M. Kenton wrote:
> > Hello all,
> >
> .
> .
> .
> > I realize that there are various "solutions" for specific
> > platforms. Dan Kegel's excellent crosstool and the cross-lfs website,
> >
> .
> .
> .
> >
> > So, my open quest
David Daney writes:
> Stephen M. Kenton wrote:
> > Hello all,
> >
> .
> .
> .
> > I realize that there are various "solutions" for specific
> > platforms. Dan Kegel's excellent crosstool and the cross-lfs website,
> >
> .
> .
> .
> >
> > So, my open questions to the list are, wh
Andrew Pinski wrote:
On 8/17/07, Stephen M. Kenton <[EMAIL PROTECTED]> wrote:
Cross compiling works for me out of the box if done correctly. Yes I
have to compile GCC and glibc (or newlib) twice but I don't care as it
is all scripted.
Thanks,
Andrew Pinski
Great! Scripting is wonderful and
"Stephen M. Kenton" <[EMAIL PROTECTED]> writes:
> However, the question
> remains, why is the problem still there to be circumvented? Is there
> some secret opposition to easy use of these tools, is there some law
> of nature that prevents them from building, is there some good
> technical reason
Stephen M. Kenton wrote:
Hello all,
.
.
.
I realize that there are various "solutions" for specific
platforms. Dan Kegel's excellent crosstool and the cross-lfs website,
.
.
.
So, my open questions to the list are, what is/should be the preferred
way to bootstrap a cross compiler/glibc
On 8/17/07, Stephen M. Kenton <[EMAIL PROTECTED]> wrote:
Cross compiling works for me out of the box if done correctly. Yes I
have to compile GCC and glibc (or newlib) twice but I don't care as it
is all scripted.
Thanks,
Andrew Pinski
Hello all,
Several years ago in the gcc 3.3 time frame I looked into building cross
compilers using the current versions of gcc, glibc etc. for a number of
different systems. I quickly found that it was a quagmire. I inquired
of this list at that time and was told that the glibc hack was
pr
21 matches
Mail list logo
