ld/parsers/libunwind/DwarfInstructions.hpp:974:2: error: redeclaration of 'compile_time_assert_failed' with a different type: 'int [((int)CFI_Parser<A>::kMaxRegisterNumber > (int)DW_X86_64_RET_ADDR) ? 1 : -1]' vs 'int [1]' COMPILE_TIME_ASSERT( (int)CFI_Parser<A>::kMaxRegisterNumber > (i... ^ ld/parsers/libunwind/InternalMacros.h:50:14: note: expanded from macro 'COMPILE_TIME_ASSERT' extern int compile_time_assert_failed[ ( expr ) ? 1 : -... ^ ld/parsers/libunwind/Registers.hpp:1134:2: note: previous declaration is here COMPILE_TIME_ASSERT( sizeof(Registers_arm64) < sizeof(unw_context_t) ); ^
I'm doing work on 8.1, but that one has some issues with a new "tapi" that is nowhere to be found.
FYI, I tried the system clang on MacOS Sierra (10.12.2), i.e., Apple LLVM version 8.0.0 (clang-800.0.42.1). It could compile binutils-apple.
(In reply to yuex from comment #2) > FYI, I tried the system clang on MacOS Sierra (10.12.2), i.e., Apple LLVM > version 8.0.0 (clang-800.0.42.1). It could compile binutils-apple. Does that constitute (part of) a workaround for this issue, in some way? (Yes, I am quite keen to get Prefix running on this MacBook that's in front of me...)
(In reply to Rutger van Bergen from comment #3) > (In reply to yuex from comment #2) > > FYI, I tried the system clang on MacOS Sierra (10.12.2), i.e., Apple LLVM > > version 8.0.0 (clang-800.0.42.1). It could compile binutils-apple. > > Does that constitute (part of) a workaround for this issue, in some way? > (Yes, I am quite keen to get Prefix running on this MacBook that's in front > of me...) You can just comment out those COMPILE_TIME_ASSERT invocations. From its name, it should not affect runtime behavior once it has compiled. But you have to make a patch, and add it to the ebuild file.
(In reply to Rutger van Bergen from comment #3) > (In reply to yuex from comment #2) > > FYI, I tried the system clang on MacOS Sierra (10.12.2), i.e., Apple LLVM > > version 8.0.0 (clang-800.0.42.1). It could compile binutils-apple. > > Does that constitute (part of) a workaround for this issue, in some way? > (Yes, I am quite keen to get Prefix running on this MacBook that's in front > of me...) Nope. Swapping clang to system's can compile this package but will fail on others later
actual fix for clang is in: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160829/169553.html I think working around it is easier for the moment.
You can also just edit make.conf to use system's clang. When this package gets compiled, Ctrl-C out to switch back. And bootstrap again. I remember this can bring you to stage3 where other packages (one or two, I can't remember) will fail. But somehow you can manage it to emerge -e system. Then the prefix it workable if you generate the startprefix script manually or from the internet. To pass emerge -e system, you have to modify ebuild file. Just a little bit off-topic that I bootstrapped successfully several days ago after DIY ed some patches to several packages. But the fact is that I finally decided to use macports. It's somehow a primitive version of portage. Some features are missing. And some others are no match to emerge. But still it provides something like Portage. I also tried to use docker to chroot a data volume to install amd64 gentoo. But the mapped filesystem IO is too slow to be productive. Gentoo Prefix on OSX is a cool idea. I'm sure that it will get better if more people contribute. I'll keep an eye on it.
Sorry to hear that! Thanks for trying though. I've pushed a fix for the 3.7.1 ebuild. Should go in tomorrow's snapshot.
Thanks to you both for responding so quickly and thoroughly. I appreciate there are "easier" alternatives for installing and running Linux packages on macOS, but I am going to stick with Gentoo Prefix. I've been a Gentoo user since the days when stage3 tarballs were considered cop-outs for wimps, and not running "emerge --sync && emerge -DuNa world" at least once a week would almost certainly leave portage broken beyond repair. I'm just a big fan of the basic Gentoo concept, and I find the idea of applying it to a context that is not friendly towards it irresistibly charming. And yes, I understand and accept that currently, this translates to a process of "try, try, and try again", with a lot of patience mixed into it. Although patience is not one of my fortes, it simply is what it is. So, I will await the snapshot with the fix for the 3.7.1 ebuild, and then see how much further I get with that.
I have just successfully completed the build of binutils-apple-7.3.1 with the ebuild that includes the COMPILE_TIME_ASSERT sed invocation.
I bumped the snapshot, testing a bootstrap as I type. I assume this particular problem is fixed now, thanks! :)
