GCC 4.8.5 for musl: tweak patch to match upstream #3969

fingolfin · 2021-11-29T14:05:18Z

The patch for using old GCC on musl defined INCLUDE_DEFAULTS_MUSL_LOCAL but
never used it in the definition of INCLUDE_DEFAULTS. Comparing the patch with
what is in mainline GCC these days suggest this patch. For reference, see:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/linux.h#L190

This is a first step towards addressing (parts of) issue #3949. Alas, since I only modify a .patch, nothing will actually be built -- which is good, as I am not sure how the correct way is to proceed with updating the RootFS / compiler shard. And in fact before doing that, it should be tested whether the patch even works as intended. So, baby steps:

Perform a test build and check if it has the correct default include paths
- I tried this via julia --color=yes --proj=../../.ci build_tarballs.jl --verbose --debug=end x86_64-linux-musl but I got ERROR: LoadError: KeyError: key "CMAKE_TARGET_TOOLCHAIN" not found
assuming this works... what next: modify 0_RootFS/GCCBootstrap@4/build_tarballs.jl in this PR to force a rebuild?
finally... "update the rootfs" ?!? clearly I have no clue what I am talking about, so I hope to get some help here. But let's first do step 1 :-)

fingolfin · 2021-11-29T14:06:41Z

More details about the error I got:

