depends: Issue cross compiling for macOS on Debian Buster #16052

1. 
   fanquake commented at 6:43 AM on May 20, 2019: member

   Using a debian:buster-slim Docker container, available here, doing a depends build for x86_64-apple-darwin14, cctools bombs out with the following in config.log:

   configure:3616: checking for x86_64-pc-linux-gnu-gcc
   configure:3643: result: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang
   configure:3912: checking for C compiler version
   configure:3921: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang --version >&5
   clang version 3.7.1 (tags/RELEASE_371/final)
   Target: x86_64-unknown-linux-gnu
   Thread model: posix
   configure:3932: $? = 0
   configure:3921: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang -v >&5
   clang version 3.7.1 (tags/RELEASE_371/final)
   Target: x86_64-unknown-linux-gnu
   Thread model: posix
   configure:3932: $? = 0
   configure:3921: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang -V >&5
   clang-3.7: error: argument to '-V' is missing (expected 1 value)
   clang-3.7: error: no input files
   configure:3932: $? = 1
   configure:3921: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang -qversion >&5
   clang-3.7: error: unknown argument: '-qversion'
   clang-3.7: error: no input files
   configure:3932: $? = 1
   configure:3952: checking whether the C compiler works
   configure:3974: /bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/toolchain/bin/clang -O3 -I/bitcoin/depends/x86_64-apple-darwin14/native/include     -L/bitcoin/depends/x86_64-apple-darwin14/native/lib -Wl,-rpath=\$$ORIGIN/../lib     conftest.c  >&5
   /usr/bin/ld: cannot find crtbegin.o: No such file or directory
   /usr/bin/ld: cannot find -lgcc
   /usr/bin/ld: cannot find -lgcc_s
   clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
   configure:3978: $? = 1
   configure:4016: result: no
   configure: failed program was:
   | /* confdefs.h */
   | #define PACKAGE_NAME "cctools"
   | #define PACKAGE_TARNAME "cctools"
   | #define PACKAGE_VERSION "877.8"
   | #define PACKAGE_STRING "cctools 877.8"
   | #define PACKAGE_BUGREPORT "t.poechtrager@gmail.com"
   | #define PACKAGE_URL ""
   | /* end confdefs.h.  */
   | 
   | int
   | main ()
   | {
   | 
   |   ;
   |   return 0;
   | }
   configure:4021: error: in `/bitcoin/depends/work/build/x86_64-apple-darwin14/native_cctools/807d6fd1be5d2224872e381870c0a75387fe05e6-3e0a7ea9e07/cctools':
   configure:4023: error: C compiler cannot create executables
   See `config.log' for more details
   

   Cross-compiling with a debian:stretch-slim container works file, so my assumption is a change in Busters newer GCC (8.3.0) has broken our older Clang (3.7.1).

   A a similar issue appeared in Clang previously, which produced similar output, and was resolved in LLVM here.

2. fanquake added the label Build system on May 20, 2019
3. fanquake referenced this in commit 8bb298cfeb on May 20, 2019
4. 
   MarcoFalke commented at 11:00 AM on May 20, 2019: member

   Couldn't the clang version be bumped to be closer to a version that is installed natively on macos? That way the released binaries are closer to the binaries that were tested by developers that compile on native mac.

5. 
   theuni commented at 5:01 PM on May 20, 2019: member

   Couldn't the clang version be bumped to be closer to a version that is installed natively on macos? That way the released binaries are closer to the binaries that were tested by developers that compile on native mac.

   Yes. But in the process we should update cctools/ld64 as well as the SDK. In the past, we've tried to find combinations that were close to what Apple was supporting at the time. That avoids situations like new clang warnings from old SDK headers.

   Edit: To clarify, I think we should start by updating everything and see if that magically solves the problem. If not, go from there.

6. MarcoFalke added the label macOS on May 20, 2019
7. MarcoFalke added this to the milestone 0.19.0 on May 20, 2019
8. MarcoFalke cross-referenced this on May 20, 2019 from issue Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa
9. fanquake cross-referenced this on Jul 15, 2019 from issue build: macOS toolchain update by fanquake
10. fanquake removed this from the milestone 0.19.0 on Sep 11, 2019
11. fanquake added this to the milestone 0.20.0 on Sep 11, 2019
12. 
    fanquake commented at 6:11 AM on September 11, 2019: member

    Pushed to 0.20.0. We'll fix this early in that cycle.

13. 
    afk11 commented at 7:02 PM on January 30, 2020: contributor

    Hi, looks like this issue affects Qubes' Debian Buster images.

14. fanquake cross-referenced this on Feb 3, 2020 from issue Bump macOS SDK version to 10.13 for gitian builds by hebasto
15. laanwj closed this on Feb 5, 2020

    ---

16. bitcoin locked this on Feb 15, 2022

Contributors

fanquakeMarcoFalketheuniafk11

Milestone
0.20.0