[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

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.  Issues in macOS headers don't get fixed if we don't know about
> them,
> and I'd prefer to fix the SDK itself than have GCC use fixup hacks.
> [snip]
> The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
> reported to Apple AFAIK.  I've filed a radar now to track it:
> .
> 
> Thanks for the advice. I reported this to Apple in early June (FB6125120),
> as noted in comment #4 above. Looking at it in
> feedbackassistant.apple.com today, there
> is no real indication anyone at Apple has ever read it. So that's
> unfortunate.

Thanks for the pointer to your report, John.

I looked it up, and an engineer sent it back to ADC a couple weeks after you
filed it as a duplicate of .  51499580 is the one I
filed (actually on the same day as yours) for the __has_builtin usage in
Availability.h AvailabilityInternal.h and TargetConditionals.h.  Those were
addressed, but that wasnt't the entirety of the issues across the entire SDK.

The comments in the report were unfortunately not as detailed as the comments
in this bugzilla report, so the engineer that screened it just thought it was
addressed with the fix to the bug I reported.  Sorry we missed that, and I'm
sorry that ADC hasn't responded back to you.  I'm going to ping them to figure
out why this is still in their "send a response" queue.

As for bullets in Rainer's original report here, I believe #2,#4 were addressed
by the fix to my radar.  #1 did not get fixed before GM, but we have a radar
tracking it (56133558) that was filed by Homebrew.  #3 (dyld) looks to no
longer be an issue in the GM headers.  Can you please confirm?  I just did a
visual check of the file and didn't notice an issue.

In the future, please feel free to poke me directly via email when you file a
report like this as I will definitely work to get a fix into the earliest
possible release.  These types of issues are a personal pet peeve of mine ;)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[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_builtin
#define __has_builtin(x) 0
#endif
#ifndef __has_include
#define __has_include(x) 0
#endif
#ifndef __has_feature
#define __has_feature(x) 0
#endif
#ifndef __has_attribute
#define __has_attribute(x) 0
#endif
#ifndef __has_extension
#define __has_extension(x) 0
#endif

which might be why you see the problematic behavior sometimes but not always,
depending on header include order =/

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #12 from Jeremy Huddleston Sequoia  
---
> perhaps Apple decided to ignore the report?
No.  We fix these issues when they're reported.

In the future, please file radars for these problems and ping me directly if
you want.  Issues in macOS headers don't get fixed if we don't know about them,
and I'd prefer to fix the SDK itself than have GCC use fixup hacks.

The __has_builtin() usage in Availability.h and TargetConditionals.h was
reported to me by Homebrew shortly after beta 1 and we fixed it internally
within a couple hours, landing it in a future beta.  We very much care about
the quality of the SDK, and if you run into issues, I'm more than happy to
champion them myself to avoid hacks like this in toolchains.

The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
reported to Apple AFAIK.  I've filed a radar now to track it:
.

>  unconditionally uses the availability attribute.

I'm not seeing that in the shipped SDK.  Perhaps it was filed by someone and
addressed.  If it's still an issue that I'm just not seeing, please file a
radar.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[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 automatically.

2. xcrun is not OSS, but the primary functionality that you asked for was
provided in libxcselect in macOS 10.15, so you wouldn't need to exec xcrun to
find the path to the SDK.

3. I cannot decipher your comment "when clang is using a "different" SDK to
target a version of MacOS, it is using the runtimes provided by the target
MacOS version."  ... that doesn't quite make sense, so please be a bit more
specific about which runtime you are referring to (the compiler runtime, the OS
runtime)... either way I try to interpret it, it makes no sense, so I'm not
sure how to address this comment, sorry.

4. macOS deprecates APIs but will almost never remove them (unless we change
architectures ... such as when we removed a bunch of deprecated API when moving
from ppc to intel).  Internal / private SPI is subject to removal, but we aim
to never remove API as that breaks binary compatibility.

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #7 from Jeremy Huddleston Sequoia  ---
There's no reason to replicate call out to xcrun or replicate xcrun's behavior.
 We added an API to libxcselect for GCC's use.  Look in usr/include/xcselect.h
in the 10.15 SDK.

[Bug other/80203] libiberty fails to compile regex.c correctly when gcc is configured --with-sysroot

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jeremy Huddleston Sequoia  ---
This issue is not present in gcc8.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[jeremyhu at macports dot org]

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)
> > installed.
> 
> I may be misunderstanding what you say: GCC builds and runs fine without the
> headers in /usr/include. At Homebrew, we are not recommending users to
> install the /usr/include headers package, and we build and run GCC fine. The
> configuration is the following
> (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
> 
>   --with-native-system-header-dir=/usr/include
>   --with-sysroot=/path/to/sdk
>
> if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> installation with Xcode CLT installed, we set /path/to/sdk to
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Yeah, I documented the workaround of using --with-sysroot in the MacPorts port
when filing these bugs and passed on to Homebrew, but that ends up causing
gcc's search path to always look in that sysroot (ie, it becomes the default
sysroot).  Thus, users will build executables that behave differently based on
where there SDK was located on their build system.  That is certainly not what
is desired.  If you have a build fleet that used an SDK that was located at
/Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build time, but your users have
/Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch can
cause problems.

The point of --with-sysroot is to change the behavior of the built product (the
final gcc executable).  The point of --with-build-sysroot is to change how we
build gcc.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[jeremyhu at macports dot org]

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 note that GCC is the only project
we are aware of that falls into this category).  In some future macOS version,
it will cease to be provided.  I strongly encourage you to address this issue
as soon as possible to ensure that GCC continues to build with future versions.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[jeremyhu at macports dot org]

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 list.  *PLEASE* email opensou...@apple.com
directly (and feel free to CC me).

