lb90

IMO the error is triggered only when the output is [ConPTY](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/)

There's an upstream report at https://github.com/gnustep/libobjc2/issues/351 Not sure if we should build with `OLDABI_COMPAT=ON` or not: https://github.com/gnustep/libobjc2?tab=readme-ov-file#gnustep-objective-c-runtime

To work around the issue you can compile with `-fobjc-runtime=gnustep-2.0`. We should make this the [default](https://github.com/llvm/llvm-project/blob/7dd9b3d81450b29bf2cddb8270081f61080bddc0/clang/lib/Driver/ToolChains/Clang.cpp#L8062) in CLang

It works in a `CLANG64` environment. By adding `-Wl,-verbose` we can see what's happening under the hood: In a CLANG64 environment: ``` CLANG64> clang -Wl,-verbose -Wno-objc-root-class -fobjc-runtime=gnustep-2.0 -o test-objc test-objc.m...

Relevant output from `lld` in verbose mode: ``` ld.lld: Reading D:/msys64/tmp/test-objc-249854.o ld.lld: Directives: D:/msys64/tmp/test-objc-249854.o: -exclude-symbols:".objcv2_load_function" -exclude-symbols:".objc_sel_name_alloc" -exclude-symbols:".objc_sel_types_@16@0:8" -exclude-symbols:".objc_selector_alloc_@16@0:8" -exclude-symbols:".objc_sel_name_dealloc" -exclude-symbols:".objc_sel_types_v16@0:8" -exclude-symbols:".objc_selector_dealloc_v16@0:8" -exclude-symbols:".objc_sel_name_init" -exclude-symbols:".objc_selector_init_@16@0:8" -exclude-symbols:"__start_.objcrt$SEL" -exclude-symbols:"__stop.objcrt$SEL" -exclude-symbols:"__start_.objcrt$CLS" -exclude-symbols:"__stop.objcrt$CLS" -exclude-symbols:"__start_.objcrt$CLR" -exclude-symbols:"__stop.objcrt$CLR" -exclude-symbols:"__start_.objcrt$CAT"...

Ah, indeed! Lemme check...

@mati865 yeah, I confirm that `ld` is correctly reading every `-exclude-symbols:...` directive embedded in the `.o` file: https://github.com/bminor/binutils-gdb/blob/2006dea18d5a8e149ee60d5548e8b3d848e46c4c/ld/pe-dll.c#L772. However that seems to have no practical effect in the end, as...

Hello @Doublonmousse! The underlying issue is https://gitlab.freedesktop.org/cairo/cairo/-/issues/886. DWrite support for Cairo was imported from Firefox, which presumably used Cairo from a single thread only, so it uses the single-threaded D2D1...

> Can the DWrite backend be deactivated through an environment variable in the meantime ? Looks like `piet` uses `PangoCairo`, so you might set the environment variable `PANGOCAIRO_BACKEND=fc`, where "fc"...

@striezel yes, that would help but there are other things which are not thread safe. I should open a final MR next week ;)