Project

General

Profile

Bug #1273

exiv2 0.25 fails to compile correctly on musl libc due to improper check of strerror_r return type

Added by A. Wilcox almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Robin Mills
Category:
build
Target version:
0.26
Start date:
20 Jan 2017
Due date:
% Done:

100%

Estimated time:
6.00 h

Description

Hello there,

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[2]: *** [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]: http://git.musl-libc.org/cgit/musl/tree/src/string/strerror_r.c

Files

exiv2-0.25-check-return-type-properly.patch (518 Bytes) exiv2-0.25-check-return-type-properly.patch A. Wilcox, 20 Jan 2017 23:12
exiv2-0.25-dont-overdefine-strerror_r.patch (497 Bytes) exiv2-0.25-dont-overdefine-strerror_r.patch A. Wilcox, 21 Jan 2017 00:13

Associated revisions

Revision 4699 (diff)
Added by Robin Mills almost 5 years ago

#1273 Thanks to A Wilcox for reporting this and providing the patch.

Revision 4700 (diff)
Added by Robin Mills almost 5 years ago

#1273 Fix for linking on FreeBSD

Revision 4701 (diff)
Added by Robin Mills almost 5 years ago

#1273 Correction to r4699

History

#1

Updated by A. Wilcox almost 5 years 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?

#2

Updated by A. Wilcox almost 5 years ago

I have confirmed that this patch in addition to the above attached solve all compilation errors for exiv2 against musl libc on x86_64, x86_32, and PowerPC.

#3

Updated by Robin Mills almost 5 years 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 h to 2.00 h

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 almost 5 years 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 almost 5 years 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 almost 5 years 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 almost 5 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 50 to 100
  • Estimated time changed from 2.00 h to 6.00 h

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.

Also available in: Atom PDF