The USE="ACL" flag is disabled on OS X, but building app-arch/libarchive-3.2.1-r2 then fails with: libtool: compile: /opt/gentoo/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1 -I/opt/gentoo/usr/include -arch x86_64 -march=core-avx-i -fcolor-diagnostics -O3 -pipe -Wno-implicit-function-declaration -mmacosx-version-min=10.11 -Wall -Wformat -Wformat-security -c /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_set_standard_lookup.c -fno-common -DPIC -o libarchive/.libs/archive_write_disk_set_standard_lookup.o /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3490:2: error: use of undeclared identifier 'acl_t' acl_t acl, dfacl = NULL; ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3493:2: error: use of undeclared identifier 'acl' acl = acl_get_fd(tmpfd); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3493:8: warning: implicit declaration of function 'acl_get_fd' is invalid in C99 [-Wimplicit-function-declaration] acl = acl_get_fd(tmpfd); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3494:6: error: use of undeclared identifier 'acl' if (acl == NULL) { ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3503:2: error: use of undeclared identifier 'dfacl' dfacl = acl_dup(acl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3503:10: warning: implicit declaration of function 'acl_dup' is invalid in C99 [-Wimplicit-function-declaration] dfacl = acl_dup(acl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3503:18: error: use of undeclared identifier 'acl' dfacl = acl_dup(acl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3504:10: warning: implicit declaration of function 'acl_set_fd' is invalid in C99 [-Wimplicit-function-declaration] acl_r = acl_set_fd(dffd, dfacl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3504:27: error: use of undeclared identifier 'dfacl' acl_r = acl_set_fd(dffd, dfacl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3512:6: error: use of undeclared identifier 'acl' if (acl) ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3513:3: warning: implicit declaration of function 'acl_free' is invalid in C99 [-Wimplicit-function-declaration] acl_free(acl); ^ /opt/gentoo/bin/bash ./libtool --tag=CC --mode=compile /opt/gentoo/usr/bin/clang -DHAVE_CONFIG_H -I. -I/Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1 -I/opt/gentoo/usr/include -arch x86_64 -march=core-avx-i -fcolor-diagnostics -O3 -pipe -Wno-implicit-function-declaration -mmacosx-version-min=10.11 -Wall -Wformat -Wformat-security -c -o libarchive/archive_write_open_fd.lo /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_open_fd.c /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3513:12: error: use of undeclared identifier 'acl' acl_free(acl); ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3514:6: error: use of undeclared identifier 'dfacl' if (dfacl) ^ /Volumes/Scratch/tmp/portage/app-arch/libarchive-3.2.1-r2/work/libarchive-3.2.1/libarchive/archive_write_disk_posix.c:3515:12: error: use of undeclared identifier 'dfacl' acl_free(dfacl); ^ 4 warnings and 10 errors generated. make[1]: *** [Makefile:5488: libarchive/archive_write_disk_posix.lo] Error 1 ... because <sys/acl.h> has not been included. It would appear that this particular source file is either missing an #ifdef to remove ACL support, or should not be being built at all. emerge --info Portage 2.2.28-prefix (python 2.7.11-final-0, prefix/darwin/macos/10.11/x64, gcc-4.2.1, unavailable, 15.5.0 x86_64) ================================================================= System uname: Darwin-15.5.0-x86_64-i386-64bit Timestamp of repository gentoo_prefix: Sun, 03 Jul 2016 13:57:51 +0000 sh bash 4.3_p42-r1 app-shells/bash: 4.3_p42-r1::gentoo_prefix dev-lang/perl: 5.24.0-r1::gentoo_prefix dev-lang/python: 2.7.11-r2::gentoo_prefix dev-util/cmake: 3.5.2-r1::gentoo_prefix dev-util/pkgconfig: 0.29.1::gentoo_prefix sys-devel/autoconf: 2.69::gentoo_prefix sys-devel/automake: 1.14.1::gentoo_prefix, 1.15::gentoo_prefix sys-devel/gcc-config: 1.8-r1::gentoo_prefix sys-devel/libtool: 2.4.6-r1::gentoo_prefix sys-devel/make: 4.2.1::gentoo_prefix Repositories: gentoo_prefix location: /opt/gentoo/var/db/repo/gentoo sync-type: rsync sync-uri: rsync://rsync.prefix.bitzolder.nl/gentoo-portage-prefix priority: -1000 aliases: gentoo CBUILD="x86_64-apple-darwin15" CC="/opt/gentoo/usr/bin/clang" CFLAGS="-arch x86_64 -march=core-avx-i -fcolor-diagnostics -O3 -pipe -Wno-implicit-function-declaration -mmacosx-version-min=10.11" CHOST="x86_64-apple-darwin15" CXX="/opt/gentoo/usr/bin/clang++" CXXFLAGS=" -arch x86_64 -march=core-avx-i -fcolor-diagnostics -O3 -pipe -Wno-implicit-function-declaration -mmacosx-version-min=10.11" LC_ALL="C" LDFLAGS="-Wl,-dead_strip_dylibs" MAKEOPTS="-j7"
I've already fixed this, didn't I?
Recently or some time back? ;) I'm pretty sure I updated my repo this morning - but I'll double check once the lz4 test-suite has completed...
Looks like https://github.com/libarchive/libarchive/issues/730 might be to blame. Can you confirm whether cherry-picking https://github.com/libarchive/libarchive/commit/3e66829717c8fde611b2b611497f08a46da40ce7.patch to your /etc/portage/patches fixes this issue? (see https://wiki.gentoo.org/wiki//etc/portage/patches)
That patch might work, if it does, I'll put it instead of my ebuild tweak.
(In reply to Fabian Groffen from comment #4) > That patch might work, if it does, I'll put it instead of my ebuild tweak. If it does, I'll revbump to -r3 :) Please check it out and let me know.
(In reply to Stuart Shelton from comment #2) > Recently or some time back? ;) > > I'm pretty sure I updated my repo this morning - but I'll double check once > the lz4 test-suite has completed... I fixed the wrong ebuild :( (In reply to NP-Hardass from comment #5) > (In reply to Fabian Groffen from comment #4) > > That patch might work, if it does, I'll put it instead of my ebuild tweak. > > If it does, I'll revbump to -r3 :) Please check it out and let me know. I also need elibtoolize for Solaris, can I revbump to -r3 myself?
Created attachment 439722 [details, diff] libarchive-3.2.1-r3.patch (In reply to Fabian Groffen from comment #6) > (In reply to Stuart Shelton from comment #2) > > Recently or some time back? ;) > > > > I'm pretty sure I updated my repo this morning - but I'll double check once > > the lz4 test-suite has completed... > > I fixed the wrong ebuild :( > > > (In reply to NP-Hardass from comment #5) > > (In reply to Fabian Groffen from comment #4) > > > That patch might work, if it does, I'll put it instead of my ebuild tweak. > > > > If it does, I'll revbump to -r3 :) Please check it out and let me know. > > I also need elibtoolize for Solaris, can I revbump to -r3 myself? If this looks fine to you, sure, feel free to revbump using that and tack on an ACK/sign-off from me. If not, I'd prefer that you post a patch/diff to have looked over first.
This is what you need for Solaris. --- a/app-arch/libarchive/libarchive-3.2.1-r2.ebuild +++ b/app-arch/libarchive/libarchive-3.2.1-r2.ebuild @@ -3,7 +3,7 @@ # $Id$ EAPI=6 -inherit autotools eutils multilib-minimal toolchain-funcs +inherit autotools eutils multilib-minimal toolchain-funcs libtool DESCRIPTION="BSD tar command" HOMEPAGE="http://www.libarchive.org/" @@ -38,6 +38,11 @@ DEPEND="${RDEPEND} PATCHES=( "${FILESDIR}/${P}-fix-tests-gnu99.patch" ) +src_prepare() { + default + elibtoolize # for Solaris sol2_ld linker fix +} + multilib_src_configure() { export ac_cv_header_ext2fs_ext2_fs_h=$(usex e2fsprogs) #354923
(In reply to Fabian Groffen from comment #8) > This is what you need for Solaris. > > --- a/app-arch/libarchive/libarchive-3.2.1-r2.ebuild > +++ b/app-arch/libarchive/libarchive-3.2.1-r2.ebuild > @@ -3,7 +3,7 @@ > # $Id$ > > EAPI=6 > -inherit autotools eutils multilib-minimal toolchain-funcs > +inherit autotools eutils multilib-minimal toolchain-funcs libtool > > DESCRIPTION="BSD tar command" > HOMEPAGE="http://www.libarchive.org/" > @@ -38,6 +38,11 @@ DEPEND="${RDEPEND} > > PATCHES=( "${FILESDIR}/${P}-fix-tests-gnu99.patch" ) > > +src_prepare() { > + default > + elibtoolize # for Solaris sol2_ld linker fix > +} > + > multilib_src_configure() { > export ac_cv_header_ext2fs_ext2_fs_h=$(usex e2fsprogs) #354923 eautoreconf calls elibtoolize, so I think that would be a little more versatile, particularly if a user needs to patch the build system (or we add a patch that patches the build system in the future). I presume that satisfies your need for Solaris? The -r3 I posted does that plus cherry picked the upstream OSX ACL patch (still waiting on your confirmation that that patch resolves the build issue)
Yes the patch fixes the problem. I don't want the autoconf dependency, neither wait for it. It's a matter of taste, but elibtoolize was created for exactly this reason. I don't buy your user argument, it means you'd want eapply_user to take care of it automagically, in which case elibtoolize would do the right thing (nothing, because eautoreconf leaves the .elibtoolized marker). Either way, it's not a big deal, as long as it's in, it works.
(In reply to Fabian Groffen from comment #10) > Yes the patch fixes the problem. > > I don't want the autoconf dependency, neither wait for it. It's a matter of > taste, but elibtoolize was created for exactly this reason. > > I don't buy your user argument, it means you'd want eapply_user to take care > of it automagically, in which case elibtoolize would do the right thing > (nothing, because eautoreconf leaves the .elibtoolized marker). > > Either way, it's not a big deal, as long as it's in, it works. I figured since we had patches in 3.1.2 which required eautoreconf, there was no harm in keeping the autotools dep. I just would rather avoid removing and readding it with relative frequency. I have no problem dropping it, so long as we don't end up having to readd it 1 patch down the line.
Fix is in -r3. Went with eautoreconf over raw elibtoolize (turns out I need eautoreconf for another patch anyway, so worked out)