https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
Chris Johns changed:
What|Removed |Added
CC||chrisj at rtems dot org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78677
--- Comment #2 from Chris Johns ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Chris Johns from comment #0)
> > Some operating system, for example RTEMS, may fail to create a POSIX key if
> > not configured with enough
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
Some operating system, for example RTEMS, may fail to create a POSIX key if not
configured with enough resources. The lack of any error
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
Tiny issue.
Looking over cxxabi.h I noticed a link in a comment about __cxa_demangle is not
valid anymore:
* See http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81835
--- Comment #3 from Chris Johns ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Chris Johns from comment #0)
> > Tiny issue.
> >
> > Looking over cxxabi.h I noticed a link in a comment about __cxa_demangle is
> > not valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
--- Comment #5 from Chris Johns ---
I have decided to revisit this bug and see what the issue is. I cannot see how
to reopen the issue?
Using GNU sed on FreeBSD is not straight forward. It requires either building
by hand to a custom prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
--- Comment #6 from Chris Johns ---
Created attachment 41380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380=edit
Use awk to create compile args as sed is not working on FreeBSD
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
FreeBSD version is 11.0-RELEASE-p9.
Configure line is:
../gcc-7.1.0/configure --prefix=/build/rtems/tools/4.12-7.1
--bindir=/build/rtems/tools/4.12-7.1/bin
--exec_prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Chris Johns changed:
What|Removed |Added
CC||chrisj at rtems dot org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #19 from Chris Johns ---
(In reply to Francois-Xavier Coudert from comment #18)
> Adding ".NOTPARALLEL: install-headers" to the libstdc++ Makefile fixes it
> perfectly, from what we can see on our apple-darwin test machines. We've
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
Building on FreeBSD with results in the following error:
In file included from
../../gcc-7.2.0/gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
--- Comment #10 from Chris Johns ---
(In reply to Joel Sherrill from comment #9)
> Yes. I believe it is the same bug. Use of GNU sed specifics on a system
> without GNU sed.
>
> I don't know if that changes the resolution.
For this bug that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
--- Comment #7 from Chris Johns ---
Is this bug the same as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
As that bug states this issue is present on darwin and the patch I posted fixes
the issues on that host.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097
--- Comment #11 from Chris Johns ---
Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 has a patch using awk
that lets the build complete without an error.
The problem is still present on FreeBSD and darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #20 from Chris Johns ---
I have been testing the patch attached to RTEMS ticket
https://devel.rtems.org/ticket/3171 and it has built gcc once for ARM and then
it did not build for SPARC plus SPARC build can fail on different header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #27 from Chris Johns ---
(In reply to Jack Howarth from comment #25)
> (In reply to Chris Johns from comment #24)
> Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local
> is set to install-freestanding-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #24 from Chris Johns ---
I would welcome a patch attached to this ticket.
My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to build.
I have seen a build work however most fail with a range of headers that can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #38 from Chris Johns ---
(In reply to Jonathan Wakely from comment #36)
> Also, this strongly suggests the problem for RTEMS is different:
>
> (In reply to Chris Johns from comment #24)
> > I would welcome a patch attached to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #44 from Chris Johns ---
(In reply to Jonathan Wakely from comment #42)
> I think something else is going on here, and not a race condition in the
> makefile.
I agree. I see the failure after a few files have been built.
>
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #45 from Chris Johns ---
This simple hack as a test works for me with `-j 8` on an i7 without
.NOTPARALLEL:
--- gcc-7.2.0/libstdc++-v3/include/Makefile.am.orig 2017-10-27
15:30:16.0 +1100
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #50 from Chris Johns ---
I raised an Apple bug report last December, the number is 36163995. Nothing
useful has happened. I will ping the bug and ask what is happening.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #65 from Chris Johns ---
I am still seeing this issue with the patch
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00933.html applied to gcc-7.3.0
(RTEMS 5 [master]) tool builds. This is on Mojave and an fully updated Xcode.
The ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #67 from Chris Johns ---
(In reply to Jonathan Wakely from comment #66)
> Yes, I was afraid the RTEMS failures might be a different problem.
>
> Are the symptoms the same? i.e. missing C++ standard library headers?
>
Yes it seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #69 from Chris Johns ---
(In reply to Jonathan Wakely from comment #68)
> (In reply to Chris Johns from comment #67)
> > (In reply to Jonathan Wakely from comment #66)
> > > Yes, I was afraid the RTEMS failures might be a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #10 from Chris Johns ---
(In reply to Jonathan Wakely from comment #9)
> Created attachment 53103 [details]
> Fix lifetime bugs for non-TLS eh_globals
>
> Does this work?
That is a great way to solve this problem given the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #4 from Chris Johns ---
(In reply to Andrew Pinski from comment #3)
> Sounds like the order of deconstructors is wrong.
> Where is __cxxabiv1::__cxa_get_globals being called from that is the problem?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #6 from Chris Johns ---
(In reply to Andrew Pinski from comment #5)
> There has to be an ordering issue of the calling of the deconstructors vs
> the ordering of the constructors.
>
> Maybe the problem is the `eh_gloabls init`
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
RTEMS 6 with GCC 12 (gcc version 12.1.1 20220509 (RTEMS 6, RSB
e73a258a3aa4af8735b589a2d770571b2105ac5f, Newlib 64b2081) (GCC)) is calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109282
--- Comment #2 from Chris Johns ---
(In reply to Andrew Pinski from comment #1)
> move-if-change should work just fine with a normal POSIX shell ...
It does. Maybe it was not found?
> What is the error message with /bin/sh still there?
The
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
Created attachment 54753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54753=edit
Change sh to $(SHELL)
The libgcc Makefile.in has `sh` and not `$(SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109282
--- Comment #5 from Chris Johns ---
(In reply to Andrew Pinski from comment #4)
> My bet if you do /bin/sh you would also get into trouble too ...
I do not think it is /bin/sh but you are right with the link bring MacOS
blocking an exe that
31 matches
Mail list logo
