|
Description
Robin Randhawa
2019-09-03 20:21:04 UTC
Created attachment 589012 [details]
Log containing compile failure info for binutils
Created attachment 589014 [details]
stage2.log.gz
Can confirm, on cleanish 2019 iMac 27". Will update with log file once it syncs. There appears to be something wrong with the clang preprocessor.
Explanation:
1. First get to a point where you see the bootstrap failing as per the log originally added to this bug. At that point you see messages akin to:
make[2]: Entering directory '/Users/robin/Gentoo/tmp/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r1/work/cctools-895/libstuff/dynamic_obj'
.
.
.
clang -m64 -I../../include -Wall -march=native -O2 -pipe -c -o ./errors.o ../errors.c
In file included from ../errors.c:24:
In file included from /usr/include/stdlib.h:66:
In file included from /usr/include/sys/wait.h:109:
In file included from /usr/include/sys/signal.h:146:
In file included from /usr/include/machine/_mcontext.h:29:
/usr/include/i386/_mcontext.h:108:2: error: unknown type name
'_STRUCT_X86_THREAD_FULL_STATE64'
_STRUCT_X86_THREAD_FULL_STATE64 __ss;
^
2. Let's isolate the problem to this particular errors.c file.
$ cd Users/robin/Gentoo/tmp/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r1/work/cctools-895/libstuff/dynamic_obj
$ clang -m64 -I../../include -Wall -march=native -O2 -pipe -c -o ./errors.o ../errors.c
In file included from ../errors.c:24:
In file included from /usr/include/stdlib.h:66:
In file included from /usr/include/sys/wait.h:109:
In file included from /usr/include/sys/signal.h:146:
In file included from /usr/include/machine/_mcontext.h:29:
/usr/include/i386/_mcontext.h:108:2: error: unknown type name
'_STRUCT_X86_THREAD_FULL_STATE64'
_STRUCT_X86_THREAD_FULL_STATE64 __ss;
^
3. The needle of suspicion at this point is on this hunk of code in /usr/include/mach/i386/_structs.h:
/*
* 64 bit versions of the above (complete)
*/
#if __DARWIN_UNIX03
#define _STRUCT_X86_THREAD_FULL_STATE64 struct __darwin_x86_thread_full_state64
_STRUCT_X86_THREAD_FULL_STATE64
{
_STRUCT_X86_THREAD_STATE64 ss64;
__uint64_t __ds;
__uint64_t __es;
__uint64_t __ss;
__uint64_t __gsbase;
};
#else /* !__DARWIN_UNIX03 */
#define _STRUCT_X86_THREAD_FULL_STATE64 struct x86_thread_full_state64
_STRUCT_X86_THREAD_FULL_STATE64
{
_STRUCT_X86_THREAD_STATE64 ss64;
__uint64_t ds;
__uint64_t es;
__uint64_t ss;
__uint64_t gsbase;
};
#endif /* !__DARWIN_UNIX03 */
Code above and below this hunk is correctly processed by the clang preprocessor but not this hunk.
4. Editing this file to try and play with this hunk is not straightforward thanks to Apple's SIP (system integrity protection) which won't allow anything in /usr/include to be edited, even as root. There are workarounds but they are invasive (pre-boot system configuration mods).
5. To try and edit this file and in the process demonstrate some puzzling behaviour, let's simulate the build of errors.c in a location outside the prefix taking care to copy all the header file dependencies appropriately and modifying clang's header inclusion directives. For this I had to do the following:
$ mkdir /tmp/test && cd /tmp/test
$ cp -R /usr/include .
$ mkdir extra-include
$ cp -R /Volumes/prefix/Gentoo/tmp/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r1/work/cctools-895/include/stuff extra-include
$ cp /Volumes/prefix/Gentoo/tmp/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r1/work/cctools-895/libstuff/errors.c .
$ clang -m64 -Iinclude/ -Iextra-include/ -Wall -march=native -O2 -pipe -c -o errors.o errors.c
This succeeds!!!
I can't explain this but hoping the above helps someone else see something I'm missing.
Some additional data points:
1. Go back to the failure location within the prefix
$ cd /Volumes/prefix/Gentoo/tmp/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r1/work/cctools-895/libstuff/dynamic_obj
2. Confirm that the 'standard' build invocation fails
$ clang -m64 -I../../include -Wall -march=native -O2 -pipe -c -o ./errors.o ../errors.c
In file included from ../errors.c:24:
In file included from /usr/include/stdlib.h:66:
In file included from /usr/include/sys/wait.h:109:
In file included from /usr/include/sys/signal.h:146:
In file included from /usr/include/machine/_mcontext.h:29:
/usr/include/i386/_mcontext.h:108:2: error: unknown type name '_STRUCT_X86_THREAD_FULL_STATE64'
_STRUCT_X86_THREAD_FULL_STATE64 __ss;
^
/usr/include/i386/_mcontext.h:124:2: error: unknown type name '_STRUCT_X86_THREAD_FULL_STATE64'
_STRUCT_X86_THREAD_FULL_STATE64 __ss;
^
2 errors generated
3. Change the include path such that the previously created copy in /tmp/test is used
$ clang -m64 -I /tmp/test/extra-include/ -Wall -march=native -O2 -pipe -c -o ./errors.o ../errors.c
$ echo ?
0
4. So the above works. Now let's get the diff of the preprocessed output from both the failing and the successful builds
$ clang -m64 -I../../include -Wall -march=native -O2 -pipe -E ../errors.c > bad.txt
$ clang -m64 -I /tmp/test/extra-include/ -Wall -march=native -O2 -pipe -E ../errors.c > good.txt
$ diff bad.txt good.txt
$ diff bad.txt good.txt | grep -i full
> struct __darwin_x86_thread_full_state64
< _STRUCT_X86_THREAD_FULL_STATE64 __ss;
> struct __darwin_x86_thread_full_state64 __ss;
< _STRUCT_X86_THREAD_FULL_STATE64 __ss;
> struct __darwin_x86_thread_full_state64 __ss;
> struct __darwin_mcontext_avx512_64_full
> struct __darwin_x86_thread_full_state64 __ss;
> typedef struct __darwin_x86_thread_full_state64 x86_thread_full_state64_t;
5. So somehow, having the libstuff headers outside of the prefix is OK but within is a problem ?
The problem: headers provided by the cctools tarball (required by the binutils-apple ebuild) conflict with those located at /usr/include. The binutils-apple ebuild fetches https://opensource.apple.com/tarballs/cctools/cctools-895.tar.gz. cctools-895/include/mach/i386 contains: _structs.h fp_reg.h thread_state.h thread_status.h .. these are redundant since they are provided by: /usr/include/mach/i386 containing: _structs.h asm.h boolean.h exception.h fp_reg.h kern_return.h ndr_def.h processor_info.h rpc.h sdt_isa.h thread_state.h thread_status.h vm_param.h vm_types.h The compilation failures reported by the original bug report occur because /usr/include/mach/i386/_structs.h introduces _STRUCT_X86_THREAD_FULL_STATE64 which is missing in the cctools version of _structs.h. I think a reasonable fix would be to conditionally patch out the mach subdir from within the cctools tarball. The conditions would be that the host is macos and the arch is x86_64. My gentoo ebuild foo is not strong so at this point I'll have to call it! hey, thanks, the problem on Mojave is that Apple decided to mess up header locations, and I haven't found a solution yet. What worked in the past was hackishly installing the headers in /, but I don't know if this still works today. Updating to include logfile: https://triffid.madbotany.com/nextcloud/index.php/s/kALAbHwXPrZtCQH (In reply to Fabian Groffen from comment #7) > hey, thanks, the problem on Mojave is that Apple decided to mess up header > locations, and I haven't found a solution yet. What worked in the past was > hackishly installing the headers in /, but I don't know if this still works > today. Thanks. This is complicated now by Apple's System Integrity Protection (aka rootless mode). Root isn't allowed to write to / anymore - unless SIP is disabled. That's not the way to go anyway. Based on a tip from xdej on #gentoo-prefix, the following hack seems to have made the binutils build succeed. Note however that this was followed by breakage of libarchive which may mean that even though the binutils build succeeded, it's fundamentally flawed somehow. Instructions: 1. Start the bootstrap script. 2. Suspend it and patch $EPREFIX/var/db/repos/gentoo/sys-devel/binutils-apple/binutils-apple-8.2.1-r1.ebuild using the attached patch. 3. Resume the bootstrap script. Created attachment 589078 [details, diff]
Patch to binutils-apple-8.2.1-r1.ebuild
It looks like the version of sys-devel/binutils-apple corresponds to the version of Xcode (as listed on https://opensource.apple.com/). I currently have XCode 12.1, which is not listed on https://opensource.apple.com/ (yet?). The most recent version listed is 11.3.1. Has anyone tried bumping binutils-apple to 11.3.1: ld64-530 cctools-949.0.1 And then dyld is listed under macOS versions. The latest is: dyld-750.6 So, what kind of pain can I expect if I try to bump these? FYI, here's my chart of deps: XCode-12 (Source Unreleased) ld64-??? cctools-??? XCode-11.3.1 ld64-530 cctools-949.0.1 XCode-11.2.1 ld64-520 cctools-949.0.1 XCode-11.0 ld64-512.4 cctools-949.0.1 XCode-10.2 ld64-450.3 cctools-927.0.2 XCode-10.1,10.0 ld64-409.12 cctools-921 XCode-9.4.1,9.4,9.3.1,9.3 ld64-351.8 cctools-906 XCode-9.2 ld64-305 cctools-900 XCode-9.1 ld64-302.3.1 cctools-900 XCode-9.0.1,9.0 ld64-302.3 cctools-900 XCode-8.3.3,8.3.2,8.3.1,8.3 ld64-278.4 cctools-898 XCode-8.2.1 ld64-274.2 cctools-895 <== binutils-apple-8.2.1-r1 (2019) XCode-8.1,8.0 ld64-274.1 cctools-895 <== binutils-apple-8.1 (2019) XCode-7.3.1 ld64-264.3.102 cctools-886 <== binutils-apple-7.3.1 (2017) XCode-7.2 ld64-253.9 cctools-877.8 <== binutils-apple-7.2-r1 XCode-7.1 ld64-253.6 cctools-877.7 <== binutils-apple-7.1-r1 XCode-7.0 ld64-253.3 cctools-877.5 <== binutils-apple-7.0-r1 macOS-10.15.6 dyld-750.6 macOS-10.15.4-10.15.5 dyld-750.5 macOS-10.15.2-10.15.3 dyld-733.8 macOS-10.15.1 dyld-733.6 macOS-10.15 dyld-732.8 macOS-10.14.4-10.14.6 dyld-655.1.1 macOS-10.14.3 dyld-655.1 macOS-10.14.2 dyld-640.2 macOS-10.14.1 dyld-635.2 macOS-10.14 dyld-625.13 macOS-10.13.6 dyld-551.4 macOS-10.13.4-10.13.5 dyld-551.3 macOS-10.13.2-10.13.3 dyld-519.2.2 macOS-10.13-10.13.1 dyld-519.2.1 macOS-10.12.4-10.12.6 dyld-433.5 macOS-10.12.1-10.12.3 dyld-421.2 <== binutils-apple-8.2.1-r1,8.1 macOS-10.12 dyld-421.1 macOS-10.11.5-10.11.6 dyld-360.22 macOS-10.11.4 dyld-360.21 macOS-10.11.3 dyld-360.19 macOS-10.11.2 dyld-360.18 libunwind-35.3 <== binutils-apple-7.3.1,7.2-r1 macOS-10.11.1 dyld-360.17 libunwind-35.3 <== binutils-apple-7.1-r1 macOS-10.11 dyld-360.14 libunwind-35.3 <== binutils-apple-7.0-r1 [Note: https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=8559e1c3e77e54115746b61ad58d8a492ce8b024 https://bugs.gentoo.org/730476#c10] Oh. I didn't have to create that chart, or at least the xcode/ld64/cctools version mapping. It's available here: https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_12.x_(since_Free_On-Device_Development) RE: https://bugs.gentoo.org/730476#c9 > I also tried to upgrade binutils-apple to a recent version and even rebased > patches to ld64-409.12 (I don't remember why I picked this version) but found > that the effort needed is higher than I can afford at the moment. ld64-409.12 would have been in Xcode 10.0 and 10.1, so that's probably the version of Xcode that Alexander had installed. native-cctools is one route version bumping (leaping?) is another route. > Bug 693444 looks like a kind of memory corruption (or rather depending on uninitialized memory) in clang. I wonder if this has been resolved in the latest versions of clang, ld64 and friends so that we can use it now? I have updated most of the binutils-apple patches. I hit a bunch of missing header errors, most of which were resolved by passing -c++-isystem into CPPFLAGS (see https://bugs.gentoo.org/730476#c28). Now the next problem I'm having is with TAPI. The changes from ld64-274.1-notapi.patch are not sufficient to disable tapi. There are a lot more places in the code that use tapi, so disabling it is not going to be simple. What if sys-devel/binutils-apple-11.3.1 (the version I'm working on) also provided tapi (instead of providing it in sys-libs/tapi)? Or it could be behind a bootstrap useflag that is only enabled during stage2? FYI, these are the versions I'm working with: ld64-530 (Xcode 11.3.1) cctools-949.0.1 (Xcode 11.3.1) dyld-750.6 (macOS 10.15.6) Created attachment 674602 [details]
WIP: binutils-apple ebuild v11.3.1
Created attachment 674605 [details]
WIP: updated ld64 Makefile
Created attachment 674608 [details, diff]
updated ld64 No LTO patch
Created attachment 674611 [details, diff]
WIP: updated ld64 No TAPI patch
Created attachment 674614 [details, diff]
Updated binutils-apple devtools-dir patch
Created attachment 674617 [details, diff]
Updated binutils-apple llvm prefix patch
With TAPI (as well as unwind) it is a bit a question if the LLVM variants (as provided by their respective packages) are correct/sufficient. Apple has a habit of using odd versions, sometimes modified, hence the inclusion. As for TAPI, I don't think making it optional is going to work anymore. Apple heavily relies on these text-based sort of object meta-caches, so if you can include it, and get it to compile as part of binutils-apple, that would be a pro. Thanks for your continued efforts! Created attachment 675244 [details]
binutils-apple ebuild v11.3.1
Created attachment 675247 [details]
Updated ld64 Makefile
Yes, I had to adjust bootstrap-prefix.sh, and I've forcefully enabled tapi in the latest version (ebuild attached), which builds just fine. relevant bootstrap-prefix.sh change: - add bootstrap_libtapi https://gist.github.com/cognifloyd/f4ff46e3dcfd48ca9827c32e04a8fe90/fbd9d6e772f93fcd3481d2ab775153440757f097#file-bootstrap-prefix-sh-L1383-L1407 - call it in stage1 https://gist.github.com/cognifloyd/f4ff46e3dcfd48ca9827c32e04a8fe90/fbd9d6e772f93fcd3481d2ab775153440757f097#file-bootstrap-prefix-sh-L1530-L1533 I recently found this: https://github.com/iains/darwin-xtools It perhaps is a proper replacement, although it needs cmake. Created attachment 675292 [details]
binutils-apple ebuild v11.3.1
I cleaned out most of my comments in the ebuild. For reference here is the state of the patches:
| binutils-apple-8.2.1-r1 | status comment | binutils-apple-11.3.1 |
+------------------------------------------------+--------------------+---------------------------------------------------+
| ld64-136-compile_stubs.h | fine | no change |
| ld64-274.2-Makefile | updated | ld64-530-Makefile |
| ld64-274.1-nolto.patch | updated | ld64-530-nolto.patch |
| ld64-236.3-crashreporter.patch | fine (it's minor) | no change |
| ld64-264.3.102-bitcode-case.patch | fixed upstream | dropped |
| ld64-274.1-unknown-fixup.patch | fixed upstream | dropped |
| ld64-274.1-notapi.patch | tapi required now | dropped |
| ld64-274.1-cfi-info-type.patch | fixed upstream | dropped |
| ld64-236.3-missing-cputypes.patch | fixed upstream | dropped |
| ld64-123.2-debug-backtrace.patch | ignore MacOS <10.5 | dropped |
| binutils-apple-4.5-as.patch | fine | no change |
| binutils-apple-5.1-as-dir.patch | fine | no change |
| binutils-apple-5.1-ranlib.patch | fine | no change |
| binutils-apple-3.1.1-libtool-ranlib.patch | fine | no change |
| cctools-839-intel-retf.patch | fine | no change |
| binutils-apple-4.0-no-oss-dir.patch | fine | no change |
| binutils-apple-5.1-extraneous-includes.patch | fine | no change |
| binutils-apple-5.1-strnlen.patch | fine | no change |
| binutils-apple-7.3-make-j.patch | fine | no change |
| binutils-apple-7.3-no-developertools-dir.patch | updated | binutils-apple-11.3.1-no-developertools-dir.patch |
| binutils-apple-8.2.1-llvm-prefix.patch | updated | binutils-apple-11.3.1-llvm-prefix.patch |
| binutils-apple-8.2.1-llvm-shim.patch | fine | no change |
| not present | new bugfix | binutils-apple-11.3.1-nolto-fix.patch |
| not present | new bugfix | binutils-apple-11.3.1-segaddrtable-fix.patch |
Also, I found that the headers in dyld-750.6 and dyld-655.1.1 have changes that are incompatible (cause build errors).
So, I used dyld-551.4 which was released with macOS 10.13.6 (approximately the same time as Xcode 11).
There are still a couple of TODOs in the ebuild:
1 - around cleaning unwanted CFLAGS.
The cctools/as/Makefile has the -g flag in it's driver_build targets.
The -g flag was dropped everywhere else. Should we drop it here as well?
2 - Do we want to install libprunetrie.a? We are currently not installing it.
yes, we want to drop -g -O/O2/Os/etc everywhere I don't think providing libprunetrie.a is useful. I assume it's linked into the objects that required them. We don't install prunetrie headers, do we? Created attachment 675295 [details, diff]
updated ld64 No LTO patch
One more section in ld64 needed the LTO ifdef.
Created attachment 675376 [details]
binutils-apple ebuild v11.3.1
K. This version of the 11.3.1 ebuild:
- drops the prunetrie TODO, as we do not install headers. It gets generated in ld64 and then compiled into object(s) in cctools.
- re-enables the sed expression to remove the last of the -g flags (I had added it but put it in a comment).
- adds an SRC_URI entry for binutils-apple-patches-11.3-r1.tar.bz2 (which needs to be created).
- replaces all of the FILESDIR vars with S, assuming that they will be included in the new patches tar.bz2 file.
I suspect we could drop some of the patches from SRC_URI.
darwin-xtools looks interesting, but: > 2.2.1 - September 2017 > > Updated to ld64-274.2 (from XCode 8.2.1 sources). Include libtapi if it's available. That's the last time the changelog says the ld64 sources were updated from upstream. from the ld64-master branch, it looks like there were also updates to ld64-409. I'm concerned that the project will lag significantly in getting support for apple silicone or any of the newer features. (no idea what features those are, but if we want to build the latest sources from Apple for other things, we need to keep up as much as possible with the tooling. Plus, you already pointed out that it uses cmake, which currently doesn't get built until just before building llvm/clang. Moving that earlier in bootstrap might be problematic. Created attachment 675382 [details, diff]
bugfix patch for nolto
Created attachment 675385 [details, diff]
bugfix patch for seg_addr_table
(In reply to Jacob Floyd from comment #31) > darwin-xtools looks interesting, but: > > > 2.2.1 - September 2017 > > > > Updated to ld64-274.2 (from XCode 8.2.1 sources). Include libtapi if it's available. > > That's the last time the changelog says the ld64 sources were updated from > upstream. from the ld64-master branch, it looks like there were also updates > to ld64-409. I'm concerned that the project will lag significantly in > getting support for apple silicone or any of the newer features. (no idea > what features those are, but if we want to build the latest sources from > Apple for other things, we need to keep up as much as possible with the > tooling. > > Plus, you already pointed out that it uses cmake, which currently doesn't > get built until just before building llvm/clang. Moving that earlier in > bootstrap might be problematic. Since Iain is the one to implement SI for GCC, I somehow hope this one might receive updates if necessary. But I agree to keep this one on the side for now. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f3826c28e296d98a50d7423c80041c3df0c86cd commit 6f3826c28e296d98a50d7423c80041c3df0c86cd Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-11-27 15:33:15 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-11-27 15:33:15 +0000 sys-devel/binutils-apple-11.3.1: version bump by Jacob Floyd, #693444 Closes: https://bugs.gentoo.org/693444 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/binutils-apple/Manifest | 4 + .../binutils-apple/binutils-apple-11.3.1.ebuild | 374 +++++++++++++++++++++ 2 files changed, 378 insertions(+) |
