| Summary: | sys-devel/gcc-apple-4.2.1_p5666-r1: compile failed for redefinition of a 'extern inline' function | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Linlin Yan <yanlinlin82> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4nykey, cnyegle, gentoo, johanmcos, kasuganosora, mys721tx, ryao, santosdosreis, srcshelton, sritchie, tomka, yangxihongx |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| URL: | http://trac.macports.org/ticket/34639 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch for correct 'inline' functions 'floor_log2' and 'exact_log2'
/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/gcc-build-logs.tar.bz2 $EPREFIX/usr/portage/sys-devel/gcc-apple/gcc-apple-4.2.1_p5666-r2.ebuild bootstrap-prefix.sh patch |
||
does it help if you set -std=c89 in CFLAGS? (I suspect they won't get through though) Did you mean changing CFLAGS in .ebuild or make.conf? Or just set that by "export CFLAGS=-std=c89"? I am afraid it should be a discordant bug between .h and .c files. Setting -std=c89 in CFLAGS won't make this better (it may just ignore the duplicated definitions). I am trying to patch it (by modifying the .c file) to see if it helps or not. I wonder that since it is a .c file (but not a .cpp file), why it tests !defined (__cplusplus), which should be always true. Created attachment 363174 [details, diff]
Patch for correct 'inline' functions 'floor_log2' and 'exact_log2'
I have changed the 'extern inline' to 'static inline' to make sure it compiles the code correctly.
However, it failed again with other messages in the subsequent steps:
mv tmp-xlimits.h xlimits.h
echo | /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/./gcc/xgcc -B/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/./gcc/ -B/Users/yanll/Gentoo/usr/x86_64-apple-darwin13/bin/ -B/Users/yanll/Gentoo/usr/x86_64-apple-darwin13/lib/ -isystem /Users/yanll/Gentoo/usr/x86_64-apple-darwin13/include -isystem /Users/yanll/Gentoo/usr/x86_64-apple-darwin13/sys-include -E -dM - | \
sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
sort -u > tmp-macro_list
/Users/yanll/Gentoo/bin/bash /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/gcc-5666.3/gcc/../move-if-change tmp-macro_list macro_list
echo timestamp > s-macro_list
The directory that should contain system headers does not exist:
/usr/include
make[3]: *** [stmp-fixinc] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2
emake failed
* ERROR: sys-devel/gcc-apple-4.2.1_p5666-r2::gentoo_prefix failed (compile phase):
* emake failed
*
* Call stack:
* ebuild.sh, line 93: Called src_compile
* environment, line 4744: Called die
* The specific snippet of code:
* emake bootstrap || die "emake failed"
*
* If you need support, post the output of `emerge --info '=sys-devel/gcc-apple-4.2.1_p5666-r2::gentoo_prefix'`,
* the complete build log and the output of `emerge -pqv '=sys-devel/gcc-apple-4.2.1_p5666-r2::gentoo_prefix'`.
*
* Please include /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/gcc-build-logs.tar.bz2 in your bug report
*
* The complete build log is located at '/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/temp/build.log'.
* The ebuild environment file is located at '/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/temp/environment'.
* Working directory: '/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build'
* S: '/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/gcc-5666.3'
Created attachment 363176 [details]
/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/gcc-build-logs.tar.bz2
Here goes my build logs of sys-devel/gcc-apple-4.2.1_p5666-r2 (I copied from sys-devel/gcc-apple-4.2.1_p5666-r1.ebuild and only applied previous patch).
Mac OS has no /usr/include/ directory. I now have no any clue for this error. Any suggestion?
(In reply to Linlin Yan from comment #4) > Created attachment 363176 [details] > /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/ > build/gcc-build-logs.tar.bz2 > > Here goes my build logs of sys-devel/gcc-apple-4.2.1_p5666-r2 (I copied from > sys-devel/gcc-apple-4.2.1_p5666-r1.ebuild and only applied previous patch). Thanks. I agree that the logic seems flawed by redefining the same thing. I am a little scared of changing the code though. > Mac OS has no /usr/include/ directory. I now have no any clue for this > error. Any suggestion? I can't find it right now, but I seem to recall having the same problem. Something to do with installing the command-line/UNIX part of xcode. This had to be done from xcode itself. Thank you! That does help. I downloaded "Command Line Tools (OS X Mavericks) for Xcode - Late October 2013" from Apple Developer site (https://developer.apple.com/downloads/index.action) and installed it. Now Gentoo Prefix installation stage3 on my MacBook Pro is going on. Created attachment 363192 [details]
$EPREFIX/usr/portage/sys-devel/gcc-apple/gcc-apple-4.2.1_p5666-r2.ebuild
Finally, I have ensured that my patch (using 'static inline' instead of 'extern inline') could solve this problem, with 'Command Line Tools (OS X Mavericks) for Xcode - Late October 2013' installed.
Now sys-devel/gcc-apple-4.2.1 could be emerged during stage3 (on Mavericks) successfully.
Also confirmed this issue with OSX 10.8 and Xcode 5.0.2 (and command line tool) Though I haven't tried the patch yet. *** Bug 491580 has been marked as a duplicate of this bug. *** *** Bug 493820 has been marked as a duplicate of this bug. *** mailing list discussion http://article.gmane.org/gmane.linux.gentoo.alt/6818 related forum post https://forums.gentoo.org/viewtopic-p-7463666.html Using gcc-apple-4.2.1_p5666-r2.ebuild and its patch on MacOS/X 10.9.1 and XCode 5.0.2 and clang --version "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix" works perfect. Should I recompile gcc r1 with gcc r2 and rebuild my portage tree? After applying patch, python3 failed to install because it was using old clang yet. Doing a hash -r and running stage3 did work. Patch works for me as well, it allows a complete stage3 bootstrap IME. Google suggests many gcc issues in MacPorts/Homebrew related to this issue. I think it should be committed without a revbump since it only effects a platform not really supported (yet). FWIW, depends how 'hacky' you want to be since after you install the patched gcc once, you can install the unpatched one. In the interest of 'maintaining less patches' - I'll let Fabian decide the preferred approach. the patch isn't ok... for the initial bootstrap it's fine as a hack, but I'd prefer a better maintainable workaround Who/where is the source of this patch exactly?
My workaround concept is as follows:
In stage3:
1) Modify bootstrap_prefix.sh to download above patch and place in $EPREFIX/etc/portage/patches/<...>
2) modify bootstrap_prefix.sh to add post_src_install() { epatch_user; } to profile.bashrc (so it is removed after --sync)
3) remove etc/portage/patches after complete
Testing now. Will post patch to bootstrap_prefix.sh here before committing if this approach sounds ok.
*** Bug 496096 has been marked as a duplicate of this bug. *** Created attachment 366720 [details, diff]
bootstrap-prefix.sh patch
Proposed workaround added to bootstrap-prefix.sh
Patched bootstrap script works for me - now I run into bug 496398, hope that's not related... Well, I suggest pushing the workaround and seeing what people report. Works for me, and a few others. *** Bug 500214 has been marked as a duplicate of this bug. *** *** Bug 500214 has been marked as a duplicate of this bug. *** This patch does not match the current bootstrap-prefix.sh.
To run, replace the line
pkgs=( ${pkgs[@]} sys-devel/binutils-apple )
with the line
local linker=sys-devel/binutils-apple
In addition, currently, the file http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar.bz2 is damaged, so replace the line
do_tree http://prefix.gentooexperimental.org/distfiles prefix-overlay-${PV}.tar.bz2
with the line
do_tree http://prefix.gentooexperimental.org/distfiles prefix-overlay-20140122.tar.bz2
(In reply to sritchie from comment #25) > In addition, currently, the file > http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar. > bz2 is damaged, so replace the line what do you mean by "damaged"? The file from http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar.bz2 results in an error such as bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? Possible reason follows. bzip2: Undefined error: 0 Input file = /Users/username/Gentoo/usr/portage/distfiles/prefix-overlay-20140202.tar.bz2, output file = (stdout) The bootstrap-prefix.sh patch not applying is known. (In reply to sritchie from comment #27) > The file from > http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar. > bz2 results in an error such as Works for me. (In reply to Jeremy Olexa (darkside) from comment #28) > The bootstrap-prefix.sh patch not applying is known. > > (In reply to sritchie from comment #27) > > The file from > > http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar. > > bz2 results in an error such as > > Works for me. Fails for me on Darwin as well (at work with a proxy inbetween). Interestingly the size of the downloaded thing doesn't match whatever is on the server. Snapshot on server is 68M, what I have on the box that fails to unpack is only 21M. Wget seems to think (due to the proxy?) that the file is 21M. (In reply to Fabian Groffen from comment #29) > (In reply to Jeremy Olexa (darkside) from comment #28) > > The bootstrap-prefix.sh patch not applying is known. > > > > (In reply to sritchie from comment #27) > > > The file from > > > http://prefix.gentooexperimental.org/distfiles/prefix-overlay-20140202.tar. > > > bz2 results in an error such as > > > > Works for me. > > Fails for me on Darwin as well (at work with a proxy inbetween). > Interestingly the size of the downloaded thing doesn't match whatever is on > the server. > > Snapshot on server is 68M, what I have on the box that fails to unpack is > only 21M. Wget seems to think (due to the proxy?) that the file is 21M. prefix-overlay-20140202.tar.bz2 fails to unpack for me too. However prefix-overlay-20140201.tar.bz2 works just fine. I pointed bootstrap-prefix.sh to prefix-overlay-20140201.tar.bz2 and was able to proceed. It doesn't look like it's a proxy issue because I have a direct connection. The 20140202 file is indeed only 21M. And it's not just wget; if you open http://prefix.gentooexperimental.org/distfiles in a browser, it shows the same size. (In reply to Alexei Zakharov from comment #30) > It doesn't look like it's a proxy issue because I have a direct connection. > The 20140202 file is indeed only 21M. And it's not just wget; if you open > http://prefix.gentooexperimental.org/distfiles in a browser, it shows the > same size. A small correction: in my case the 20140202 file was fetched from http://distfiles.gentoo.org/distfiles/, where its size is 21M. On http://prefix.gentooexperimental.org/distfiles, its size is 68M. So the issue is probably with the incomplete mirror of the overlay file. (In reply to Alexei Zakharov from comment #31) > A small correction: in my case the 20140202 file was fetched from > http://distfiles.gentoo.org/distfiles/, where its size is 21M. On Confirmed and removed from the mirrors (with usual propagation lag) PS. This should have been a new bug report. Comment on attachment 366720 [details, diff]
bootstrap-prefix.sh patch
Given that bootstrap-prefix.sh has undergone 24 changes in the past 10 days, I'm marking the patch obsolete until development settles, the following is the important part:
echo "post_src_prepare() { epatch_user; }" >> "${PORTDIR}/profiles/prefix/profile.bashrc"
mkdir -p "${EPREFIX}"/etc/portage/patches/sys-devel/gcc-apple
"${EPREFIX}"/tmp/usr/bin/wget ${GENTOO_MIRRORS}/experimental/prefix/patches/gcc-apple-4.2.1-inline.patch -O "${EPREFIX}"/etc/portage/patches/sys-devel/gcc-apple/gcc-apple-4.2.1-inline.patch
I can confirm that the attached patch makes gcc-apple build. I have not thoroughly inspected the code touched by patch, so I cannot comment on its quality, but the idea of patching sys-devel/gcc-apple to use a subset of C89 and C99 that works regardless of which are chosen is a good approach. However, I am not convinced it is worth the cost to benefit ratio to go nuts with that approach. Given that sys-devel/gcc-apple is only built on Mac OS X, it probably isn't a horrible idea to just apply it to sys-devel/gcc-apple without much thought beyond deciding that it causes no regressions. I feel we could avoid future-proof things by inserting -std=gnu89 into the right places in the build system. If Clang doesn't cooperate with that (and without the above patch), it could be filed with LLVM as a bug in Clang. I used the ./bootstrap-prefix.sh with the folowing settings:
export EPREFIX="$HOME/Gentoo"
export ARCH="x86_64-apple-darwin13"
./bootstrap-prefix.sh
Then the gcc extern inline error apperas.
Now setup the patch:
echo "post_src_prepare() { epatch_user; }" >> /Users/xenoist/Gentoo/usr/portage/profiles/prefix/darwin/macos/10.9/profile.bashrc
mkdir -p "${EPREFIX}"/etc/portage/patches/sys-devel/gcc-apple
wget --no-check-certificate "https://bugs.gentoo.org/attachment.cgi?id=363174" -O "${EPREFIX}"/etc/portage/patches/sys-devel/gcc-apple/gcc-apple-4.2.1-inline.patch
./bootstrap-prefix.sh
gcc compiles now.
it actually needs -std=gnu89 (the default GCC uses). I've committed the necessary fixes, need to bump the snapshot tomorrow. Fixed in today's snapshot Confirmed bootstrap out of box for OSX 10.9(.2 for me). Thanks. Confirmed success, OS X 10.9.2, fresh bootstrap beginning March 1, 2014, using USE_LATEST_TREE_YES=1 ./bootstrap-prefix.sh (In reply to sritchie from comment #40) > Confirmed success, OS X 10.9.2, fresh bootstrap beginning March 1, 2014, > using > > USE_LATEST_TREE_YES=1 ./bootstrap-prefix.sh I'll just clarify here because people will find this bug report later. USE_LATEST_TREE is never recommended unless you are testing/fixing bugs (advanced user). In this case latest tree and snapshot are very similar |
I was trying to rebuild Gentoo Prefix from the beginning on my MacBook Pro (Mavericks). During stage3 (after solved issue 490932), it failed when emerging sys-devel/gcc-apple-4.2.1_p5666-r1, with the following error messages: /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r1/work/gcc-5666.3/gcc/toplev.c:564:1: error: redefinition of a 'extern inline' function 'floor_log2' is not supported in C99 mode floor_log2 (unsigned HOST_WIDE_INT x) ^ /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r1/work/gcc-5666.3/gcc/toplev.h:174:1: note: previous definition is here floor_log2 (unsigned HOST_WIDE_INT x) ^ /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r1/work/gcc-5666.3/gcc/toplev.c:599:1: error: redefinition of a 'extern inline' function 'exact_log2' is not supported in C99 mode exact_log2 (unsigned HOST_WIDE_INT x) ^ /Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r1/work/gcc-5666.3/gcc/toplev.h:180:1: note: previous definition is here exact_log2 (unsigned HOST_WIDE_INT x) ^ 5 warnings and 2 errors generated. make[3]: *** [toplev.o] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 emake failed Reproducible: Always I checked the source files and found that: In 'work/gcc-5666.3/gcc/toplev.h', it defines: #if GCC_VERSION >= 3004 ... extern inline int floor_log2 (unsigned HOST_WIDE_INT x) { ... #endif However, in 'work/gcc-5666.3/gcc/toplev.c', the condition of #if is changed as: #if GCC_VERSION < 3004 || !defined (__cplusplus) ... int floor_log2 (unsigned HOST_WIDE_INT x) { ... #endif #endif