I agree with pretty much all Iain has said here.  There's nothing that should
be different about how gcc treats i386 on darwin vs how it treats i386 on
linux.

Note that for us, the far bigger concerns are the broken --with-build-sysroot
support:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203

Given those, 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 note that GCC is the only project we are
aware of that falls into this category).  In some future macOS version, it will
cease to be provided.  I strongly encourage you to address those issues as soon
as possible to ensure that GCC continues to build with future versions.

[Bug c++/82092] New: gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092

Bug ID: 82092
   Summary: gcc fails to link genmodes on darwin
(cfiStartsArray[i] != cfiStartsArray[i-1])
   Product: gcc
   Version: 8.0
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 8-20170827,
r251369) fail to build on darwin.

The build fails with the linker failing an assert due to invalid output
produced by the compiler when building genmodes:

make[3]: Entering directory
`/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/gcc'
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/xg++
-B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/./prev-gcc/
-B/opt/local/x86_64-apple-darwin17/bin/ -nostdinc++
-B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs
-B/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs
 -isystem
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include/x86_64-apple-darwin17
 -isystem
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/include
 -isystem
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/gcc-8-20170827/libstdc++-v3/libsupc++
-L/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/src/.libs
-L/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc8/libgcc-devel/work/build/prev-x86_64-apple-darwin17/libstdc++-v3/libsupc++/.libs
  -g -O2   -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-no_pie  -o build/genmodes \
build/genmodes.o build/errors.o .././libiberty/libiberty.a
0  0x101edfb1b  __assert_rtn + 129
1  0x101ef323a 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3030
2  0x101eeabcc  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 282
3  0x101f2fae4  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 830
4  0x101f3246d  ld::tool::InputFiles::parseWorkerThread() + 497
5  0x7fff7ec806c1  _pthread_body + 340
6  0x7fff7ec8056d  _pthread_body + 0
A linker snapshot was created at:
/tmp/genmodes-2017-08-03-125525.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/Library/Caches/com.apple.xbs/Sources/ld64/ld64-302.4/src/ld/parsers/macho_relocatable_file.cpp,
line 1898.
collect2: error: ld returned 1 exit status

This happens with all versions of macOS that I’ve tried (El Capitan through
High Sierra).

See also bug #57438

[Bug other/80203] New: libiberty fails to compile regex.c correctly when gcc is configured --with-sysroot

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203

Bug ID: 80203
   Summary: libiberty fails to compile regex.c correctly when gcc
is configured --with-sysroot
   Product: gcc
   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: ---

During a build of gcc6, libiberty fails to compile because -isysroot is not
passed to the compiler.  gcc was configured with
--with-sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk",
and this is passed elsewhere, but not when building regex.c

 /opt/local/bin/clang-mp-3.9 -arch x86_64 -c -DHAVE_CONFIG_H -pipe -Os
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
 -I.
-I/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
-D_GNU_SOURCE 
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/physmem.c

...

if [ x"-fno-common" != x ]; then \
  /opt/local/bin/clang-mp-3.9 -arch x86_64 -c -DHAVE_CONFIG_H -g   -I.
-I/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
-D_GNU_SOURCE -fno-common
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/regex.c
-o pic/regex.o; \
else true; fi
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/regex.c:52:12:
fatal error: 'sys/types.h' file not found
#  include 
   ^
1 error generated.

gcc was configured with:

--prefix=/opt/local --build=x86_64-apple-darwin16
--enable-languages=c,c++,objc,obj-c++,lto,fortran
--includedir=/opt/local/include/gcc6 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-6
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-6 --with-gxx-include-dir=/opt/local/include/gcc6/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--libdir=/opt/local/lib/libgcc --with-pkgversion="MacPorts gcc6 6.3.0_0"
--with-sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk"

Note that we're not using --with-build-sysroot because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[jeremyhu at macports dot org]

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
   |the value passed to |not get honored throughout
   |--with-build-sysroot=,  |the build (fix-includes,
   |looks for /usr/include  |CPP, CXXCPP,
   |instead of looking within   |configure-stage2)
   |the SDK |

--- Comment #7 from Jeremy Huddleston Sequoia  ---
Retitled to make the issue more clear/generic.

Note that using --with-sysroot, I'm able to get a built compiler, but the
result ends up using the configured sysroot as its default sysroot (as one
would expect based on the documentation for --with-sysroot).

My understanding is that --with-build-sysroot should behave the same as
--with-sysroot *except* that the installed compiler's default is modified by
--with-sysroot and not modified by --with-build-sysroot.

[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK

[jeremyhu at macports dot org]

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:

configure:6449: 
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/build/./pr
ev-gcc/xg++ ...  conftest.cpp >&5
conftest.cpp:22:19: fatal error: stdio.h: No such file or directory
 #include 
   ^
compilation terminated.

[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK

[jeremyhu at macports dot org]

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.

[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK

[jeremyhu at macports dot org]

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/gcc, I'd use
--prefix=/opt/gcc6.  However, the system headers (i.e., /usr/include/stdlib.h)
are located in the macOS SDK (not at /usr/include), so it looks like I should
be passing 
--with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
to configure.  Or am I misunderstanding the purpose of this configure option?

Our build system (MacPorts) is already setting up
'-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
in CPPFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS and adding
'-Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
to LDFLAGS' ... which is sufficient for most other projects, but GCC's a
difficult beast to tame.

FWIW, I worked around this by just editing SYSTEM_HEADER_DIR in gcc/Makefile.in
before running configure.

Another related issue is that CPP and CXXCPP need to be explicitly set in the
environment because the test for discovering them does not use CPPFLAGS and
thus fails, so /lib/cpp is used as fallback (which is not correct).

[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK

[jeremyhu at macports dot org]

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.

[Bug other/79885] New: fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

Bug ID: 79885
   Summary: fix-includes does not honor the value passed to
--with-build-sysroot=, looks for /usr/include instead
of looking within the SDK
   Product: gcc
   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-sysroot=/Applications/Xcode.app/.../MacOSXXX.sdk, the build will
fail unless /usr/include is present on the system as well.  The build fails
during fix-includes with the message:

The directory that should contain system headers does not exist:
  /usr/include

I suspect this is because SYSTEM_HEADER_DIR is set to /usr/include rather than
$SDKROOT/usr/include.

Perhaps I'm misunderstanding the intention of --with-build-sysroot, but
essentially, I want to build gcc against a given macOS SDK, and the system does
not contain system headers installed at /.  I'm testing a workaround of
defining SYSTEM_HEADER_DIR explicitly, but it would be best if this issue were
resolved properly upstream.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[jeremyhu at macports dot org]

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 possible for someone to manually force themselves into such a situation,
but that is not a configuration we (Apple, MacPorts, LLVM, GCC) should support.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[jeremyhu at macports dot org]

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-mp-3.8 /opt/local/bin/clang

However, don't create the symlink yourself.  Use 'sudo port select clang
mp-clang-3.8'

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[jeremyhu at macports dot org]

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
> interesting as the default build is a Debug one compiled at -O0. The debug
> build of libunwind.dylib produces a binary which exhibits the same breakage
> in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15
> with the optimized system libunwind.dylib. This makes it much more likely
> that the issue isn't an optimization bug in Apple Clang 7.0 but rather a
> linker bug in Xcode 7.

I don't see how you come to that conclusion.  All I see are these data points:

libunwind-35.3 built against the 10.10 SDK with Xcode6-era clang and Xcode6-era
linker produces a libunwind.dylib that does not exhibit this problem.

libunwind-35.3 built against the 10.11 SDK with Xcode7-era clang and Xcode7-era
linker produces a libunwind.dylib that exhibits this problem.

I suggest you try using the Xcode 7 linker with the Xcode 6 compiler and 10.10
SDK.  If you hypothesis is correct, it should fail.  You can do that by just
copying Xcode7's linker to
Xcode6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
(make sure you backup the old one of course).


> Unfortunately, it is impossible to test that by
> linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build
> uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus
> requires the new linker with the .tbd support.

Well then I suggest you similarly test using the Xcode 7 compiler with the
Xcode 7 linker and the 10.10 SDK to rule out the SDK as a factor and then test
using the Xcode 7 compiler with the Xcode 6 linker and the 10.10 SDK.

> FYI, The .tbd files are new "text-based stub libraries", that provide a much
> more compact version of the stub libraries for use in the SDK, and help to
> significantly reduce its download size.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

--- Comment #49 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
---
(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
  breaks the usage of deployment targets such as 10.9.3.
 
 All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
 (where x is integer, but not only one digit).

That is not the case.  Do not make that assumption.

(In reply to howarth from comment #46)
 (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
   breaks the usage of deployment targets such as 10.9.3.
  
  All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
  (where x is integer, but not only one digit).
 
 If Jeremy really disagreed on that change, he hasn't acted on it in the
 gcc49 MacPorts packaging that he maintains (which still uses the original
 proposed patch from
 https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02428.html). FYI, as far as
 llvm-gcc 4.2.1 is concerned, in my fink legacy package for Apple's llvm-gcc
 4.2.1, I used a back port of our patch,
 http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/
 languages/llvm-gcc42-yosemite.patch. Neither gcc 4.9.2 nor the patched
 llvm-gcc 4.2.1 has shown any problems on OS X 10.9.5.

I have not fixed the GPL3 ports in MacPorts because I do not read GPL-3 code
and thus am not able to fix it.  Another MacPorts developer is making the fix
for newer versions of gcc.

[Bug driver/63810] New: gcc sets incorrect macro for OS X deployment targets

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810

Bug ID: 63810
   Summary: gcc sets incorrect macro for OS X deployment targets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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:

$ echo | clang-mp-3.5 -E -dM - -mmacosx-version-min=10.09.04 | grep
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1094

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

--- Comment #50 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
---
As this bug is now marked as resolved, I've filed #63810 to address the
remaining issues.  Lawrence Velázquez lar...@macports.org is working on a
patch to address the issue.

[Bug driver/63810] gcc sets incorrect macro for OS X deployment targets

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810

--- Comment #1 from Jeremy Huddleston Sequoia jeremyhu at macports dot org ---
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 macro should be is quite simple:

Split the string by .
Use implicit 0 if there are less than three elements.
if (first field is 10) or (first field is 10 and second field = 10), use
%02d%02d%02d as the format
else use %02d%01d%01d as the format

I had to do this in bash for some unrelated reason, and here it is in case it
is helpful to you:

BUILD_MAJOR=$(echo ${PRODUCT_VERSION} | cut -f1 -d.)
BUILD_MINOR=$(echo ${PRODUCT_VERSION} | cut -f2 -d.)
BUILD_TINY=$(echo ${PRODUCT_VERSION} | cut -f3 -d.)

[[ -z ${BUILD_MINOR} ]]  BUILD_MINOR=0
[[ -z ${BUILD_TINY} ]]  BUILD_TINY=0

if ((BUILD_MAJOR  10 || (BUILD_MAJOR == 10  BUILD_MINOR = 10))) ; then
  VERSION_ENCODED=$(printf %02d%02d%02d ${BUILD_MAJOR} ${BUILD_MINOR}
${BUILD_TINY})
else
  VERSION_ENCODED=$(printf %02d%01d%01d ${BUILD_MAJOR} ${BUILD_MINOR}
${BUILD_TINY})
fi

For clang, I did this (slightly less clean):

-char Str[5];
-Str[0] = '0' + (Maj / 10);
-Str[1] = '0' + (Maj % 10);
-Str[2] = '0' + std::min(Min, 9U);
-Str[3] = '0' + std::min(Rev, 9U);
-Str[4] = '\0';
+char Str[7];
+if (Maj  10 || Maj == 10  Min  10) {
+  Str[0] = '0' + (Maj / 10);
+  Str[1] = '0' + (Maj % 10);
+  Str[2] = '0' + std::min(Min, 9U);
+  Str[3] = '0' + std::min(Rev, 9U);
+  Str[4] = '\0';
+} else {
+  Str[0] = '0' + (Maj / 10);
+  Str[1] = '0' + (Maj % 10);
+  Str[2] = '0' + (Min / 10);
+  Str[3] = '0' + (Min % 10);
+  Str[4] = '0' + (Rev / 10);
+  Str[5] = '0' + (Rev % 10);
+  Str[6] = '\0';
+}

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #42 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
---
The committed patch is incorrect.  It makes an invalid assumption which breaks
the usage of deployment targets such as 10.9.3.

Please instead use the (GPL2) patch that I provided back in June and is
available from MacPorts:
https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/files/yosemite-deployment-target.patch

I will also attach it, but it is based on gcc-4.2 (I do not intentionally read
GPL3 code) and may require modification for usage in newer gcc.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407

--- Comment #43 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
---
Created attachment 33824
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824action=edit
gcc 4.2 based patch which handles tiny version numbers properly

[Bug c/55965] gcc -std=c99 emits code for inline even without extern

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965

--- Comment #3 from Jeremy Huddleston Sequoia jeremyhu at macports dot org ---
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 the __isalnum symbol (because
_isalnum() is being inlined).

I suspect you seeing an isalnum symbol is because you're on a different
platform that does not _-prefix.

[Bug target/52268] tls support should be added for darwin11

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268

--- Comment #10 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
---
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 ticket was referring to.  Thanks.

[Bug target/52268] tls support should be added for darwin11

[jeremyhu at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268

Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #8 from Jeremy Huddleston Sequoia jeremyhu at macports dot org ---
Seems to work to me in gcc-4.6:

~ $ cat test_thread.c 
#include pthread.h
#include stdio.h

#define NUM_THREADS 5

int __thread value;

void * test_thread(void *arg) {
return value;
}

int main(void) {
int i;
pthread_t thread[NUM_THREADS];

for(i=0; i  5; i++) {
pthread_create(thread[i], NULL, test_thread, NULL);
}

for(i=0; i  5; i++) {
void *loc;
pthread_join(thread[i], loc);
printf(%p\n, loc);
}

return 0;
}

$ gcc-mp-4.6 test_thread.c 

$ ./a.out
0x7fc7b3d00118
0x7fc7b3e00118
0x7fc7b3f00118
0x7fc7b3d00118
0x7fc7b3c03b28

$ gcc-mp-4.6 --version
gcc-mp-4.6 (MacPorts gcc46 4.6.4_5+universal) 4.6.4
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libgcc/58120] New: libgcc.a and libgcc_eh.a have incorrect symbol visibility

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58120

Bug ID: 58120
   Summary: libgcc.a and libgcc_eh.a have incorrect symbol
visibility
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  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 that is sub-optimal.  The static archives should
have the expected visibility to prevent re-export when built into a dylib.

This is an issue on OS X, and I assume the same issue exists on other platforms
as well.

[Bug c/55965] New: gcc -std=c99 emits code for inline even without extern

[jeremyhu at macports dot org]

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

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jerem...@macports.org





$ cat /tmp/testa.c 

inline int isalnum(int _c) { return 1; }

inline int _isalnum(int _c) { return 1; }



$ /opt/local/bin/gcc-mp-4.8 -c /tmp/testa.c -o /tmp/test.o -std=c99



$ nm /tmp/test.o 

0010 s EH_frame1

 T _isalnum



---



isalnum is being emitted with external linkage even though it is inline and

never declared as 'extern inline'  It looks like gcc may have implicit extern

declarations for some functions which is forcing this 'inline' definition to be

treated asn an 'extern inline' definition.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #40 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 200112L to indicate

 it's supported.  POSIX 2008 moves the Timers functionality to the Base spec,

 and requires that _POSIX_TIMERS is defined to 200809L. In eiher case, a POSIX

 system supporting nanosleep should define _POSIX_TIMERS.



It is defined to -1 because OS X does not support all that _POSIX_TIMERS

entails.



I still don't see why the _POSIX_TIMERS  0 check exists at all.  On systems

that don't have it, the tests will simply fail because timespec or nanosleep

are undefined.



 The configure checks are based on well-documented, publicly-available

 standards, please try to understand them instead of proposing patches based on

 the misunderstanding that adding struct makes any difference to anything.



I very much understand the standards, and I've provided a link to them.  The

standard itself does not require _POSIX_TIMERS to be defined for nanosleep to

be supported, and it specifically states 'struct timespec' in the function

prototype.



(In reply to comment #26)

  If Apple or anyone else wants it to work

 otherwise they need to do the work, as GCC maintainers have no reason to do

 support building parts of GCC without GCC!



Apple is fully committed to libc++.  If anyone wants libstdc++ to work on

Darwin, it is clear that it will need to be a community effort.



(In reply to comment #29)

 _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 
 means

 the Timers option is not supported.



Yes, it is not *fully* supported.



  Or are you going to demand that the use of pre-2008 POSIX nanosleep() be 
  only

  accepted on a target-specific basis?

 

 There are plenty of systems with a 2001 nanosleep that define _POSIX_TIMERS to

 20112L, but darwin seems to support nanosleep without the rest of the Timers

 option.  I don't want to remove the correct check for _POSIX_TIMERS just for

 one system's peculiarities.



It's not one system.  You are misreading the spec.  _POSIX_TIMERS  0 implies

that all the functionality is available.  That is the only thing you can deduce

from that check.  It is perfectly valid to have a conforming nanosleep with

_POSIX_TIMERS = -1.



Why are you even othering to put that code inside of a _POSIX_TIMERS  0 check.

 If _POSIX_TIMERS  0, you're guaranteed (by the standard) to have that

functionality, so there's no point in checking... if you want to support all

platforms, it's better to just check for nanosleep directly without the

_POSIX_TIMERS check.



(In reply to comment #39)

 Yes, but why do you want to disable it?

 

 Why does that patch define _GLIBCXX_USE_SCHED_YIELD?



I think his patch has no effect on _GLIBCXX_USE_SCHED_YIELD ... I think he

wasn't seeing _GLIBCXX_USE_SCHED_YIELD before because of a mistype he was

having with the configure option.



With Rob's patch, I see both _GLIBCXX_USE_SCHED_YIELD and

_GLIBCXX_USE_NANOSLEEP defined to 1.



 That is correctly detected anyway by configure, without any changes, as I said

 in comment 30 and again in comment 37



Yes, it is.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #42 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 tests will simply fail because timespec or nanosleep

  are undefined.

 

 The existence of a function called nanosleep doesn't mean it's the right one,

 or that it will be found at link time, or available at run-time.

 

 Checking _POSIX_TIMERS  0 means the functionality is actually usable, without

 checking sysconf() at run-time as described by POSIX.1b-2001.

 



Right, but as we see here, the converse is not true.  ie:



This is true:

(_POSIX_TIMERS  0) = (nanosleep is the one you want)



This is not true:

(nanosleep is the one you want) = (_POSIX_TIMERS  0)



You want to find an test such that:



(your test) = (nanosleep is the one you want)



 (That was a link to clock_nanosleep not nanosleep, which was a different

 option, not Timers ;)



Aww sorry.  I copy-linked the wrong one, but meh.



 ... but you do still seem to doubt that the struct is unnecessary in C++. 



No.  I don't doubt that.  I admitted in comment #20 that C++ is not a strength

of mine, so thanks for letting me know about this detail.



 Maybe you've noticed how you don't need to say:

 

class std::string str = a string;

^

 to use C++ classes. It's the same for structs.



Yeah, I knew about class, but I didn't know about that for structs.  I thought

it wasn't possible to drop 'struct' in C++ as it's not possible to drop it in C

(although most users will typedef).  Thanks for teaching me something new.



 Again, there's a difference between *working* (i.e. being usable) on darwin 
 and

 being able to build libstdc++ with a different compiler.  There is no

 requirement to be able to configure libstdc++ with anything other than G++, 
 but

 in any case I assure you that clang++ doesn't require the 'struct' keyword

 either.



I don't doubt it.  I was just trying to make the usage strictly match the POSIX

spec.



  It's not one system.  You are misreading the spec.

 

 No I'm not, my words you quoted carefully made the distinction of saying -1

 means the Timers option is not supported, not that nanosleep is not supported:



Ok.



 I'd be happy to improve the test to support other systems, but the patches

 posted to this PR so far have been unacceptable due to failing to understand

 the existing checks, failing to meet libstdc++'s configury conventions, or

 adding support for a single system rather than for any systems which provide

 nanosleep without the rest of the Timers option.  In the absence of a decent

 patch I suggest defining the HAVE_NANOSLEEP macro in os_defines.h and moving

 on.



  Why are you even othering to put that code inside of a _POSIX_TIMERS  0 
  check.

   If _POSIX_TIMERS  0, you're guaranteed (by the standard) to have that

  functionality, so there's no point in checking...

 

 The existence of a preprocessor symbol doesn't tell you whether you need to

 link to a particular library to use the function.



Ah, I forgot you were checking for library linkage as well.  That makes sense.



 The check is AC_TRY_LINK which will ensure not only is the function declared

 but the symbol is found, having added -lposix4 or -lrt to the link line if

 earlier checks indicate they're needed.



That makes sense.



  if you want to support all

  platforms, it's better to just check for nanosleep directly without the

  _POSIX_TIMERS check.

 

 If _POSIX_TIMERS is defined to 0 the code might compile but not work at

 run-time.  I didn't write those checks, but I'm not inclined to remove the

 tests of the POSIX option macros just to fix this PR.



Ok, what about just using _POSIX_TIMERS  0 || defined(__APPLE__)?  That may

miss some other OSs in the same boat, but they can always add similar checks.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:



   What|Removed |Added



 CC||jeremyhu at macports dot

   ||org



--- Comment #2 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
2012-10-07 17:39:52 UTC ---

I think Jack is confused regarding --enable-libstdcxx-timer.  From emailing me,

he seems to be under the impression that '--enable-libstdcxx-timer' is

equivalent to '--enable-libstdcxx-timer=no' ... if that is the case, then

something is certainly wrong since --enable-libstdcxx-timer should be

equivalent to '--enable-libstdcxx-timer=yes' ...



As for darwin ... we have sched_yield and nanosleep.  We don't have

clock_gettime.



Why are you testing for posix timer support in your checks for sched_yield and

nanosleep?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #4 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 things work reasonably

 well on GNU/Linux machines. Patches are welcome, as usual.



I know the target, and I'm willing to answer any questions you may have. 

Unfortunately as gcc is GPL3, I can't look at the code or offer services beyond

that.



Is there a particular reason why the check for nanosleep and sched_yield check

for _POSIX_TIMERS  0?  That seems peculiar to me.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #7 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 GPL3 even if you copy/paste it into this bug report.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #9 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 read them.  Please don't do that.  The code is GPL3, and 
  it

  remains GPL3 even if you copy/paste it into this bug report.

 

 Well you are bound to read code fragments that are GPLv3 in FSF gcc bugzilla 
 so

 I 

 don't know what you expecting here. I would stop reading FSF gcc bugzilla if

 you can't 

 reasonably participate.



I can certainly participate.  I just need to make sure that I don't read any

code snippets that are GPL3 licensed.



 Also, aren't headers considered different in context 

 from source 

 files?



It depends how they are licensed, but this is really a side conversation.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #14 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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/onlinepubs/9699919799/functions/clock_nanosleep.html



If there are some platforms which don't conform and need 'timespec' instead of

'struct timespec', then you can certainly work around those on a case by case

basis, but the _POSIX_TIMERS conditional has no reason to be there as far as I

can tell...



You should also do something similar for the clock_gettime and sched_yield

checks.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #16 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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.



Except that one is POSIX and one is not.  Additionally, you shouldn't assume

that g++ is being used.  Hopefully, libstdc++ would be portable enough that one

wouldn't need to bootstrap g++ to build it.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #20 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 exactly the same.



C++ lets you just drop struct?  My C++ is very rusty, and I didn't realize

that.  That seems messy.  Thanks for the info.



 Just

 wanted to clarify why, even from a formal point of view, the patch cannot be

 right, I didn't really mean to analyze in any detail the existing autoconf 
 test

 (I didn't write this specific one, IIRC). Again send patches to libstdc++,

 possibly CC Jon.



Yeah, that's why I'm suggesting just dropping the check for _POSIX_TIMERS  0

... that check seems weird to me, and Jack's test seems to indicate that it's

not needed.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847



--- Comment #22 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #13 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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.7 (MacPorts gcc47 4.7.1_7+universal) 4.7.1

Copyright (C) 2012 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



with libstdcxx-devel @4.8-20120923

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #16 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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

  U ___emutls_get_address

 b1e0 d ___emutls_v.gomp_tls_data

 

 I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's

 libstdc++.6.dylib could be due to the fact that clang is used to build it

 rather than a proper full bootstrap. Please try restoring the bootstrap and 
 see

 if the symbols are restored to libstdc++.6.dylib.



We do a full bootstrap first before building libstdc++.  There is an issue with

clang (fixed in llvm-3.2) which prevents us from using clang to build libstdc++



(In reply to comment #15)

 I believe your no-runtime-stubs.patch used during the initial build of

 libstdc++ is at fault...

 ...

 

 These changes will certainly keep config.h in the libstdc++-v3 build directory

 from having...

 

 #define HAVE_TLS 



Why?  That seems odd.



 Why is it so critical for MacPorts to eliminate the linkage on 

 libgcc_ext.10.4/ libgcc_ext.10.5?



Because it doesn't exist.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #18 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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...

   

   #define HAVE_TLS 

  

  Why?  That seems odd.

 

 Not really. The use of the no-runtime-stubs.patch patch would keep the tests

 in config/tls.m4 for working properly as it breaks the ability of the xgcc

 compiler

 from accessing the emutls support calls residing in libgcc_ext.10.4/5.



Nothing actually resides in libgcc_ext.10.[45].dylib ... those are stub

libraries which result in those symbols resolving to

/opt/local/lib/gccXX/libgcc_s.1.dylib.



   Why is it so critical for MacPorts to eliminate the linkage on 

   libgcc_ext.10.4/ libgcc_ext.10.5?

  

  Because it doesn't exist.

 

 This is the wrong approach. You shouldn't be trying to gut libgcc_ext from

 libstdc++-v3 but

 rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that

 they are kept at

 the latest level.



Yes, that was what I eventually want to do, but this was the first step of that

approach.  Still, this *should* work.



Note that the libgcc_ext.10.[45] are not actually needed if we're going to be

using the libgcc runtime.  This is the whole reason why I suggest just removing

them entirely in a future release.  The whole point of those stubs is to let

let linker pick up some of the runtime from libSystem and the rest (things

added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be in

the business of shipping our own compiler runtime, we don't need to let some

parts resolve to libSystem and others resolve to ours.  We should just let it

all resolve to ours.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #21 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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 runtime.  This is the whole reason why I suggest just 
  removing

  them entirely in a future release.  The whole point of those stubs is to let

  let linker pick up some of the runtime from libSystem and the rest (things

  added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be 
  in

  the business of shipping our own compiler runtime, we don't need to let some

  parts resolve to libSystem and others resolve to ours.  We should just let 
  it

  all resolve to ours.

 

 My understanding is that the libgcc symbols that have been subsumed into

 libSystem as of

 darwin10 and will always override those provided by any additional libgcc.



yes



 The

 following messages

 from the darwin linker developer on llvm-dev covered this and related issues

 with the unwinder.

 

 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html

 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html

 http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html

 

 Perhaps you are proposing that eventually we gut the duplicate symbols, now in

 libSystem, out of FSF libgcc_s but that would have to be done very carefully.

 Over

 a years work went into the libgcc_ext design and implementation. A similar

 effort

 would be required to gracefully replace it.



Yes ... which is why I simply mentioned it in a comment and haven't started

going down that road except as a brain exercise.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #22 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 
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.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



Jeremy Huddleston jeremyhu at macports dot org changed:



   What|Removed |Added



 CC||jeremyhu at macports dot

   ||org



--- Comment #8 from Jeremy Huddleston jeremyhu at macports dot org 2012-10-05 
17:41:16 UTC ---

I don't know that we're playing games with which libstdc++ gcc uses at link

time.  Instead of having multiple copies of libstdc++ lying around, you now

have one, and it's either built from gcc-4.8 (the libstdcxx-devel port) or from

gcc-4.7 (the libstdcxx port).  It lives as ${prefix}/lib/libstdc++.6.dylib, and

is picked up by g++-mp-XX by way of their libstdc++.dylib symlinks.



Additionally, we hope to eventually move this libstdc++ on top of libc++abi

instead of libsupc++, so it can co-exist with the host libc++ and libstdc++ in

the same address space (users seem to do mixing of the C++ runtimes which is

what instigated the libstdcxx port to begin with).



As for the no-runtime-stubs.patch patch, that is *NOT* used to build gcc47. 

That is only used in the process of building libstdc++.6.dylib in the libstdcxx

port, and it is done in order to intentionally not have the resulting

libstdc++.dylib link against the libgcc runtime dynamically.  The gcc

buildsystem is so convoluted that this seemed to be the easiest way to ensure

that the resulting libstdc++.dylib picked up its gcc runtime statically.

[Bug middle-end/54806] [4.7 Regression] Undefined symbols: ___emutls_v.*, ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806



--- Comment #9 from Jeremy Huddleston jeremyhu at macports dot org 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

[Bug preprocessor/54160] New: gcc should not define __OBJC2__ when lang is not set to ObjC (gcc 4.6 and later)

[jeremyhu at macports dot org]

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: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jerem...@macports.org


gcc should not be defining the __OBJC2__ preprocessor macro when it is not
building for the Objective C or Objective C++ languages.

~ $ echo  | gcc-mp-4.5 -x objective-c -E -dM - | grep OBJ
#define __OBJC__ 1

~ $ echo  | gcc-mp-4.5 -E -dM - | grep OBJ

~ $ echo  | gcc-mp-4.6 -x objective-c -E -dM - | grep OBJ
#define __OBJC__ 1
#define __OBJC2__ 1

~ $ echo  | gcc-mp-4.6 -E -dM - | grep OBJ
#define __OBJC2__ 1

This is a regression that entered gcc 4.6 and is present in current versions of
4.6, 4.7, and 4.8 snapshots

[Bug boehm-gc/47309] New: gcc-4.4.5 fails to build on darwin/ppc due to issues in boehm-gc GC_test_and_set

[jeremyhu at macports dot org]

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: P3
 Component: boehm-gc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jerem...@macports.org


temp work dir replaced with ... for better readability:

libtool: compile:  .../build/./gcc/xgcc -B.../build/./gcc/
-B/opt/local/ppc-apple-darwin9/bin/ -B/opt/local/ppc-apple-darwin9/lib/
-isystem /opt/local/ppc-apple-darwin9/include -isystem
/opt/local/ppc-apple-darwin9/sys-include -DHAVE_CONFIG_H
-I.../gcc-4.4.5/boehm-gc/include -fexceptions -Iinclude -I././targ-include
-I.//libc/include -g -pipe -ggdb3 -fexceptions -Iinclude -I././targ-include
-I.//libc/include -c ../../../gcc-4.4.5/boehm-gc/os_dep.c  -fno-common -DPIC -o
.libs/os_dep.o
In file included from .../gcc-4.4.5/boehm-gc/include/private/gc_priv.h:98,
 from ../../../gcc-4.4.5/boehm-gc/os_dep.c:17:
.../gcc-4.4.5/boehm-gc/include/private/gc_locks.h: In function
'GC_test_and_set':
.../gcc-4.4.5/boehm-gc/include/private/gc_locks.h:165: error: 'asm' operand has
impossible constraints

inline static int GC_test_and_set(volatile unsigned int *addr) {
  int oldval;
  int temp = 1; /* locked value */

  __asm__ __volatile__(
   1:\tlwarx %0,0,%3\n   /* load and reserve   */
   \tcmpwi %0, 0\n   /* if load is */
   \tbne 2f\n/*   non-zero, return already set */
   \tstwcx. %2,0,%1\n/* else store conditional */
   \tbne- 1b\n   /* retry if lost reservation  */
   \tsync\n  /* import barrier */
   2:\t\n/* oldval is zero if we set   */
  : =r(oldval), =p(addr)
  : r(temp), 1(addr)
  : cr0,memory);
  return oldval;
}