http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
Jeremy Huddleston changed:
What|Removed |Added
CC||jeremyhu at macports dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #9 from Jeremy Huddleston 2012-10-05
17:47:02 UTC ---
The one build config change on MP side that accompanied the version bump was
that we now build with --enable-libstdcxx-time for
http://trac.macports.org/ticket/36364
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #13 from Jeremy Huddleston Sequoia
2012-10-06 06:38:54 UTC ---
I see this issue with older gcc47 versions that predate the bump to 4.7.2 and
addition of --enable-libstdcxx-time, specifically:
$ g++-mp-4.7 --version
g++-mp-4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #16 from Jeremy Huddleston Sequoia
2012-10-06 17:47:52 UTC ---
(In reply to comment #14)
> Interestingly Macports' libgomp shows the same expected emutls related symbols
> as fink...
>
> % nm libgomp.1.dylib | grep emutls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #18 from Jeremy Huddleston Sequoia
2012-10-06 19:53:25 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > > These changes will certainly keep config.h in the libstdc++-v3 build
> > > directory
> > > from having
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #21 from Jeremy Huddleston Sequoia
2012-10-06 21:14:30 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> > Note that the libgcc_ext.10.[45] are not actually needed if we're going to
> > be
> > using the libgcc r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #22 from Jeremy Huddleston Sequoia
2012-10-06 21:15:02 UTC ---
In any event, this is a MacPorts bug for which I have a fix. This upstream bug
should be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #4 from Jeremy Huddleston Sequoia
2012-10-07 18:35:24 UTC ---
(In reply to comment #3)
> As far as Darwin is concerned, simply, somebody knowing the target well has to
> work out the details. So far, we only made sure that thin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #7 from Jeremy Huddleston Sequoia
2012-10-07 19:04:12 UTC ---
Yeah, Jack... your copying them and pasting them here just makes it easier for
me to accidentally read them. Please don't do that. The code is GPL3, and it
remains
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #9 from Jeremy Huddleston Sequoia
2012-10-07 19:38:18 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Yeah, Jack... your copying them and pasting them here just makes it easier
> > for
> > me to accidentally r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #14 from Jeremy Huddleston Sequoia
2012-10-07 22:49:50 UTC ---
Your patch looks wrong to me. You should just get rid of the '#if
_POSIX_TIMERS > 0' check and always use 'struct timespec' :
http://pubs.opengroup.org/onlinepub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #16 from Jeremy Huddleston Sequoia
2012-10-07 23:07:04 UTC ---
(In reply to comment #15)
> Note that the autoconf test is built by the C++ compiler, thus there is no
> real
> difference between timespec and struct timespec.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #20 from Jeremy Huddleston Sequoia
2012-10-07 23:25:54 UTC ---
(In reply to comment #18)
> To repeat what I meant: the autoconf test is built by the C++ compiler. Given
> that, writing 'timespec' or writing 'struct timespec' is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #22 from Jeremy Huddleston Sequoia
2012-10-08 03:48:00 UTC ---
Well we'll go with it for now. I've bumped gcc48 in MacPorts using Rob's
version of the patch. I'll update gcc47 and gcc46 after hearing back from Jon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #40 from Jeremy Huddleston Sequoia
2012-10-08 18:33:37 UTC ---
(In reply to comment #25)
> N.B. prior to POSIX 2008 nanosleep was part of the Timers option, if OS X
> supports that it should define _POSIX_TIMERS to 0, -1 or 200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #42 from Jeremy Huddleston Sequoia
2012-10-08 20:10:26 UTC ---
(In reply to comment #41)
> (In reply to comment #40)
> > I still don't see why the _POSIX_TIMERS > 0 check exists at all. On systems
> > that don't have it, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47309
Summary: gcc-4.4.5 fails to build on darwin/ppc due to issues
in boehm-gc GC_test_and_set
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: major
Priority:
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
If one builds a dylib using static libgcc.a, the libgcc symbols will be
exported by that library. One can mitigate this using an
-unexported_symbols_list, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54160
Bug #: 54160
Summary: gcc should not define __OBJC2__ when lang is not set
to ObjC (gcc 4.6 and later)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #13 from Jeremy Huddleston Sequoia
---
1. clang honors $SDKROOT from the environment if it is not passed via -isysroot
on the command line. That's all gcc needs to do, and then users running 'xcrun
gcc' would ge this behavior automa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #13 from Jeremy Huddleston Sequoia
---
Also note that also already does the following:
/*
* Compatibility with compilers and environments that don't support compiler
* feature checking function-like macros.
*/
#ifndef __has_buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #15 from Jeremy Huddleston Sequoia
---
(In reply to John Marshall from comment #14)
> [In reply to Jeremy Huddleston Sequoia in comment #12]
>
> In the future, please file radars for these problems and ping me directly if
> you want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #10 from Jeremy Huddleston Sequoia
---
FWIW, I don't have much power other than nagging to move along the OSS drops.
Those are managed by a process, and prioritization is given to those making
explicit requests to the OSS mailing li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #9 from Jeremy Huddleston Sequoia ---
Because of this issue, gcc only builds if we have the DevSDK ("headers at /"
package) installed. That package is being provided as a workaround for any
projects that fail to build without it (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Francois-Xavier Coudert from comment #11)
> (In reply to Jeremy Huddleston Sequoia from comment #10)
> > Given those, gcc only builds if we have the DevSDK ("headers at /" package)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203
Jeremy Huddleston Sequoia changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965
Bug #: 55965
Summary: gcc -std=c99 emits code for inline even without extern
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
Snapshot 8-20170604 (trunk r248863) builds fine on darwin.
Snapshot 8-20170611 (trunk r249106) and later (through at least
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
If gcc-6.3.0 is configured with
--with-build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #1 from Jeremy Huddleston Sequoia ---
And note that I'm not using --with-sysroot because I don't want this to affect
the compiler installed by 'make install', just what is used to build gcc
itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #3 from Jeremy Huddleston Sequoia ---
I'm not sure what you mean by using --prefix "instead" ... I'm using --prefix
to establish where I want the tools to be installed to.
As an example, if I wanted to install gcc to /opt/gcc6/bin/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #5 from Jeremy Huddleston Sequoia ---
I don't really understand what you mean by "Try --with-build-sysroot= instead."
... --with-build-sysroot= *is* being used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #6 from Jeremy Huddleston Sequoia ---
Got farther with the Makefile.in edit and setting of CPP and CXXCPP, but
failing now because --sysroot=... is not getting passed to xg++ during
configure-stage2-gcc:
from gcc/config.log:
configu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
Jeremy Huddleston Sequoia changed:
What|Removed |Added
Summary|fix-includes does not honor |--with-build-sysroot= does
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Target Milestone: ---
During a build of gcc6, libiberty fails to compile because -isysroot is not
passed to the compiler. gcc was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #11 from Jeremy Huddleston Sequoia
---
(In reply to Jeffrey Walton from comment #5)
># port install clang-3.8
># port install gcc6
># ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8
You probably meant:
$ ln -s clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Iain Sandoe from comment #9)
> we ought not be in a position where we detect that the ld64 is too old at
> the same time as trying to use the LLVM back end as the assembler.
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #16 from Jeremy Huddleston Sequoia
---
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965
--- Comment #3 from Jeremy Huddleston Sequoia ---
On OSX, the _isalnum symbol corresponds to the isalnum() function and the
__isalnum symbol would correspond to the _isalnum() function. It is emitting
the _isalnum symbol (for isalnum()) but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #43 from Jeremy Huddleston Sequoia
---
Created attachment 33824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824&action=edit
gcc 4.2 based patch which handles tiny version numbers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #49 from Jeremy Huddleston Sequoia
---
(In reply to Francois-Xavier Coudert from comment #45)
> (In reply to Jeremy Huddleston Sequoia from comment #42)
> > The committed patch is incorrect. It makes an invalid assumption which
> >
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremyhu at macports dot org
Even after the change for bug #61407, gcc is not setting up the deployment
target macro correctly. gcc always sets the tiny version to 0 which is not
always the case. For example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #50 from Jeremy Huddleston Sequoia
---
As this bug is now marked as resolved, I've filed #63810 to address the
remaining issues. Lawrence Velázquez is working on a
patch to address the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #1 from Jeremy Huddleston Sequoia ---
Larry said that he's working on a patch to fix this for gcc trunk, and I
suspect he's pretty close to having something since that was about a week ago.
The algorithm for determining what the macr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
--- Comment #10 from Jeremy Huddleston Sequoia
---
Ah, gotcha. In that case, please retitle as well to indicate such. Prior to
gcc-4.5, even support via emutls was not available on darwin, so some people in
#macports thought that's what this ti
50 matches
Mail list logo
