mesonbuild
Add objfw dependency
The Windows check failures do seem to be relevant, I think they're related to the changing the order of the compilers, since it looks like before that the test skipped on windows.
The Windows check failures do seem to be relevant, I think they're related to the changing the order of the compilers, since it looks like before that the test skipped on windows.
That should be addressed now. It seems Meson expects MSVC-syntax from Clang on Windows, so it needs to be clang-cl instead.
[5/5] clang -o exe1 exe1.p/main.c.o -Wl,--as-needed -Wl,--no-undefined subprojects/cmTest/libcmTest.a FAILED: exe1 clang -o exe1 exe1.p/main.c.o -Wl,--as-needed -Wl,--no-undefined subprojects/cmTest/libcmTest.a /usr/bin/ld: subprojects/cmTest/libcmTest.a.p/cmTest.c.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: failed to set dynamic section sizes: bad value clang-15.0: error: linker command failed with exit code 1 (use -v to see invocation)This looks related. The OpenSUSE runner is building C with
ccand ObjC with clang, then linking with clang. For some reason it doesn't like that but the reason it doesn't like it is because of PIE??
That does look to me like a very OpenSUSE-specific error where they probably force them flags on the linker. I'm guessing this is yet another case of "No proper separation between compilers / languages in Meson", so I'm not sure what to do about it.
Could we install objfw on:
* macOS CI via brew install in the GitHub actions yaml * fedora via ci/ciimages/ in the list of packagesThe latter will only start testing once the PR is merged and the images are rebuilt. The skip will function until then (we can check that it passes in Fedora since some image builders might fail, but the Fedora image builder should show objfw running successfully and should be building fine right now).
Added a commit.
Could we install objfw on:
* macOS CI via brew install in the GitHub actions yaml * fedora via ci/ciimages/ in the list of packagesThe latter will only start testing once the PR is merged and the images are rebuilt. The skip will function until then (we can check that it passes in Fedora since some image builders might fail, but the Fedora image builder should show objfw running successfully and should be building fine right now).
I looked into this and this is a distribution bug: OpenSUSE uses incompatible default flags for GCC and Clang: Their GCC defaults to not using PIE while their clang does. This leaves 2 options:
1.) Ignore the failure as a distribution bug (which it is!) 2.) Let Meson decide whether to use PIE or not and not the distribution, so that it can then consistently compile with PIE / no PIE irregardless of the defaults.
You can easily reproduce this yourself by creating a file called test.c with:
#include <stdio.h>
int main() { puts("Hello world!"); return 0; }
And then compiling like this:
gcc -c test.c
clang test.o
Which will fail. However, this works:
gcc -fPIE -c test.c
clang test.o
As does this:
gcc -c test.c
clang -Wl,-no-pie test.c
In any case, this problem exists irregardless of this PR, it just makes it more visible.
Seems like we should skip your test on opensuse
It's not even my test that's failing, it's the existing test cases/cmake/24 mixing languages that fails because now Clang is preferred for ObjC (because GCC's ObjC support is close to being useless).
We should get you to rebase on https://github.com/mesonbuild/meson/pull/13133 when it is merged that way the Fedora image builder will succeed. Also, it sounds like if you rebase on master, the Gentoo one will succeed too?
This is good to go pending whether or not we want to wait my PR to merge to rebase on so the Fedora image builder job succeeds.
The problem is that this PR doesn't break things, but it's things already being broken, and every time I rebase, something else has been broken.
I guess then that this means this can never get merged because CI is always broken.
I restarted failed jobs, sadly there is some flakiness in some tests. :(
But for example #13148 has all green CI (except for the lint one which is an actual failure) and that is only one day old.
I'm just waiting for the full CI results to come in...
As I pointed out a couple times in the past already -- the development policy is that the CI must be green in order to merge the PR, but "CI image builder" jobs are exempt. You don't need to worry about them, you don't need to rebase to try fixing it, and when I'm ready to merge this PR I will manually check that all required CI jobs pass and that all failures are "just" image builder failures.
At the moment we are fine and this is on track to be merged as long as there are no additional failures. All three red jobs are image builder jobs.
Ok, interesting.
3 hours ago, this passed: https://github.com/mesonbuild/meson/actions/runs/8852155560/job/24310221953
Now it fails in this PR:
[1/15] clang -Ilibalib.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libalib.dylib.p/libfoo.m.o -MF libalib.dylib.p/libfoo.m.o.d -o libalib.dylib.p/libfoo.m.o -c '../test cases/osx/7 bitcode/libfoo.m'
[2/15] clang++ -Ilibblib.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libblib.dylib.p/libbar.mm.o -MF libblib.dylib.p/libbar.mm.o.d -o libblib.dylib.p/libbar.mm.o -c '../test cases/osx/7 bitcode/libbar.mm'
[3/15] clang++ -Ilibbmodule.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libbmodule.dylib.p/libbar.mm.o -MF libbmodule.dylib.p/libbar.mm.o.d -o libbmodule.dylib.p/libbar.mm.o -c '../test cases/osx/7 bitcode/libbar.mm'
[4/15] clang -Ilibamodule.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libamodule.dylib.p/libfoo.m.o -MF libamodule.dylib.p/libfoo.m.o.d -o libamodule.dylib.p/libfoo.m.o -c '../test cases/osx/7 bitcode/libfoo.m'
[5/15] cc -Ilibclib.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libclib.dylib.p/libfile.c.o -MF libclib.dylib.p/libfile.c.o.d -o libclib.dylib.p/libfile.c.o -c '../test cases/osx/7 bitcode/libfile.c'
[6/15] rm -f libalib.a && llvm-ar csrD libalib.a libalib.dylib.p/libfoo.m.o
[7/15] cc -Ilibcmodule.dylib.p -I. '-I../test cases/osx/7 bitcode' -I/opt/homebrew/include -fdiagnostics-color=always -fembed-bitcode -Wall -Winvalid-pch -O0 -g -MD -MQ libcmodule.dylib.p/libfile.c.o -MF libcmodule.dylib.p/libfile.c.o.d -o libcmodule.dylib.p/libfile.c.o -c '../test cases/osx/7 bitcode/libfile.c'
[8/15] rm -f libblib.a && llvm-ar csrD libblib.a libblib.dylib.p/libbar.mm.o
[9/15] clang -o libalib.dylib libalib.dylib.p/libfoo.m.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-bitcode_bundle -shared -install_name @rpath/libalib.dylib
FAILED: libalib.dylib
clang -o libalib.dylib libalib.dylib.p/libfoo.m.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-bitcode_bundle -shared -install_name @rpath/libalib.dylib
ld: -mllvm and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[10/15] clang++ -o libblib.dylib libblib.dylib.p/libbar.mm.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-bitcode_bundle -shared -install_name @rpath/libblib.dylib
FAILED: libblib.dylib
clang++ -o libblib.dylib libblib.dylib.p/libbar.mm.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-bitcode_bundle -shared -install_name @rpath/libblib.dylib
ld: -mllvm and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
[11/15] clang -o libamodule.dylib libamodule.dylib.p/libfoo.m.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-dead_strip_dylibs -bundle -Wl,-undefined,dynamic_lookup
[12/15] cc -o libclib.dylib libclib.dylib.p/libfile.c.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-bitcode_bundle -shared -install_name @rpath/libclib.dylib
[13/15] clang++ -o libbmodule.dylib libbmodule.dylib.p/libbar.mm.o -L/opt/homebrew/lib -I/opt/homebrew/include -Wl,-dead_strip_dylibs -bundle -Wl,-undefined,dynamic_lookup
ninja: build stopped: subcommand failed.
It's mixing cc for *.c files and clang for *.m files.
ld: -mllvm and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together
We are definitely using the latter. The former not, but maybe that is a mistaken diagnosis from using different toolchains? Linking bitcode bundles together is hardly likely to work without a consistent toolchain.
The key insight is here:
C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.0.40.1)")
C linker for the host machine: cc ld64 1015.7
Objective-C compiler for the host machine: clang (clang 18.1.4)
Objective-C linker for the host machine: clang ld64 1015.7
Objective-C++ compiler for the host machine: clang++ (clang 18.1.4)
Objective-C++ linker for the host machine: clang++ ld64 1015.7
We are trying to use clang in preference to gcc, but what we ended up doing is using clang in preference to the system AppleClang.
That's exactly what I mean. This error only came up after rebasing. Every time I rebase to incorporate one fix for CI, it also incorporates something that breaks another test on CI.
Everything but image builders seems to be back to green now -> I'm not rebasing it anymore