search

Brooooooklyn / canvas

High performance skia binding to Node.js. Zero system dependencies and pure npm packages without any postinstall scripts nor node-gyp.
https://vercel.skia.rs
MIT License
1.75k stars 76 forks source link

Minimum macos version #896

Open Julusian opened 1 month ago

Julusian commented 1 month ago

Is there a specific target for minimum macos version of this library?

Chromium supports macos 10.15, but it appears that this library requires macos 12.

I have some users who are stuck on 10.15 or 11, which would be nice to support if possible. I am open to doing some digging to create a PR myself if this is something that would be accepted.

For reference, the error they are getting is:

Error: dlopen(/Applications/Companion.app/Contents/Resources/node_modules/@napi-rs/canvas-darwin-x64/skia.darwin-x64.node, 1): Symbol not found: __ZTTNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE
  Referenced from: /Applications/Companion.app/Contents/Resources/node_modules/@napi-rs/canvas-darwin-x64/skia.darwin-x64.node
  Expected in: /usr/lib/libc++.1.dylib
Julusian commented 4 weeks ago

I have been digging into this, and it looks like this project is correctly configuring the compiler to target 10.13, but for some reason it isn't doing it.

I've boiled a test case down to running inside skia/out/Static:

clang++ -MD -MF obj/src/sksl/libskia.SkSLString.o.d -DNDEBUG -DSK_CODEC_DECODES_BMP -DSK_CODEC_DECODES_WBMP -DSK_ENABLE_PRECOMPILE -DSK_ASSUME_GL=1 -DSK_DISABLE_TRACING -DSK_USE_PERFETTO -DSK_ENABLE_API_AVAILABLE -DSK_GAMMA_APPLY_TO_A8 -DSK_ENABLE_AVX512_OPTS -DSKIA_IMPLEMENTATION=1 -DSK_FONTMGR_FREETYPE_DIRECTORY_AVAILABLE -DSK_TYPEFACE_FACTORY_FREETYPE -DSK_FONTMGR_FREETYPE_EMPTY_AVAILABLE -DSK_TYPEFACE_FACTORY_CORETEXT -DSK_FONTMGR_CORETEXT_AVAILABLE -DSK_SUPPORT_PDF -DSK_CODEC_DECODES_JPEG -DSK_HAS_HEIF_LIBRARY -DSK_CODEC_DECODES_ICO -DSK_CODEC_DECODES_PNG -DSK_CODEC_DECODES_WEBP -DSK_HAS_WUFFS_LIBRARY -DSK_CODEC_DECODES_GIF -DSK_XML -I../.. -Wno-attributes -ffp-contract=off -fstrict-aliasing -fPIC -fvisibility=hidden -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk -target x86_64-apple-macos10.13 -O3 -mmacosx-version-min=10.13 -std=c++17 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -std=c++17 -fno-exceptions -DSK_FORCE_RASTER_PIPELINE_BLITTER -DSK_ENABLE_SVG -DSK_RELEASE -DSK_DISABLE_TRACING -DSK_ENCODE_WEBP -DSK_CODEC_DECODES_WEBP -DSK_ENCODE_PNG -DSK_CODEC_DECODES_PNG -DSK_ENCODE_JPEG -DSK_CODEC_DECODES_JPEG -DSK_HAS_HEIF_LIBRARY -DSK_SHAPER_HARFBUZZ_AVAILABLE -Wno-psabi -mmacosx-version-min=10.13 -c ../../src/sksl/SkSLString.cpp -o obj/src/sksl/libskia.SkSLString.o

and then grep __ZTTNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE obj/src/sksl/libskia.SkSLString.o to check if it references the offending symbols.

This command from GN looks to be correctly formed, with a few points references macos 10.13

Digging deeper, I found that whether these symbols are used depends on either https://github.com/llvm/llvm-project/blob/3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff/libcxx/include/__availability#L150-L161 or https://github.com/llvm/llvm-project/blob/3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff/libcxx/include/__availability#L283-L293. These links are to the latest 18.x of llvm, which is what homebrew installs The second one is doing the platform checks, but the first one is the case being hit.

That partially explains why the platform checks aren't taking effect. What I am now trying to figure out is where _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS is being defined, as that is causing these platform checks to be skipped. I am struggling to find where this is coming from, or how it is supposed to work

Julusian commented 4 weeks ago

OK, this is being defined by /opt/homebrew/Cellar/llvm/18.1.8/bin/../include/c++/v1/__config_site

The version provided by xcode at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/c++/v1/__config_site does not have this set, so will use the platform version logic.

So it looks like the solution will be to stop using llvm from brew, and to use the one provided by xcode, I am giving this a test