exiv2 0.25 fails to compile correctly on musl libc due to improper check of strerror_r return type
|Status:||Closed||Start date:||20 Jan 2017|
|Assignee:||Robin Mills||% Done:|
|Category:||build||Estimated time:||6.00 hours|
While packaging exiv2 for our musl libc-based distribution, Adélie Linux, I noticed the exiv2 package failed to compile:
/usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp: In function ‘std::__cxx11::string Exiv2::strError()’: /usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp:340:25: error: invalid conversion from ‘int’ to ‘char*’ [-fpermissive] buf = strerror_r(error, buf2, n); ^ src/CMakeFiles/exiv2lib.dir/build.make:782: recipe for target 'src/CMakeFiles/exiv2lib.dir/futils.cpp.o' failed make: *** [src/CMakeFiles/exiv2lib.dir/futils.cpp.o] Error 1
This is because musl implements an XSI-conformant strerror_r1. Changing the check from CHECK_C_SOURCE_COMPILES to CHECK_CXX_SOURCE_COMPILES - without changing any other part of the check - causes the check to fail correctly on musl (and allow compilation with int-type strerror_r). I applied this to the source on a glibc test machine and the check passed correctly there, allowing compilation with char*-type strerror_r. So this is a partial re-introduction of changeset #2041 but without the drastic change in the test.
#1 Updated by A. Wilcox about 1 year ago
I should note that additionally on some builders, but not others, I've just seen a similar yet not identical build failure:
/usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp:54:56: error: ambiguating new declaration of ‘char* strerror_r(int, char*, size_t)’ extern char *strerror_r(int errnum, char *buf, size_t n); ^ In file included from /usr/lib/gcc/powerpc-foxkit-linux-musl/5.4.0/include/g++-v5/cstring:42:0, from /usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp:49: /usr/include/string.h:64:5: note: old declaration ‘int strerror_r(int, char*, size_t)’ int strerror_r (int, char *, size_t); ^ /usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp: In function ‘std::__cxx11::string Exiv2::strError()’: /usr/src/media-gfx/exiv2-0.25-r2/work/exiv2-0.25/src/futils.cpp:340:25: error: invalid conversion from ‘int’ to ‘char*’ [-fpermissive] buf = strerror_r(error, buf2, n); ^ src/CMakeFiles/exiv2lib.dir/build.make:782: recipe for target 'src/CMakeFiles/exiv2lib.dir/futils.cpp.o' failed
This appears to be because include/exiv2/config.h forcibly defines this for all Linux machines, due to some failure involving GCC 4.8. This is definitely not correct.. Would you be amenable to adding an "&& defined(GLIBC)" to that check?
#3 Updated by Robin Mills about 1 year ago
- Status changed from New to Assigned
- Target version set to 0.26
- % Done changed from 80 to 50
- Estimated time changed from 1.00 to 2.00
Thank you for reporting this and providing a patch. I returned from vacation yesterday and will review/submit your patch on Tuesday.
It's been a few years since I've had to service the strerror_r hackery. If you're confident that your fix is good on Adélie Linux, our buildserver will validate your patch on Fedora/Ubuntu/Cygwin/MinGW/Mac (Intel 64 and PPC 32) and MSVC (2005,8,10,12,13,15).
#4 Updated by A. Wilcox about 1 year ago
I have already pushed the packages live to the alpha2 repos for Adélie; additionally, I have tested the patch on Galapagos Linux (a minimal fork of Gentoo based on glibc), and my personal Mac running OS X 10.11.3. If there are any build failures on the other platforms, I will be happy to revise the patch.
As an aside, I notice the BSD family is curiously missing from your build farm. Is there a particular reason? I can toss this at my FreeBSD 10 SPARC box if you want.
#5 Updated by Robin Mills about 1 year ago
Your patch seems fine to me. It's 1am in England and I'm awake with jet-lag after a 28 hour flight home from New Zealand. I don't want to start messing with code tonight.
Ah, that's an interesting offer to build on your Sparc. You know how it is with open-source, everything grows in response to requests and contributions. If I can access your Sparc with SSH, I could get our build server to run builds on your machine.
#6 Updated by Robin Mills about 1 year ago
Fix submitted. r4699. Thanks to A Wilcox for reporting this and providing the patch.
I've installed FreeBSD on a virtual machine on the build server (a Mac Mini). I haven't succeed yet in building on FreeBSD for two reasons:
1) cmake compiles and fails to link "cannot find -ldl"
(I know why and I'll submit a fix for this)
2) make config; ./configure is generating errors
I haven't investigated yet. However I will and submit a fix.
I would be useful to build on the big endian Sparc. My 2004 PowerBook G4 is really old and I only power it up occasionally to build/test on Big Endian.
#7 Updated by Robin Mills about 1 year ago
- Status changed from Assigned to Closed
- % Done changed from 50 to 100
- Estimated time changed from 2.00 to 6.00
I've updated src/CMakeLists.txt to provide support for building exiv2 on FreeBSD. However it requires -DEXIV2_ENABLE_NLS=OFF as gettext and libintl is not installed by default on FreeBSD. Additionally, the autotools (./configure) build fails to generate valid makefiles. Debugging this is complicated because I'm running FreeBSD on a virtual machine under Parallels on a Mac. This environment does not appear to be able to install Parallels Tools and consequently Gnome is almost un-usable. All-in-all, working with FreeBSD has been a misery.
As nobody else has requested support for FreeBSD, I don't intend to spend more time on this. If A Wilcox wishes to work on this and provide patches, I will be happy to review, test and commit them. When we have FreeBSD building effortlessly (both CMake and ./configure) I will seriously consider adding FreeBSD to the nightly build when development begins on v0.27.
I appreciate this matter being reported and patched by A Wilcox. We are in the final stages before shipping v0.26 and the original issue concerning strerror_r has been resolved and therefore this issue is being closed. If A Wilcox would like to contribute to the effort to support FreeBSD, please open a new issue with the title "Build Support for FreeBSD" and assign the target version as 0.27.