Add objfw dependency #13067

Midar · 2024-04-10T23:48:07Z

No description provided.

test cases/objc/5 objfw/meson.build

mesonbuild/dependencies/misc.py

dcbaker · 2024-04-18T16:28:51Z

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.

Midar · 2024-04-21T19:59:20Z

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.

tristan957 · 2024-04-22T14:23:49Z

This needs documentation

Midar · 2024-04-22T19:49:20Z

This needs documentation

Done.

dcbaker

Just a few small nits, otherwise this looks good to me to land

mesonbuild/dependencies/misc.py

dcbaker · 2024-04-22T21:25:49Z

test cases/objc/6 objfw with modules/meson.build

+endif
+
+executable('SimpleTest', 'SimpleTest.m',
+  dependencies: [objfw_dep])


Please merge the new 5 and 6 tests into a single test. Meson startup overhead is the longest pull in CI, and so we've moved to have fewer, but more complex tests rather than many simple ones.

ObjFWTest is very new it looks like, which means that it's very likely for people with the framework installed to not have this and end up with the whole test being skipped.

Is it possible to use a different module that has been around for longer to do the test that modules: works?

@dcbaker Done.
@eli-schwartz Unfortunately, ObjFWTest is the first module ObjFW ships with. All others are 3rd party.

eli-schwartz

[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 cc and 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??

docs/markdown/Dependencies.md

eli-schwartz · 2024-04-22T21:35:26Z

test cases/objc/6 objfw with modules/meson.build

+endif
+
+executable('SimpleTest', 'SimpleTest.m',
+  dependencies: [objfw_dep])


ObjFWTest is very new it looks like, which means that it's very likely for people with the framework installed to not have this and end up with the whole test being skipped.

Is it possible to use a different module that has been around for longer to do the test that modules: works?

eli-schwartz

Could we install objfw on:

macOS CI via brew install in the GitHub actions yaml
fedora via ci/ciimages/ in the list of packages

The 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).

Midar · 2024-04-22T21:46:41Z

[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 cc and 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.

Midar · 2024-04-22T21:49:30Z

Could we install objfw on:
* macOS CI via brew install in the GitHub actions yaml

* fedora via ci/ciimages/ in the list of packages
The 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.

dcbaker

All of my concerns have been addressed, so when @eli-schwartz is happy with this it can be merged

Midar · 2024-04-23T20:18:23Z

Could we install objfw on:
* macOS CI via brew install in the GitHub actions yaml

* fedora via ci/ciimages/ in the list of packages
The 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.

tristan957 · 2024-04-23T21:14:59Z

Seems like we should skip your test on opensuse

Midar · 2024-04-23T21:17:35Z

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).

Midar · 2024-04-23T22:44:02Z

Worked around this by always enabling PIE in the test.

tristan957 · 2024-04-23T22:46:36Z

We should get you to rebase on #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?

Midar · 2024-04-23T22:48:34Z

Rebased on master for now

tristan957 · 2024-04-24T00:07:39Z

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.

Midar · 2024-04-26T20:45:14Z

Rebased for the 3rd time now - what's missing to get this merged?

jpakkane · 2024-04-26T21:12:47Z

Our development rules prohibit merging MRs that break CI.

Midar · 2024-04-26T21:14:47Z

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.

jpakkane · 2024-04-26T21:22:02Z

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.

eli-schwartz · 2024-04-26T21:23:35Z

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.

eli-schwartz · 2024-04-26T21:40:58Z

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.

Midar · 2024-04-27T02:00:48Z

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.

GCC only has very limited support for Objective-C and doesn't support any of the modern features, so whenever Clang is available, it should be used instead. Essentially, the only reason to ever use GCC for Objective-C is that Clang simply does not support the target system.

This uses objfw-config to get to the flags, however, there's still several todos that can only be addressed once dependencies can have per-language flags.

OBJC=clang / OBJCXX=clang++ can pick up a newer Clang that no longer supports bitcode.

Midar · 2024-04-28T07:09:22Z

Everything but image builders seems to be back to green now -> I'm not rebasing it anymore

eli-schwartz · 2024-04-28T07:14:45Z

Thanks for persevering. :)

Midar requested review from dcbaker and jpakkane as code owners April 10, 2024 23:48

Midar force-pushed the objfw branch from 4e3a077 to 7727311 Compare April 11, 2024 00:20

tristan957 reviewed Apr 11, 2024

View reviewed changes

test cases/objc/5 objfw/meson.build Outdated Show resolved Hide resolved

dcbaker reviewed Apr 11, 2024

View reviewed changes

mesonbuild/dependencies/misc.py Outdated Show resolved Hide resolved

dcbaker added the dependencies label Apr 11, 2024

Midar force-pushed the objfw branch 2 times, most recently from 8a7dec1 to 46e553f Compare April 12, 2024 22:13

dcbaker approved these changes Apr 14, 2024

View reviewed changes

