Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 491098 - sys-devel/gcc-apple-4.2.1_p5666-r1: compile failed for redefinition of a 'extern inline' function
Summary: sys-devel/gcc-apple-4.2.1_p5666-r1: compile failed for redefinition of a 'ext...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All OS X
: Normal normal (vote)
Assignee: Gentoo Prefix
URL: http://trac.macports.org/ticket/34639
Whiteboard:
Keywords:
: 491580 493820 496096 500214 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-11-12 16:40 UTC by Linlin Yan
Modified: 2014-03-02 13:31 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for correct 'inline' functions 'floor_log2' and 'exact_log2' (gcc-apple-4.2.1-inline.patch,1.79 KB, patch)
2013-11-13 03:19 UTC, Linlin Yan
Details | Diff
/Users/yanll/Gentoo/var/tmp/portage/sys-devel/gcc-apple-4.2.1_p5666-r2/work/build/gcc-build-logs.tar.bz2 (gcc-build-logs.tar.bz2,35.28 KB, application/x-bzip2)
2013-11-13 03:24 UTC, Linlin Yan
Details
$EPREFIX/usr/portage/sys-devel/gcc-apple/gcc-apple-4.2.1_p5666-r2.ebuild (gcc-apple-4.2.1_p5666-r2.ebuild,11.42 KB, text/plain)
2013-11-13 12:19 UTC, Linlin Yan
Details
bootstrap-prefix.sh patch (bootstrap-prefix-gcchack.patch,1.06 KB, patch)
2014-01-01 21:05 UTC, Jeremy Olexa (darkside) (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Linlin Yan 2013-11-12 16:40:16 UTC
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
Comment 1 Fabian Groffen gentoo-dev 2013-11-12 19:50:17 UTC
does it help if you set -std=c89 in CFLAGS?  (I suspect they won't get through though)
Comment 2 Linlin Yan 2013-11-13 01:21:25 UTC
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.
Comment 3 Linlin Yan 2013-11-13 03:19:38 UTC
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'
Comment 4 Linlin Yan 2013-11-13 03:24:50 UTC
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?
Comment 5 Fabian Groffen gentoo-dev 2013-11-13 06:46:33 UTC
(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.
Comment 6 Linlin Yan 2013-11-13 09:41:18 UTC
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.
Comment 7 Linlin Yan 2013-11-13 12:19:12 UTC
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.
Comment 8 aleiphoenix 2013-11-14 16:48:26 UTC
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.
Comment 9 Fabian Groffen gentoo-dev 2013-11-21 14:47:17 UTC
*** Bug 491580 has been marked as a duplicate of this bug. ***
Comment 10 Fabian Groffen gentoo-dev 2013-12-17 20:21:55 UTC
*** Bug 493820 has been marked as a duplicate of this bug. ***
Comment 11 Benda Xu gentoo-dev 2013-12-28 23:30:11 UTC
mailing list discussion

http://article.gmane.org/gmane.linux.gentoo.alt/6818
Comment 12 Benda Xu gentoo-dev 2013-12-28 23:45:11 UTC
related forum post

https://forums.gentoo.org/viewtopic-p-7463666.html
Comment 13 Jayson Reis 2013-12-29 02:42:07 UTC
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?
Comment 14 Jayson Reis 2013-12-29 03:24:32 UTC
After applying patch, python3 failed to install because it was using old clang yet.
Doing a hash -r and running stage3 did work.
Comment 15 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2013-12-30 01:44:16 UTC
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).
Comment 16 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2013-12-30 03:25:06 UTC
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.
Comment 17 Fabian Groffen gentoo-dev 2013-12-30 11:36:16 UTC
the patch isn't ok... for the initial bootstrap it's fine as a hack, but I'd prefer a better maintainable workaround
Comment 18 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2013-12-31 13:53:49 UTC
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.
Comment 19 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2013-12-31 13:55:13 UTC
*** Bug 496096 has been marked as a duplicate of this bug. ***
Comment 20 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-01-01 21:05:28 UTC
Created attachment 366720 [details, diff]
bootstrap-prefix.sh patch

Proposed workaround added to bootstrap-prefix.sh
Comment 21 Volker Wegert 2014-01-04 20:37:57 UTC
Patched bootstrap script works for me - now I run into bug 496398, hope that's not related...
Comment 22 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-01-22 03:15:13 UTC
Well, I suggest pushing the workaround and seeing what people report. Works for me, and a few others.
Comment 23 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-04 02:14:22 UTC
*** Bug 500214 has been marked as a duplicate of this bug. ***
Comment 24 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-04 04:51:58 UTC
*** Bug 500214 has been marked as a duplicate of this bug. ***
Comment 25 sritchie 2014-02-04 20:12:26 UTC
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
Comment 26 Fabian Groffen gentoo-dev 2014-02-04 20:30:51 UTC
(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"?
Comment 27 sritchie 2014-02-04 20:34:16 UTC
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)
Comment 28 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-05 02:14:15 UTC
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.
Comment 29 Fabian Groffen gentoo-dev 2014-02-05 12:35:28 UTC
(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.
Comment 30 Alexei Zakharov 2014-02-05 19:37:17 UTC
(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.
Comment 31 Alexei Zakharov 2014-02-05 19:42:00 UTC
(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.
Comment 32 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-06 03:37:14 UTC
(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 33 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-02-06 03:42:00 UTC
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
Comment 34 Richard Yao gentoo-dev 2014-02-18 19:36:48 UTC
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.
Comment 35 Joerg Neikes 2014-02-27 11:05:32 UTC
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.
Comment 36 Fabian Groffen gentoo-dev 2014-02-28 19:32:39 UTC
it actually needs -std=gnu89 (the default GCC uses).
Comment 37 Fabian Groffen gentoo-dev 2014-02-28 19:41:29 UTC
I've committed the necessary fixes, need to bump the snapshot tomorrow.
Comment 38 Fabian Groffen gentoo-dev 2014-03-01 09:30:22 UTC
Fixed in today's snapshot
Comment 39 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-03-02 04:14:01 UTC
Confirmed bootstrap out of box for OSX 10.9(.2 for me). Thanks.
Comment 40 sritchie 2014-03-02 12:34:46 UTC
Confirmed success, OS X 10.9.2, fresh bootstrap beginning March 1, 2014, using

USE_LATEST_TREE_YES=1 ./bootstrap-prefix.sh
Comment 41 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-03-02 13:31:27 UTC
(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