Replies: 2 comments 3 replies
-
|
Issue lovell/sharp#4095 indicates that this is an issue in sharp v0.33.5 (which provides libvips v8.15.3) and that downgrading to v0.33.4 (libvips v8.15.2) resolves it. However, what remains unclear to me is that there were no changes in the C++ bindings between libvips v8.15.2 and v8.15.3: I also cannot spot any ABI/API incompatibilities in the pre-built libvips binaries introduced in this changeset: If we ignore the issues with Next.js' standalone(?) build, which seem to occur only on Linux, the main issue appears to be on macOS between sharp v0.33.4 and v0.33.5. Perhaps the root cause is due to the GitHub Actions runner being updated to macOS 12 (Monterey) in commit lovell/sharp@cc96c21 and lovell/sharp-libvips@f3aff14? I don't have access to a macOS device, so verifying this guess would be a bit tricky. |
Beta Was this translation helpful? Give feedback.
-
|
The GitHub Actions macOS 11 image provided clang 13 whereas the macOS 12 image provides clang 14, which I guess could explain this. Both sharp and libvips are compiled using the same |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, it would be very weird if that's the culprit. The only C++ symbol changes in the pre-built libvips binary on macOS between v8.15.2 and v8.15.3 are: Details$ llvm-nm -Cgj libvips-8.15.2-darwin-x64/lib/libvips-cpp.42.dylib > before.txt
$ llvm-nm -Cgj libvips-8.15.3-darwin-x64/lib/libvips-cpp.42.dylib > after.txt
$ git diff --no-index before.txt after.txt
[...]
@@ -1706,7 +1710,7 @@ std::__1::basic_ostream<char, std::__1::char_traits<char>>::~basic_ostream()
std::__1::basic_ostream<char, std::__1::char_traits<char>>::~basic_ostream()
std::__1::basic_ostream<char, std::__1::char_traits<char>>::~basic_ostream()
std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(bool)
-std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(float)
+std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(double)
std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(int)
std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(unsigned int)
std::__1::basic_ostream<char, std::__1::char_traits<char>>::operator<<(unsigned long)
@@ -1750,6 +1754,7 @@ std::__1::mutex::unlock()
std::__1::mutex::~mutex()
std::__1::locale::locale(std::__1::locale const&)
std::__1::locale::~locale()
+std::__1::thread::hardware_concurrency()
std::__1::thread::detach()
std::__1::thread::~thread()
std::__1::codecvt<char, char, __mbstate_t>::idThe C++ symbol changes in sharp seems also OK, though I'm not very sure about those node-addon-api changes. Details$ llvm-nm -Cgj sharp-v0.33.4-napi-v9-darwin-x64/build/Release/sharp-darwin-x64.node > before.txt
$ llvm-nm -Cgj sharp-v0.33.5-napi-v9-darwin-x64/build/Release/sharp-darwin-x64.node > after.txt
$ git diff --no-index before.txt after.txt
[...]
@@ -16,9 +17,9 @@ Napi::AsyncWorker::OnAsyncWorkExecute(napi_env__*, void*)
Napi::AsyncWorker::OnAsyncWorkComplete(napi_env__*, napi_status, void*)
Napi::details::CallbackData<Napi::Value (*)(Napi::CallbackInfo const&), Napi::Value>::Wrapper(napi_env__*, napi_callback_info__*)
Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>::Wrapper(napi_env__*, napi_callback_info__*)
-Napi::details::FinalizeData<char, std::__1::function<void (void*, char*)>, void>::Wrapper(napi_env__*, void*, void*)
-void Napi::details::default_finalizer<Napi::details::CallbackData<Napi::Value (*)(Napi::CallbackInfo const&), Napi::Value>>(napi_env__*, void*, void*)
-void Napi::details::default_finalizer<Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>>(napi_env__*, void*, void*)
+void Napi::details::PostFinalizerWrapper<&Napi::details::FinalizeData<char, std::__1::function<void (void*, char*)>, void>::Wrapper(napi_env__*, void*, void*)>(napi_env__*, void*, void*)
+void Napi::details::PostFinalizerWrapper<&void Napi::details::default_finalizer<Napi::details::CallbackData<Napi::Value (*)(Napi::CallbackInfo const&), Napi::Value>>(napi_env__*, void*, void*)>(napi_env__*, void*, void*)
+void Napi::details::PostFinalizerWrapper<&void Napi::details::default_finalizer<Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>>(napi_env__*, void*, void*)>(napi_env__*, void*, void*)
vips::to_vectorv(int, ...)
vips::VInterpolate::new_from_name(char const*, vips::VOption*)
vips::VImage::gaussnoise(int, int, vips::VOption*)
@@ -113,7 +114,7 @@ sharp::AssertImageTypeDimensions(vips::VImage, sharp::ImageType)
sharp::RemoveAnimationProperties(vips::VImage)
sharp::ImageTypeSupportsUnlimited(sharp::ImageType)
sharp::IsV(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)
-sharp::Blur(vips::VImage, double)
+sharp::Blur(vips::VImage, double, VipsPrecision, double)
sharp::IsDz(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)
sharp::Tint(vips::VImage, std::__1::vector<double, std::__1::allocator<double>>)
sharp::Trim(vips::VImage, std::__1::vector<double, std::__1::allocator<double>>, double, bool)
@@ -131,7 +132,7 @@ sharp::IsTiff(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1
sharp::IsWebp(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)
sharp::Linear(vips::VImage, std::__1::vector<double, std::__1::allocator<double>>, std::__1::vector<double, std::__1::allocator<double>>)
sharp::Negate(vips::VImage, bool)
-sharp::Recomb(vips::VImage, std::__1::unique_ptr<double [], std::__1::default_delete<double []>> const&)
+sharp::Recomb(vips::VImage, std::__1::vector<double, std::__1::allocator<double>> const&)
sharp::Boolean(vips::VImage, vips::VImage, VipsOperationBoolean)
sharp::Flatten(vips::VImage, std::__1::vector<double, std::__1::allocator<double>>)
sharp::HasAttr(Napi::Object, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>)
@@ -140,7 +141,7 @@ sharp::IsDzZip(std::__1::basic_string<char, std::__1::char_traits<char>, std::__
sharp::Sharpen(vips::VImage, double, double, double, double, double, double)
sharp::TrimEnd(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)
sharp::Bandbool(vips::VImage, VipsOperationBoolean)
-sharp::Convolve(vips::VImage, int, int, double, double, std::__1::unique_ptr<double [], std::__1::default_delete<double []>> const&)
+sharp::Convolve(vips::VImage, int, int, double, double, std::__1::vector<double, std::__1::allocator<double>> const&)
sharp::HasAlpha(vips::VImage)
sharp::Modulate(vips::VImage, double, double, int, double)
sharp::AttrAsStr(Napi::Object, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) |
Beta Was this translation helpful? Give feedback.
-
Ah, it looks like these symbol changes are due to nodejs/node-addon-api@40bcb09. It would be odd if that caused any issues. |
Beta Was this translation helpful? Give feedback.
-
|
Alternative approach for sharp taken via lovell/sharp-libvips#252 |
Beta Was this translation helpful? Give feedback.
-
The C++ shared library currently uses the same ABI version as the C shared library, namely 42 (60 - 18):
libvips/meson.build
Lines 27 to 28 in f801ed6
However C++ ABI compatibility is a bit of a minefield and my investigation into lovell/sharp#4095 suggests it could relate to a collision between two different versions of the libvips C++ library both with the
libvips-cpp.so.42soname.I had a look at what some other C++ shared libraries do to handle this.
Version 1.62.1 of gRPC uses the project version for the C++ library:
Version 1.14.10 of dbus uses its own, separately-incremented version number for the C++ library:
Something like the following might work along the lines of the gRPC approach, which seems the most sensible (i.e. lowest maintenance):
I guess there is a possible problem here in that
libvips-cpp.so.42might be consider to be more recent thanlibvips-cpp.so.8.16.0, so maybe we need to retain the C ABI version as a prefix too, e.g.libvips-cpp.so.42.8.16.0?Beta Was this translation helpful? Give feedback.
All reactions