Midar force-pushed the objfw branch 4 times, most recently from dfb23dc to ed3ba44 Compare April 21, 2024 08:21

Midar force-pushed the objfw branch 2 times, most recently from f7ef5f8 to 4e0cfb3 Compare April 22, 2024 19:41

dcbaker requested changes Apr 22, 2024

View reviewed changes

Midar force-pushed the objfw branch from 4e0cfb3 to cbf3e4b Compare April 22, 2024 21:35

eli-schwartz reviewed Apr 22, 2024

View reviewed changes

Midar force-pushed the objfw branch from cbf3e4b to d2adfa7 Compare April 22, 2024 21:39

eli-schwartz requested changes Apr 22, 2024

View reviewed changes

dcbaker approved these changes Apr 22, 2024

View reviewed changes

Midar force-pushed the objfw branch 5 times, most recently from cf72dd8 to bdb74f6 Compare April 23, 2024 22:43

Midar force-pushed the objfw branch from bdb74f6 to 38a8e89 Compare April 23, 2024 22:48

Midar force-pushed the objfw branch 2 times, most recently from 89f79d0 to 355b4b5 Compare April 26, 2024 20:44

Midar added 3 commits April 27, 2024 20:50

Add support for depending on ObjFW

b13cb68

This uses objfw-config to get to the flags, however, there's still several todos that can only be addressed once dependencies can have per-language flags.

Install ObjFW on macOS, Fedora and MSYS2 CI

47ad3fd

Midar force-pushed the objfw branch 2 times, most recently from 91b0e85 to e1afd17 Compare April 27, 2024 22:55

Explicitly set OBJC=cc OBJCXX=c++ for bitcode test

0752a74

OBJC=clang / OBJCXX=clang++ can pick up a newer Clang that no longer supports bitcode.

Midar force-pushed the objfw branch from e1afd17 to 0752a74 Compare April 27, 2024 23:20

eli-schwartz merged commit e9363e1 into mesonbuild:master Apr 28, 2024
39 of 43 checks passed

Midar deleted the objfw branch April 28, 2024 07:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add objfw dependency #13067

Add objfw dependency #13067

Midar commented Apr 10, 2024

dcbaker commented Apr 18, 2024

Midar commented Apr 21, 2024

tristan957 commented Apr 22, 2024

Midar commented Apr 22, 2024

dcbaker left a comment

dcbaker Apr 22, 2024

eli-schwartz Apr 22, 2024

Midar Apr 22, 2024

eli-schwartz left a comment

eli-schwartz Apr 22, 2024

eli-schwartz left a comment

Midar commented Apr 22, 2024

Midar commented Apr 22, 2024

dcbaker left a comment

Midar commented Apr 23, 2024

tristan957 commented Apr 23, 2024

Midar commented Apr 23, 2024

Midar commented Apr 23, 2024

tristan957 commented Apr 23, 2024

Midar commented Apr 23, 2024

tristan957 commented Apr 24, 2024

Midar commented Apr 26, 2024

jpakkane commented Apr 26, 2024

Midar commented Apr 26, 2024

jpakkane commented Apr 26, 2024

eli-schwartz commented Apr 26, 2024

eli-schwartz commented Apr 26, 2024 •

edited

Loading

Midar commented Apr 27, 2024

Midar commented Apr 28, 2024

eli-schwartz commented Apr 28, 2024

Add objfw dependency #13067

Add objfw dependency #13067

Conversation

Midar commented Apr 10, 2024

dcbaker commented Apr 18, 2024

Midar commented Apr 21, 2024

tristan957 commented Apr 22, 2024

Midar commented Apr 22, 2024

dcbaker left a comment

Choose a reason for hiding this comment

dcbaker Apr 22, 2024

Choose a reason for hiding this comment

eli-schwartz Apr 22, 2024

Choose a reason for hiding this comment

Midar Apr 22, 2024

Choose a reason for hiding this comment

eli-schwartz left a comment

Choose a reason for hiding this comment

eli-schwartz Apr 22, 2024

Choose a reason for hiding this comment

eli-schwartz left a comment

Choose a reason for hiding this comment

Midar commented Apr 22, 2024

Midar commented Apr 22, 2024

dcbaker left a comment

Choose a reason for hiding this comment

Midar commented Apr 23, 2024

tristan957 commented Apr 23, 2024

Midar commented Apr 23, 2024

Midar commented Apr 23, 2024

tristan957 commented Apr 23, 2024

Midar commented Apr 23, 2024

tristan957 commented Apr 24, 2024

Midar commented Apr 26, 2024

jpakkane commented Apr 26, 2024

Midar commented Apr 26, 2024

jpakkane commented Apr 26, 2024

eli-schwartz commented Apr 26, 2024

eli-schwartz commented Apr 26, 2024 • edited Loading

Midar commented Apr 27, 2024

Midar commented Apr 28, 2024

eli-schwartz commented Apr 28, 2024

eli-schwartz commented Apr 26, 2024 •

edited

Loading