Created attachment 465166 [details, diff]
Use fts-standalone on musl libc
libtool: link: gcc -O2 -ggdb -march=nocona -mtune=core2 -fno-omit-frame-pointer -mfpmath=sse -o .libs/zipcmp zipcmp.o ../lib/.libs/libzip.so -lz
zipcmp.o: In function `list_directory':
/var/tmp/portage/dev-libs/libzip-1.1.3/work/libzip-1.1.3/src/zipcmp.c:320: undefined reference to `fts_open'
/var/tmp/portage/dev-libs/libzip-1.1.3/work/libzip-1.1.3/src/zipcmp.c:328: undefined reference to `fts_read'
/var/tmp/portage/dev-libs/libzip-1.1.3/work/libzip-1.1.3/src/zipcmp.c:376: undefined reference to `fts_close'
/var/tmp/portage/dev-libs/libzip-1.1.3/work/libzip-1.1.3/src/zipcmp.c:366: undefined reference to `fts_close'
collect2: error: ld returned 1 exit status
Makefile:411: recipe for target 'zipcmp' failed
Attached is a patch that:
- adds sys-libs/fts-standalone to [R]DEPEND when elibc_musl
- adds simple check to configure.ac
- revbump to inherit autotools for 'eautoreconf'
Tested on musl and glibc (changes nothing on glibc, builds correctly on musl).
Any chance of sending upstream? They seem semi-alive.
I just tried checked out upstream version 1.2.0 on a musl system and it
built fine out of the box. I think that 1.1.3 should also work fine if
sys-libs/fts-standalone is NOT installed.
The point is that there are configure tests for fts but they only check
for presence of fts.h and not whether it is necessary to link to an
additional library. (This is not surprising since I don't think that
any other system has an external libfts.)
fts is only used in the directory comparison of zipcmp.
Well, there has been a recent release 1.2.0 that kde-apps/ark is now optionally depending on. So I've added your patch for the 1.2.0 version bump in git commit 9a609ec75673220be26e8ca4f8f7164cf3262aa2 and also sent my own ballon d'essai to their mailing list about their half-finished cmake support, we'll see how it goes.