...
musl-1.1.19/tools/musl-gcc.specs.sh
musl-1.1.19/tools/version.sh
[ Info: Copying content of bundled in srcdir...
[ Info: Checking to see if /home/mhorn/Yggdrasil/0_RootFS/GCCBootstrap@4/build/x86_64-linux-musl/FULfIaMF/ is encrypted...
[ Info: Checking to see if /home/mhorn/.julia/packages/BinaryBuilderBase/Yzjww/deps/ is encrypted...
ERROR: LoadError: KeyError: key "CMAKE_TARGET_TOOLCHAIN" not found
Stacktrace:
 [1] getindex
   @ ./dict.jl:482 [inlined]
 [2] toolchain_file(bt::BinaryBuilderBase.Meson{:clang}, p::Platform, envs::Dict{String, String}; is_host::Bool)
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/Yzjww/src/BuildToolchains.jl:175
 [3] generate_toolchain_files!(platform::Platform, envs::Dict{String, String}; toolchains_path::String, host_platform::Platform)
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/Yzjww/src/BuildToolchains.jl:231
 [4] BinaryBuilderBase.UserNSRunner(workspace_root::String; cwd::String, workspaces::Vector{Pair{String, String}}, mappings::Vector{Pair}, platform::Platform, extra_env::Dict{String, String}, verbose::Bool, compiler_wrapper_path::String, toolchains_path::String, src_name::String, shards::Vector{CompilerShard}, kwargs::Base.Iterators.Pairs{Symbol, String, Tuple{Symbol}, NamedTuple{(:compiler_wrapper_dir,), Tuple{String}}})
   @ BinaryBuilderBase ~/.julia/packages/BinaryBuilderBase/Yzjww/src/UserNSRunner.jl:51
 [5] autobuild(dir::AbstractString, src_name::AbstractString, src_version::VersionNumber, sources::Vector{var"#s1251"} where var"#s1251"<:BinaryBuilderBase.AbstractSource, script::AbstractString, platforms::Vector{T} where T, products::Vector{var"#s947"} where var"#s947"<:Product, dependencies::Vector{var"#s946"} where var"#s946"<:BinaryBuilderBase.AbstractDependency; verbose::Bool, debug::Bool, skip_audit::Bool, ignore_audit_errors::Bool, autofix::Bool, code_dir::Union{Nothing, String}, require_license::Bool, kwargs::Any)
   @ BinaryBuilder ~/.julia/packages/BinaryBuilder/CuDaR/src/AutoBuild.jl:697
 [6] build_tarballs(ARGS::Any, src_name::Any, src_version::Any, sources::Any, script::Any, platforms::Any, products::Any, dependencies::Any; julia_compat::String, kwargs::Any)
   @ BinaryBuilder ~/.julia/packages/BinaryBuilder/CuDaR/src/AutoBuild.jl:283
 [7] build_and_upload_gcc(version::VersionNumber, ARGS::Vector{String})
   @ Main ~/Yggdrasil/0_RootFS/gcc_common.jl:809
 [8] build_and_upload_gcc(version::VersionNumber)
   @ Main ~/Yggdrasil/0_RootFS/gcc_common.jl:795
 [9] top-level scope
   @ ~/Yggdrasil/0_RootFS/GCCBootstrap@4/build_tarballs.jl:2
in expression starting at /home/mhorn/Yggdrasil/0_RootFS/GCCBootstrap@4/build_tarballs.jl:2

giordano · 2021-11-29T14:17:55Z

https://github.com/JuliaPackaging/BinaryBuilderBase.jl/blob/c213d27e79009bf6e2b242965484808604e07902/src/BuildToolchains.jl#L200 was changed recently in JuliaPackaging/BinaryBuilderBase.jl#181, but I think I used meson since then (and this is generated regardless of whether meson is used or not), so I'm not sure what's going on here, maybe an unexpected code path

fingolfin · 2021-11-30T23:25:54Z

Since I keep getting that error when trying to build it locally, I'll now try and see what happens if I try to build it on yggdrasil...

giordano · 2021-11-30T23:29:09Z

I'll now try and see what happens if I try to build it on yggdrasil...

We don't build anything under 0_RootFS here 😉

fingolfin · 2021-11-30T23:33:11Z

Damn. OK, so I how can I do this then? I was hoping that Yggdrasil is able to build it, then I'd download the resulting artifact as usual, and use that to check if the issue is resolved.

giordano · 2021-11-30T23:37:58Z

No, we build all the compiler shards locally and deploy them directly to releases in this repository. This process is completely disjointed from the rest of what we do here.

fingolfin · 2021-12-01T13:34:47Z

OK. But I just can't get it to build. How to proceed? Damn.

giordano · 2021-12-01T13:36:13Z

Try to understand what's wrong with the Meson toolchain file 🙂 As I said above, it has been changed very recently, it isn't impossible there was an error in an untested code path.

fingolfin · 2021-12-01T14:06:18Z

Yeah I think the line you pointed out,

    cmake_toolchain_file = '$(envs[is_host ? "CMAKE_HOST_TOOLCHAIN" : "CMAKE_TARGET_TOOLCHAIN"])'

is problematic because it assumes CMAKE_TARGET_TOOLCHAIN etc. are present. But those are set in platform_envs(), unless bootstrap=true

But I have no idea what the "correct" fix is... some options:

define CMAKE_TARGET_TOOLCHAIN also if bootstrap=true
- should this then affect other similar settings? e.g. why CMAKE_HOST_TOOLCHAIN or MESON_HOST_TOOLCHAIN or ...
make the code in toolchain_file check if CMAKE_TARGET_TOOLCHAIN is present; if not then ...
- don't emit the cmake_toolchain_file line
- emit it but with a default value
completely drop the cmake_toolchain_file line (I have no idea what it is for)
... something else

fingolfin · 2021-12-01T14:06:58Z

For now I removed the line setting cmake_toolchain_file which at least allowed the build process to start. We'll see.

giordano · 2021-12-02T18:39:21Z

Problem with the toolchain files should have been fixed by JuliaPackaging/BinaryBuilderBase.jl#185, which is now in v1.0.5

fingolfin · 2021-12-03T14:14:06Z

OK, now it works, and the patch seems to have the desired effect:

# $bindir/x86_64-linux-musl-gcc -v -E - < /dev/null
Using built-in specs.
COLLECT_GCC=/workspace/destdir/bin/x86_64-linux-musl-gcc
Target: x86_64-linux-musl
Configured with: /workspace/srcdir/gcc-4.8.5/configure --prefix=/workspace/destdir --target=x86_64-linux-musl --host=x86_64-linux-musl --build=x86_64-linux-musl --disable-multilib --disable-werror --enable-shared --enable-host-shared --enable-threads=posix --with-sysroot=/workspace/destdir/x86_64-linux-musl/sys-root --program-prefix=x86_64-linux-musl- --disable-bootstrap --with-arch=x86-64 --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --disable-symvers --enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.8.5 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 /workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/x86_64-linux-musl/4.8.5/cc1 -E -quiet -v -iprefix /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/ -isysroot /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root - -mtune=generic -march=x86-64
ignoring duplicate directory "/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/4.8.5/../../../../x86_64-linux-musl/include"
ignoring duplicate directory "/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/4.8.5/include"
#include "..." search starts here:
#include <...> search starts here:
 /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/../../../../x86_64-linux-musl/include
 /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/include
 /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/local/include
 /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/workspace/x86_64-linux-musl/destdir/x86_64-linux-musl/sys-root/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"
COMPILER_PATH=/workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/x86_64-linux-musl/4.8.5/:/workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/../../../../x86_64-linux-musl/bin/
LIBRARY_PATH=/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/../../../../x86_64-linux-musl/lib/../lib64/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/../../../../x86_64-linux-musl/lib/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/4.8.5/../../../:/workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/lib/:/workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

How to proceed from here?

giordano · 2021-12-03T15:21:25Z

That's awesome, thanks! We need to do the same also for GCC 5, can you check the patch applies cleanly also there? For GCC 5 the patch is a symlink to the GCC 4 one, so you don't have to edit anything if that applies cleanly.

How to proceed from here?

If this works, we can merge it and we can build and publish it, I'd just wait some time in case other needs arise, these are pretty large artifacts, I prefer not to build them too often or needlessly.

fingolfin · 2021-12-03T15:32:45Z

Actually, having thought about this some more (and knowing that clang may also need this in various combinations), perhaps we should use a completely different approach, and just patch clang_compile_flags! and gcc_compile_flags! to add the equivalent of -isystem $includedir. Then no shards have to be changed, and all compilers will work. Am I missing something?

giordano · 2021-12-03T15:38:32Z

Uhm, that'd probably work, even though I'm not sure -isystem is a better idea than -I, in the past I've had bad surprises with -isystem. However I'm a bit worried about superpicky build sytems which error on all possible warnings when ${includedir} is included twice, I've seen stuff like that in the past.

Side note, regarding the need to rebuild GCC for other stuff, I just discovered we're missing this symlink in the compiler shards for all Musl platforms:

Yggdrasil/0_RootFS/gcc_common.jl

Lines 701 to 702 in beb4ee8

    
                   # Fix broken symlink 
        
                   ln -fsv ../usr/lib/libc.so ${sysroot}/lib/ld-musl-$(musl_arch).so.1

fingolfin · 2021-12-04T02:04:54Z

Uhm, that'd probably work, even though I'm not sure -isystem is a better idea than -I,

The reason I suggested -isystem is because it would match the behavior of the "built-in" syroot path closest. In particular, include paths specified with -I later one take precedence over it; if -I was used it would take precedence, which can caused bad problems indeed.

Actually, the result would still not match 100% what the compiler does; to get that, one would have to use -nostdinc followed by four -isystem directives for the four standard dirs gcc/clang seems to use on most of our supported platforms.

in the past I've had bad surprises with -isystem.

Do you recall any details as to what kind of bad surprises those were?

However I'm a bit worried about superpicky build sytems which error on all possible warnings when ${includedir} is included twice, I've seen stuff like that in the past.

But the build system would not see this flag, it would not be in the CPPFLAGS after all.

Side note, regarding the need to rebuild GCC for other stuff, I just discovered we're missing this symlink in the compiler shards for all Musl platforms:

Yggdrasil/0_RootFS/gcc_common.jl

Lines 701 to 702 in beb4ee8

# Fix broken symlink

ln -fsv ../usr/lib/libc.so ${sysroot}/lib/ld-musl-$(musl_arch).so.1

The patch for using old GCC on musl defined INCLUDE_DEFAULTS_MUSL_LOCAL but never used it in the definition of INCLUDE_DEFAULTS. Comparing the patch with what is in mainline GCC these days suggest this patch. For reference, see: <https://github.com/gcc-mirror/gcc/blob/master/gcc/config/linux.h#L190>

fingolfin · 2021-12-07T22:52:44Z

I confirmed that GCC 5.2.0 also builds fine, and also has the desired behavior. To wit:

sandbox:${WORKSPACE}/srcdir/gcc_build # cd $bindir
sandbox:${WORKSPACE}/destdir/bin # ./x86_64-linux-musl-gcc --version
x86_64-linux-musl-gcc (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

sandbox:${WORKSPACE}/destdir/bin # ./x86_64-linux-musl-gcc -v -E - < /dev/null
Using built-in specs.
COLLECT_GCC=/workspace/destdir/bin/x86_64-linux-musl-gcc
Target: x86_64-linux-musl
Configured with: /workspace/srcdir/gcc-5.2.0/configure --prefix=/workspace/destdir --target=x86_64-linux-musl --host=x86_64-linux-musl --build=x86_64-linux-musl --disable-multilib --disable-werror --enable-shared --enable-host-shared --enable-threads=posix --with-sysroot=/workspace/destdir/x86_64-linux-musl/sys-root --program-prefix=x86_64-linux-musl- --disable-bootstrap --with-arch=x86-64 --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --disable-symvers --enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 /workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/x86_64-linux-musl/5.2.0/cc1 -E -quiet -v -iprefix /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/ -isysroot /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root - -mtune=generic -march=x86-64
ignoring duplicate directory "/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/5.2.0/../../../../x86_64-linux-musl/include"
ignoring duplicate directory "/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/../../lib/gcc/x86_64-linux-musl/5.2.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/../../../../x86_64-linux-musl/include
 /workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/include
 /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/local/include
 /workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/workspace/x86_64-linux-musl/destdir/x86_64-linux-musl/sys-root/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"
COMPILER_PATH=/workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/x86_64-linux-musl/5.2.0/:/workspace/x86_64-linux-musl/destdir/bin/../libexec/gcc/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/../../../../x86_64-linux-musl/bin/
LIBRARY_PATH=/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/../../../../x86_64-linux-musl/lib/../lib64/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/../../../../x86_64-linux-musl/lib/:/workspace/x86_64-linux-musl/destdir/bin/../lib/gcc/x86_64-linux-musl/5.2.0/../../../:/workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/lib/:/workspace/x86_64-linux-musl/destdir/bin/../x86_64-linux-musl/sys-root/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

giordano · 2021-12-08T00:24:13Z

Awesome, thanks! The idea of fixing this in BinaryBuilderBase.jl/src/Runner.jl still stands, like I did in JuliaPackaging/BinaryBuilderBase.jl#192: JuliaPackaging/BinaryBuilderBase.jl#188 has still to be properly fixed by creating the symlink in the GCC recipe here.

Do you recall any details as to what kind of bad surprises those were?

No, sorry. It was outside of BinaryBuilder, something completely unrelated. But I remember the compiler was picking up wrong headers because of -isystem happily used by CMake (:roll_eyes:) and the solution was to replace it with -I.

The patch for using old GCC on musl defined INCLUDE_DEFAULTS_MUSL_LOCAL but never used it in the definition of INCLUDE_DEFAULTS. Comparing the patch with what is in mainline GCC these days suggest this patch. For reference, see: <https://github.com/gcc-mirror/gcc/blob/9eec77c0df9e5c67454a2e8f83246104458ba4f0/gcc/config/linux.h#L190>

fingolfin mentioned this pull request Nov 29, 2021

Ensure all our C/C++ cross compiler search for headers in $includedir and libraries in $libdir #3949

Closed

giordano mentioned this pull request Nov 30, 2021

[BWA] Add builder for v0.7.17 #3980

Merged

giordano added the BinaryBuilder ⚙️ Issues and pull requested related to internals of BinaryBuilder label Dec 4, 2021

fingolfin force-pushed the mh/tweak-gcc-4.8.5-musl branch from 4e8d441 to c1d4022 Compare December 7, 2021 22:12

fingolfin marked this pull request as ready for review December 7, 2021 22:52

giordano merged commit 0c9f13e into JuliaPackaging:master Dec 8, 2021

fingolfin deleted the mh/tweak-gcc-4.8.5-musl branch December 10, 2021 07:49

fingolfin mentioned this pull request Mar 1, 2022

Add -isystem ${includedir} for clang on FreeBSD, and GCC on musl JuliaPackaging/BinaryBuilderBase.jl#226

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GCC 4.8.5 for musl: tweak patch to match upstream #3969

GCC 4.8.5 for musl: tweak patch to match upstream #3969

fingolfin commented Nov 29, 2021 •

edited

Loading

fingolfin commented Nov 29, 2021

giordano commented Nov 29, 2021

fingolfin commented Nov 30, 2021

giordano commented Nov 30, 2021

fingolfin commented Nov 30, 2021

giordano commented Nov 30, 2021

fingolfin commented Dec 1, 2021

giordano commented Dec 1, 2021

fingolfin commented Dec 1, 2021

fingolfin commented Dec 1, 2021

giordano commented Dec 2, 2021

fingolfin commented Dec 3, 2021

giordano commented Dec 3, 2021

fingolfin commented Dec 3, 2021

giordano commented Dec 3, 2021

fingolfin commented Dec 4, 2021

fingolfin commented Dec 7, 2021

giordano commented Dec 8, 2021

GCC 4.8.5 for musl: tweak patch to match upstream #3969

GCC 4.8.5 for musl: tweak patch to match upstream #3969

Conversation

fingolfin commented Nov 29, 2021 • edited Loading

fingolfin commented Nov 29, 2021

giordano commented Nov 29, 2021

fingolfin commented Nov 30, 2021

giordano commented Nov 30, 2021

fingolfin commented Nov 30, 2021

giordano commented Nov 30, 2021

fingolfin commented Dec 1, 2021

giordano commented Dec 1, 2021

fingolfin commented Dec 1, 2021

fingolfin commented Dec 1, 2021

giordano commented Dec 2, 2021

fingolfin commented Dec 3, 2021

giordano commented Dec 3, 2021

fingolfin commented Dec 3, 2021

giordano commented Dec 3, 2021

fingolfin commented Dec 4, 2021

fingolfin commented Dec 7, 2021

giordano commented Dec 8, 2021

fingolfin commented Nov 29, 2021 •

edited

Loading