One appropriate default for --with-build-tools could be the same as
the defaults for --program-transform-name. A default native build
would use 'as', a default cross build would use '$target-as'. Most
people using --program-prefix would probably also pass the same value
to --with-build-tools.
Yes, this seems to meet the needs I expressed. Thanks, Jan
>>> Paolo Bonzini <[EMAIL PROTECTED]> 23.12.05 10:10:01 >>>
> One appropriate default for --with-build-tools could be the same as
> the defaults for --program-transform-name. A default native build
> would use 'as', a default cross build
On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote:
> On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote:
> > Hello!
> >
> > The new scheme to select target tools breaks building GCC for me. Maybe I
> > have an unusal setup. The problem in my case is that configure now cho
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
> 2) look into the --with-build-tools path, for both a Canadian cross and
> a native build. This defaults to $exec_prefix/$target/bin, so the
> default build tools (used in autoconf tests and by the being-built GCC)
> would be, if f
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GC
Hi all,
i'm going into holiday and i wish you all of the gcc-team a happy christmas
and thanks for all your work, even though it is still to early for christmas
wishes :).
cu,
Ronny Peine
Hi,
I have downloaded latest GCC and Binutils sources from FSF for M16C
port. Using these sources, I could successfully build the cross
toolchain i.e. m32c-elf-*.
However, I am facing a problem while accessing the "const" data and
hard-coded strings which by default get placed in section ".rod
On Fri, Dec 23, 2005 at 01:33:30PM +0100, Paolo Bonzini wrote:
> Gunther Nikl wrote:
> >
> >If the above isn't restricted to canadian cross, it looks good. This
> >should apply for a normal cross build as well: (build == host) != target
> >
> Yes. My distinction between native and cross, was more
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
> On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote:
> > On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote:
> > > Hello!
> > >
> > > The new scheme to select target tools breaks building GCC for me. Maybe I
>
Wait wait wait wait wait. This is a cross compiler. Are we mistakenly
running $prefix/bin/$target-as, which is a bad version, or are we
really running $prefix/bin/as, a program named "as"? If we're doing
that, let's fix that separately - it's a nasty bug!
Probably my configuration will not
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
> On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
> > Sorry for being vague, its a cross-compiler (build == host). The build
> > errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The
> > last successfu
Hi,
When bootstrapping rev. 109012 on ia64-linux (checked out around 9am GMT
today), I get
make[3]: Entering directory `/mnt/sda5/bonzo/obj-trunk/stage2-libdecnumber'
source='../../trunk/libdecnumber/decNumber.c' object='decNumber.o'
libtool=no /home/bonzo/local/obj-trunk/./prev-gcc/xgcc
-B/
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
Sorry for being vague, its a cross-compiler (build == host). The build
errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The
la
On Fri, Dec 23, 2005 at 03:50:50PM +0100, Paolo Bonzini wrote:
>
> >Wait wait wait wait wait. This is a cross compiler. Are we mistakenly
> >running $prefix/bin/$target-as, which is a bad version, or are we
> >really running $prefix/bin/as, a program named "as"? If we're doing
> >that, let's fi
On Fri, Dec 23, 2005 at 04:43:09PM +0100, Paolo Bonzini wrote:
> This, in turn, is the first that is found among:
>
> 1) the default assembler (--with-as)
>
> 2) an in-tree assembler
>
> 3) AS_FOR_TARGET
>
> 4) if host == target, AS (obsolete, should be covered by case 3)
>
> 5) if build == ho
The last diagnostic in 3.4.x I'm getting from g++ is this:
XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE:
XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[ \\t]+_ZTIP9CTemplateIhE
as shown here:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html
There are three xfails
> I am doing this in my own start-up code.
If you're not using my crt0.s then you REALLY need to at least look at
it and see where/how I copy all the ROM data into RAM so that you can
access it.
> However, this is not the expected behavior, especially when using
> hardware. My ".rodata" should b
The SPARC psABI defines that a caller must allocate the space for a
structure returned from the callee. If the callee sees the size marker
in the allocation matches the size of the return then it fills the slot.
If the size matches we return, if it doesn't match we return anyway but
add a fixed of
John Daniels wrote:
Hi,
It appears GCC 3.x no longer supports the
-fvtable-thunks option. Is gcc 3.x using thunks by
default for its vtable format? Also, can the
_G_USING_THUNKS macro no longer used to determine if
thunks are being used?
the updated C++ ABI always uses thunks. http://www.codes
Your request for Express Transfer from your Bank of Oklahoma account to your
bank account ending in 8794, has been received and is in process.
This process usually takes 6-8 working hours to complete but is dependent on
your account preferences.
See, Change or Cancel this Transfer at:
ht
> The last diagnostic in 3.4.x I'm getting from g++ is this:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[
> \\t]+_ZTIP9CTemplateIhE
> as shown here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html
>
> Some more info, the reason hpux only showed one XPASS in 3.4 seems to
> be that the regexp isn't correct to match the assembler syntax.
> Patches were installed on mainline but not in 3.4 for mmix and hpux:
> http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html
> http://gcc.gnu.org/ml/gcc
On Fri, Dec 23, 2005 at 02:27:41PM -0500, Kaveh R. Ghazi wrote:
> > Some more info, the reason hpux only showed one XPASS in 3.4 seems to
> > be that the regexp isn't correct to match the assembler syntax.
> > Patches were installed on mainline but not in 3.4 for mmix and hpux:
> > http://gcc.g
On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
> > PS: I'm going to try applying the patch to 3.4 and see if it fixes
> > tinfo1.C.
>
> Meanwhile I'm running a regression hunt for the fix on mainline, which
> is currently looking between 2005-07-29 and 2005-07-30. Perhaps that's
>
Snapshot gcc-4.1-20051223 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051223/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
> > > PS: I'm going to try applying the patch to 3.4 and see if it fixes
> > > tinfo1.C.
> >
> > Meanwhile I'm running a regression hunt for the fix on mainline,
> > which is currently looking between 2005-07-29 and 2005-07-30.
26 matches
Mail list logo
