On 08/12/2011 06:25 PM, H.J. Lu wrote:
>
> I prefer to wait for testing results to commit it, the breakage is minor.
It bootstraps successfully with "make -j12" on a 24 core machine.
Thanks.
Committed.
Paolo
On Fri, Aug 12, 2011 at 8:57 AM, Paolo Bonzini wrote:
> On 08/12/2011 05:50 PM, H.J. Lu wrote:
>>
>> > Thanks, you are correct.
>>
>> It should work.
>>
>> Thanks.
>
> I prefer to wait for testing results to commit it, the breakage is minor.
It bootstraps successfully with "make -j12" on a 24 co
On Friday 12 August 2011 16:40:33, Paolo Bonzini wrote:
> install-unwind_h:
> - rm -f $(gcc_objdir)/include/unwind.h
> - cp unwind.h $(gcc_objdir)/include/unwind.h
> - chmod a+r $(gcc_objdir)/include/unwind.h
> + dest=$(gcc_objdir)/include/tmp-unwind.h; \
> + cp u
On 08/12/2011 05:50 PM, H.J. Lu wrote:
> Thanks, you are correct.
It should work.
Thanks.
I prefer to wait for testing results to commit it, the breakage is minor.
Paolo
On Fri, Aug 12, 2011 at 8:40 AM, Paolo Bonzini wrote:
>>> Can't this sequence happen?
>>>
>>> proc1: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc2: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc1: sh $(srcdir)/../move-if-change \
>>> $(gcc_objdir
Can't this sequence happen?
proc1: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2: cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1: sh $(srcdir)/../move-if-change \
$(gcc_objdir)/include/tmp-unwind.h \
$(gcc_objdir)/include/unwind.h
proc2
On Fri, Aug 12, 2011 at 5:38 AM, Pedro Alves wrote:
> On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
>> 2011-08-12 Paolo Bonzini
>>
>> * Makefile.in (install-unwind_h): Create
>> $(gcc_objdir)/include/unwind.h
>> atomically.
>>
>> Index: Makefile.in
>> ==
On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
> 2011-08-12 Paolo Bonzini
>
> * Makefile.in (install-unwind_h): Create
> $(gcc_objdir)/include/unwind.h
> atomically.
>
> Index: Makefile.in
> ===
> --- M
On 08/12/2011 02:13 PM, H.J. Lu wrote:
We may have a race condition here.
I opened:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
Does the attached patch work?
Can you provide a patch instead of the whole Makefile.in?
Sorry, that was not intended.
Paolo
2011-08-12 Paolo Bonzini
On Fri, Aug 12, 2011 at 12:04 AM, Paolo Bonzini wrote:
> On 08/11/2011 08:24 PM, H.J. Lu wrote:
>>
>> On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote:
>>>
>>> On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
>>> wrote:
Paolo Bonzini writes:
> On 08/10/2011 06:05 PM, Rainer Orth
On 08/11/2011 08:24 PM, H.J. Lu wrote:
On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote:
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
wrote:
Paolo Bonzini writes:
On 08/10/2011 06:05 PM, Rainer Orth wrote:
True: it is called once per multilib.
Just to doublecheck, are we sure that u
On Thu, Aug 11, 2011 at 20:19, H.J. Lu wrote:
> On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
> wrote:
>> Paolo Bonzini writes:
>>
>>> On 08/10/2011 06:05 PM, Rainer Orth wrote:
>> >> True: it is called once per multilib.
> >
> > Just to doublecheck, are we sure that unwind.h is alw
On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote:
> On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
> wrote:
>> Paolo Bonzini writes:
>>
>>> On 08/10/2011 06:05 PM, Rainer Orth wrote:
>> >> True: it is called once per multilib.
> >
> > Just to doublecheck, are we sure that unwind.h is
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
wrote:
> Paolo Bonzini writes:
>
>> On 08/10/2011 06:05 PM, Rainer Orth wrote:
> >> True: it is called once per multilib.
>
> Just to doublecheck, are we sure that unwind.h is always the same?
>>> Yep: it's unwind-generic.h for almost a
Paolo Bonzini writes:
> Writing that down in a wiki page (even as unformatted text) would be
> useful.
While I'm not too fond of WiKis, I've added some text to
http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration
It's ugly right now, but better than nothing.
Rainer
--
---
On 08/11/2011 05:26 PM, Rainer Orth wrote:
> Actually I think the installation of all the installed target headers
> should move to libgcc's Makefiles (and the headers themselves should move
> under the libgcc/ directory).
Agreed, added to my ever-growing todo list for the libgcc move. Thi
"Joseph S. Myers" writes:
> Actually I think the installation of all the installed target headers
> should move to libgcc's Makefiles (and the headers themselves should move
> under the libgcc/ directory).
Agreed, added to my ever-growing todo list for the libgcc move. This
would be
* gcc/gi
Paolo Bonzini writes:
> On 08/10/2011 06:05 PM, Rainer Orth wrote:
>> True: it is called once per multilib.
>>> >
>>> > Just to doublecheck, are we sure that unwind.h is always the same?
>> Yep: it's unwind-generic.h for almost all targets, just a few arm
>> targets use config/arm/unwind-a
On Thu, 11 Aug 2011, Paolo Bonzini wrote:
> On 08/11/2011 04:25 PM, Joseph S. Myers wrote:
> > > The actual problem are not the runtime libraries, which already know to
> > > search $builddir/.../libgcc for unwind.h and related files. The
> > > copyback is only for the benefit of the testsuite
"Joseph S. Myers" writes:
> On Thu, 11 Aug 2011, Rainer Orth wrote:
>
>> The actual problem are not the runtime libraries, which already know to
>> search $builddir/.../libgcc for unwind.h and related files. The
>> copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
>> gnat.dg
On 08/11/2011 04:25 PM, Joseph S. Myers wrote:
> The actual problem are not the runtime libraries, which already know to
> search $builddir/.../libgcc for unwind.h and related files. The
> copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
> gnat.dg, and gcc.dg) where I w
On Thu, 11 Aug 2011, Rainer Orth wrote:
> The actual problem are not the runtime libraries, which already know to
> search $builddir/.../libgcc for unwind.h and related files. The
> copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
> gnat.dg, and gcc.dg) where I was too lazy
Paolo Bonzini writes:
> On 08/10/2011 06:50 PM, Pedro Alves wrote:
>> On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
>>> > Paolo Bonzini writes:
>>> >
> > >> True: it is called once per multilib.
> >
> > Just to doublecheck, are we sure that unwind.h is always the s
On 08/10/2011 06:50 PM, Pedro Alves wrote:
On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
> Paolo Bonzini writes:
>
> >> True: it is called once per multilib.
> >
> > Just to doublecheck, are we sure that unwind.h is always the same?
>
> Yep: it's unwind-generic.h for almost
On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
> Paolo Bonzini writes:
>
> >> True: it is called once per multilib.
> >
> > Just to doublecheck, are we sure that unwind.h is always the same?
>
> Yep: it's unwind-generic.h for almost all targets, just a few arm
> targets use config/arm/
On 08/10/2011 06:05 PM, Rainer Orth wrote:
>> True: it is called once per multilib.
>
> Just to doublecheck, are we sure that unwind.h is always the same?
Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.
Patch doing rm
Paolo Bonzini writes:
>> True: it is called once per multilib.
>
> Just to doublecheck, are we sure that unwind.h is always the same?
Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.
Rainer
--
On 08/10/2011 03:56 PM, Rainer Orth wrote:
"Joseph S. Myers" writes:
This is strange: they copy explicitly goes into $(gcc_objdir): from
libgcc/Makefile.in:
install-unwind_h:
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r $(gcc_objdir)/include/unwind.h
For an in-tree
On Wed, 10 Aug 2011, Rainer Orth wrote:
> Could you try the obvious patch? It's probably quicker than me
> recreating the setup.
Actually I think it will be quicker for you to do this test.
--
Joseph S. Myers
jos...@codesourcery.com
"Joseph S. Myers" writes:
>> This is strange: they copy explicitly goes into $(gcc_objdir): from
>> libgcc/Makefile.in:
>>
>> install-unwind_h:
>> cp unwind.h $(gcc_objdir)/include/unwind.h
>> chmod a+r $(gcc_objdir)/include/unwind.h
>>
>> For an in-tree build, the source direct
On Wed, 10 Aug 2011, Rainer Orth wrote:
> "Joseph S. Myers" writes:
>
> > This appears to have brought back PR 26478, build failure with readonly
> > source directory:
> >
> > cp unwind.h ../../.././gcc/include/unwind.h
> > cp: cannot create regular file `../../.././gcc/include/unwind.h':
> >
"Joseph S. Myers" writes:
> This appears to have brought back PR 26478, build failure with readonly
> source directory:
>
> cp unwind.h ../../.././gcc/include/unwind.h
> cp: cannot create regular file `../../.././gcc/include/unwind.h': Permission
> denied
> make[4]: *** [install-unwind_h] Error
This appears to have brought back PR 26478, build failure with readonly
source directory:
cp unwind.h ../../.././gcc/include/unwind.h
cp: cannot create regular file `../../.././gcc/include/unwind.h': Permission
denied
make[4]: *** [install-unwind_h] Error 1
--
Joseph S. Myers
jos...@codesource
Andreas,
> The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
> I've verified that the resulting libgcc_s.so aggrees with the one
> produced by the 4.6 branch. Checked in as obvious.
in that case, ia64/t-eh-ia64 should be removed since it's overridden
completely and only serve
The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
I've verified that the resulting libgcc_s.so aggrees with the one
produced by the 4.6 branch. Checked in as obvious.
Andreas.
2011-08-09 Andreas Schwab
* config.host (ia64*-*-linux*): Move ia64/t-glibc after
Rainer Orth writes:
> Andreas Schwab writes:
>
>> It's already fixed, 'twas the missing ldflags.
>
> I see, so I wasn't the only victim :-)
Unfortunately it didn't really fix it, the undefined symbol is still
present in libgcc_s.so. I'll experiment with the config file juggling.
Andreas.
--
Richard Sandiford writes:
> Rainer Orth writes:
>> * config.host (unwind_header): New variable.
>> (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
>> (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
>> *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
>>
Andreas Schwab writes:
> It's already fixed, 'twas the missing ldflags.
I see, so I wasn't the only victim :-)
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Paolo Bonzini writes:
> On 08/06/2011 05:07 PM, Mikael Morin wrote:
>> On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
>>> Can you try this instead?
>> It works. Thanks
>
> Committed, thanks.
Thanks for fixing this.
Rainer
--
--
It's already fixed, 'twas the missing ldflags.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab writes:
> I'm seeing this bootstrap failure on ia64 (configured with
> --with-system-libunwind):
>
> /usr/local/gcc/gcc-20110806/Build/./prev-gcc/g++
> -B/usr/local/gcc/gcc-20110806/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/
> -nostdinc++
> -B/usr/local/gcc/gcc-20110806/Build
> I'm seeing this bootstrap failure on ia64 (configured with
> --with-system-libunwind):
> /usr/local/gcc/gcc-20110806/Build/./prev-gcc/libgcc_s.so: undefined referen=
> ce to `__libunwind__Unwind_Find_FDE'
> collect2: error: ld returned 1 exit status
> make[3]: *** [gengtype] Error 1
I get this
Thanks again for doing this.
Rainer Orth writes:
> * config.host (unwind_header): New variable.
> (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
> (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
> *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
>
On 08/06/2011 05:07 PM, Mikael Morin wrote:
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
Can you try this instead?
It works. Thanks
Committed, thanks.
Paolo
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
> Can you try this instead?
It works. Thanks
Mikael
On 08/06/2011 12:43 PM, Mikael Morin wrote:
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:
On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote:
I suppose it is this patch that breaks bootstrap
The culprit is indeed r177447.
Adding a -I flag? I suppose that makes sense even if crtstuf
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:
> On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote:
> > I suppose it is this patch that breaks bootstrap
The culprit is indeed r177447.
>
> Adding a -I flag? I suppose that makes sense even if crtstuff is
> moved soon to toplevel libgcc.
Ho
I'm seeing this bootstrap failure on ia64 (configured with
--with-system-libunwind):
/usr/local/gcc/gcc-20110806/Build/./prev-gcc/g++
-B/usr/local/gcc/gcc-20110806/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/
-nostdinc++
-B/usr/local/gcc/gcc-20110806/Build/prev-ia64-suse-linux/libstdc++-v3/src
On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote:
> I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2:
> /home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No
> such file or directory
>
> Fixed by the the following pat^Whack
> Index: crtstuff.c
> ==
On Wednesday 03 August 2011 15:32:45 Rainer Orth wrote:
> This is the revised/updated version of the patch originally posted at
>
> [build] Move unwinder to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
>
> and reposted as CFT at
>
> http://gcc.gnu
On 08/05/2011 01:46 PM, Rainer Orth wrote:
>> How should we proceed with this patch, especially given the quite
>> moderate comments from most affected target maintainers?
>
> ARM is the only target we should care a bit about. Any chance you can try
> cross-compiling it (with a combined tre
Paolo Bonzini writes:
>> How should we proceed with this patch, especially given the quite
>> moderate comments from most affected target maintainers?
>
> ARM is the only target we should care a bit about. Any chance you can try
> cross-compiling it (with a combined tree it should not be hard)?
On 08/03/2011 03:32 PM, Rainer Orth wrote:
It should incorporate all review comments and a few errors I've noticed
during final review have been corrected.
I've received approval for the Darwin bits, Steve successfully tested on
HP-UX/IA64 and Linux/IA64 at least bootstrapped. VMS/IA64 approval
> +++ b/libstdc++-v3/acinclude.m4
> @@ -685,9 +685,9 @@ AC_DEFUN([GLIBCXX_EXPORT_INCLUDES], [
>fi
>
># Stuff in the actual top level. Currently only used by libsupc++
> to
> - # get unwind* headers from the gcc dir.
> - #TOPLEVEL_INCLUDES='-I$(toplevel_srcdir)/gcc
> -I$(toplevel_srcdi
Hi Rainer,
How should we proceed with this patch, especially given the quite
moderate comments from most affected target maintainers?
I have no objections to the patch from an ARM or FRV point of view.
Cheers
Nick
This is the revised/updated version of the patch originally posted at
[build] Move unwinder to toplevel libgcc
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
and reposted as CFT at
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00201.html
It should incorporate all
56 matches
Mail list logo
