libarchive @3.3.1: error: use of undeclared identifier 'ACL_SYNCHRONIZE'

[Gord-Butler]

Upgraded Macports to 2.4.1 and attempted to upgrade ports. libarchive failed at the build stage. I'm including logs from the first two attempts to upgrade plus terminal output after cleaning the port and attempting the second time. Running Macports on a MacBook Pro with OSX 10.9.

[Gord-Butler]

First build attempt

[Gord-Butler]

second build attempt

[Gord-Butler]

terminal output from second attempt

[ryandesign (Ryan Carsten Schmidt)]

The error seems to be:

:info:build libarchive/archive_read_disk_entry_from_file.c:677:34: error: use of undeclared identifier 'ACL_SYNCHRONIZE'
:info:build         {ARCHIVE_ENTRY_ACL_SYNCHRONIZE, ACL_SYNCHRONIZE}
:info:build                                         ^
:info:build libarchive/archive_read_disk_entry_from_file.c:1371:31: error: invalid application of 'sizeof' to an incomplete type 'const struct <anonymous struct at libarchive/archive_read_disk_entry_from_file.c:638:14> []'
:info:build                 for (i = 0; i < (int)(sizeof(acl_perm_map) / sizeof(acl_perm_map[0])); ++i) {
:info:build                                             ^~~~~~~~~~~~~~
:info:build 2 errors generated.

[keybounce]

CC me, I'm having this same issue.

It's worse -- this is needed to build cmake. So guess what this did to my "sudo port upgrade outdated" :-)

... Actually, didn't there used to be a "CC me" button in the bug report section here?

EDIT: Never mind, found it.

[ballapete (Peter "Pete" Dyballa)]

On Mac OS X 10.6.8, Snow Leopard, it is:

libtool: compile:  /usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I/opt/local/include -I/opt/local/include/libxml2 -pipe -Os -arch x86_64 -Wall -Wformat -Wformat-security -MT libarchive/archive_read.lo -MD -MP -MF libarchive/.deps/archive_read.Tpo -c libarchive/archive_read.c -o libarchive/archive_read.o >/dev/null 2>&1
libarchive/archive_read_disk_entry_from_file.c:677: error: ‘ACL_SYNCHRONIZE’ undeclared here (not in a function)
libarchive/archive_read_disk_entry_from_file.c: In function ‘translate_guid’:
libarchive/archive_read_disk_entry_from_file.c:757: warning: implicit declaration of function ‘getpwuuid’
libarchive/archive_read_disk_entry_from_file.c:757: warning: assignment makes pointer from integer without a cast
libarchive/archive_read_disk_entry_from_file.c:767: warning: implicit declaration of function ‘getgruuid’
libarchive/archive_read_disk_entry_from_file.c:767: warning: assignment makes pointer from integer without a cast
make[1]: *** [libarchive/archive_read_disk_entry_from_file.lo] Error 1

[maxkalashnikov-macports (Max Kalashnikov)]

Same problem on Mountain Lion (10.8)

[maxkalashnikov-macports (Max Kalashnikov)]

Looks like this is a problem fixed in upstream with ​https://github.com/libarchive/libarchive/commit/d9036ca49e414c6b5560c48126b6963204a6eda9 and ​https://github.com/libarchive/libarchive/commit/60f0931d3b97e00616d7122321e34116d926bcc5, but there doesn't appear to be a release incorporating them yet.

[Hasan-Tata (Hasan Tata)]

Is there any way to patch manually last commit of GitHub sources and install it?

[tobypeterson]

Of course it could be patched, but I don't have a convenient way to test on ancient OS releases. Hopefully upstream will release an update soon.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53724.

Toby, if it's alright with you, I can try to apply those two upstream commits and test on older OSes, and commit to the port if successful.

[devernay (Frédéric Devernay)]

note that even with the fixes above, it doesn't compile on SL, because of missing getpwuuid and getgruuid functions (referenced by function translate_guid() ​https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_disk_entry_from_file.c#L872 )

[MrB74]

​https://github.com/libarchive/libarchive/issues/882 is open but does that cover this issue? Can we just go back to 3.3.0 or whatever was before this until this is reverted? Or for 10.8/9 use that version and for 10.10/10.11 use 3.3.1? Thanks

[maxkalashnikov-macports (Max Kalashnikov)]

3.2.2_1 seems to work fine at least on ML, with all installable versions of clang/llvm.

I could also give it a try on a PPC Leopard box, if that would be helpful, though that would be quite slow.

[ryandesign (Ryan Carsten Schmidt)]

We know that 3.2.2_1 built fine on PowerPC Leopard as well by looking at the ​available packages.

[Hasan-Tata (Hasan Tata)]

I have edited libarchive port file by changing its version to 3.2.2 like following.

sudo port edit libarchive

Then it works fine on OSX Lion 10.7 now.

[maxkalashnikov-macports (Max Kalashnikov)]

Sorry, I know libarchive itself is fine on ppc Leop. I meant I could see if modern clangs (or other dependents) compile ok against it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to maxkalashnikov-macports:

Sorry, I know libarchive itself is fine on ppc Leop. I meant I could see if modern clangs (or other dependents) compile ok against it.

Why do we care about that? What would that show?

The goal is to have a working libarchive for 10.9 and earlier. Going back to 3.2.2_1 for 10.9 and earlier would solve that for now.

[Hasan-Tata (Hasan Tata)]

Actually, I had been building ffmpeg universal full library and it depends on cmake. But it was being failed because of libarchive ARC issues on my OSX Lion. And now after I fixed libarchive version to 3.2.2 in its port file and then not only cmake but also ffmpeg successfully built now.

[maxkalashnikov-macports (Max Kalashnikov)]

Replying to ryandesign:

Replying to maxkalashnikov-macports:

Sorry, I know libarchive itself is fine on ppc Leop. I meant I could see if modern clangs (or other dependents) compile ok against it.

Why do we care about that? What would that show?

I'm not asserting that anyone cares about it. I certainly don't.

The goal is to have a working libarchive for 10.9 and earlier. Going back to 3.2.2_1 for 10.9 and earlier would solve that for now.

I was merely offering to help confirm that libarchive of that version is, indeed, working (for a use case I'm otherwise familiar with on a newer OS/cpu) on a particularly old platform, since I happen to have an idle one available.

[reeskm (Rees Machtemes)]

Confirmed this on PPC Leopard 10.5.8 while trying a "upgrade outdated" today. Log attached.

[reeskm (Rees Machtemes)]

Fail on Leopard PPC

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53773.

[dliessi (Davide Liessi)]

Replying to devernay:

note that even with the fixes above, it doesn't compile on SL, because of missing getpwuuid and getgruuid functions (referenced by function translate_guid() ​https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_disk_entry_from_file.c#L872 )

​Apparently solved?

The list of commits relevant to this ticket seems to be:

• ​https://github.com/libarchive/libarchive/commit/d9036ca49e414c6b5560c48126b6963204a6eda9
• ​https://github.com/libarchive/libarchive/commit/60f0931d3b97e00616d7122321e34116d926bcc5
• ​https://github.com/libarchive/libarchive/commit/4c3cda21663fa3dc42147c771a3b96b85e631c53
• ​https://github.com/libarchive/libarchive/commit/1a1be097da6c042a83fff26bdce361101bb869c8
• ​https://github.com/libarchive/libarchive/commit/71d26ad1b8e9f47f20abb4005a3d5c25ea83e4ab

[emrecio]

uname -a: Darwin emacbook500 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

info:build libarchive/archive_read_disk_entry_from_file.c:677: error: <E2><80><98>ACL_SYNCHRONIZE<E2><80><99> undeclared here (not in a function)
:info:build libarchive/archive_read_disk_entry_from_file.c: In function <E2><80><98>translate_guid<E2><80><99>:
:info:build libarchive/archive_read_disk_entry_from_file.c:757: warning: implicit declaration of function <E2><80><98>
getpwuuid<E2><80><99>
:info:build libarchive/archive_read_disk_entry_from_file.c:757: warning: assignment makes pointer from integer without a cast
:info:build libarchive/archive_read_disk_entry_from_file.c:767: warning: implicit declaration of function <E2><80><98>getgruuid<E2><80><99>
:info:build libarchive/archive_read_disk_entry_from_file.c:767: warning: assignment makes pointer from integer without a cast
:info:build make[1]: *** [libarchive/archive_read_disk_entry_from_file.lo] Error 1

[michaelld (Michael Dickens)]

I just attached a file containing a set of patches that fix all of the libarchive issues for me on 10.7 (libstdc++) and 10.12. I revert release back to 3.2.2, and add a devel version that's at the current GIT master, for those folks wanting the cutting edge. Minimal patching, really. I'd value testing / verification for those who know how to do it.

[dliessi (Davide Liessi)]

Replying to michaelld:

I revert release back to 3.2.2, and add a devel version that's at the current GIT master, for those folks wanting the cutting edge.

Shouldn't you increase the epoch, when decreasing the version number?

Minimal patching, really. I'd value testing / verification for those who know how to do it.

If it is just a matter of applying the diff and trying to install libarchive, I can try.

[michaelld (Michael Dickens)]

Increase epoch: yes. Missed that, thx for the pointer. We can add that in the final commit.

Just apply the diff, do a "selfupdate", then give it a try. Either the release or devel port should work & meet CMake's requirements.

[mf2k (Frank Schima)]

Has duplicate #53808.

[dliessi (Davide Liessi)]

The build was successful, but the checksums are wrong. I found these:

checksums           rmd160  3fedae2b71685d3003e71acd4189c5f3de80a2db \
                    sha256  691c194ee132d1f0f7a42541f091db811bc2e56f7107e9121be2bc8c04f1060f

I got also this:

Executing:  cd "/Volumes/MacPorts/hopeful/build/_opt_macports-git_macports-ports_archivers_libarchive/libarchive/work/libarchive-3.2.2" && /usr/bin/patch -p0 < '/opt/macports-git/macports-ports/archivers/libarchive/files/patch-libarchive__archive_read_support_format_lha.c.diff'
patching file libarchive/archive_read_support_format_lha.c
Hunk #1 succeeded at 1713 with fuzz 2 (offset -3 lines).

Also this warning during the destroot phase:

libtool: warning: remember to run 'libtool --finish /opt/local/lib'

What do you mean by "meet CMake's requirements"? Should I rebuild cmake?

[michaelld (Michael Dickens)]

Ah; forgot. After applying the patch & doing selfupdate, one needs to do:

sudo port clean --all libarchive*

then, the checksums should be valid. Otherwise, the build will work using the old archive.

The warnings in patch & build are normal; nothing to worry about.

The CMake Portfile is patched to allow for both libarchive and libarchive-devel. No need to rebuild in on your part.

Can you also try libarchive-devel?

sudo port -f deac libarchive
sudo port install libarchive-devel

If that works, you can revert back to libarchive release:

sudo port -f deac libarchive-devel
sudo port act libarchive

Thx!

[dliessi (Davide Liessi)]

Replying to michaelld:

Ah; forgot. After applying the patch & doing selfupdate, one needs to do:

sudo port clean --all libarchive*

then, the checksums should be valid. Otherwise, the build will work using the old archive.

This sounds undesirable, especially if you increase the epoch (or revision) so that everybody will need to rebuild libarchive. Maybe you should use the stealth update recipe.

Can you also try libarchive-devel?

It built without errors. (I didn't test it, nor I inspected the log file, though.)

[michaelld (Michael Dickens)]

OK; yeah. Doing a stealth update like change is the right way to go. Good point.

[michaelld (Michael Dickens)]

OK. New patch file with the updates discussed above (e.g., no need to "clean --all"). Works nicely for me.

[devernay (Frédéric Devernay)]

Yes, everything should be fixed upstream, but we're waiting for 3.3.2 that will incorporate these patches.

Replying to dliessi:

Replying to devernay:

note that even with the fixes above, it doesn't compile on SL, because of missing getpwuuid and getgruuid functions (referenced by function translate_guid() ​https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_disk_entry_from_file.c#L872 )

​Apparently solved?

The list of commits relevant to this ticket seems to be:

• ​https://github.com/libarchive/libarchive/commit/d9036ca49e414c6b5560c48126b6963204a6eda9
• ​https://github.com/libarchive/libarchive/commit/60f0931d3b97e00616d7122321e34116d926bcc5
• ​https://github.com/libarchive/libarchive/commit/4c3cda21663fa3dc42147c771a3b96b85e631c53
• ​https://github.com/libarchive/libarchive/commit/1a1be097da6c042a83fff26bdce361101bb869c8
• ​https://github.com/libarchive/libarchive/commit/71d26ad1b8e9f47f20abb4005a3d5c25ea83e4ab

[michaelld (Michael Dickens)]

Any idea when 3.3.2 will be out? libarchive is currently dysfunctional for some macOS users. This patch fixes that issue, allowing for the prior release or the latest dev version. Seems like a good way to get folks' MacPorts installs back to functional while we wait ...

[tobypeterson]

I'd rather not revert, since this does work fine on current macOS releases. If 3.3.2 or whatever isn't imminent, we should cherry pick whatever changes are needed. I don't have an easy way to test on these old OS builds so someone else would have to do that.

[dliessi (Davide Liessi)]

Replying to tobypeterson:

I'd rather not revert, since this does work fine on current macOS releases. If 3.3.2 or whatever isn't imminent, we should cherry pick whatever changes are needed.

I do agree.

I don't have an easy way to test on these old OS builds so someone else would have to do that.

I can try to apply the commits I pointed out in comment:36 and check if it builds but I wouldn't know how to test if it works as expected. I cannot promise, but I may try later today.

[dliessi (Davide Liessi)]

Replying to dliessi:

I can try to apply the commits I pointed out in comment:36 and check if it builds but I wouldn't know how to test if it works as expected. I cannot promise, but I may try later today.

I tried to prepare a patch containing the commits in comment:36 based on version 3.3.1, but I get too many conflicts when cherry-picking the commits. Since I know nothing of what the code does, I'm not going to fix the conflicts.

Anyway, instead of downgrading the port for everyone, maybe we could upgrade to current master (or at least to commit ​71d26ad1b8e9f47f20abb4005a3d5c25ea83e4ab) only users of the affected platforms.

[michaelld (Michael Dickens)]

OK folks. I've attached a patchfile that just fixes libarchive by patching it to bring it up to the current GIT master. This patch works for me on 10.7 (libstdc++) and 10.12. It does not add libarchive-devel; it leaves the version at 3.3.1, but bumps the revision to 1 such that all installs will move to this new version, whether working before or not. I've added in a section that should be self-obvious to delete when 3.3.2 comes out.

[thetrial (alabay)]

Well, maybe I’m absolutely too dumb … but I haven’t found out how to patch :-( Which file exactly? I thought, Macport would patch automatically … no. So I tried manually … but lost the trace where to point that patch. Maybe a hint or a step-by-step? Thanx.

[1-61803]

Replying to michaelld:

This patch works for me on 10.7 (libstdc++) and 10.12.

Since someone mentioned that current OSs don't have problems with libarchive, what didn't work for you on 10.12 exactly?

[ballapete (Peter "Pete" Dyballa)]

Replying to thetrial:

Well, maybe I’m absolutely too dumb … but I haven’t found out how to patch :-( Which file exactly? I thought, Macport would patch automatically … no.

Right, it does not patch automatically. Patching has to be programmed into the Portfile ('port file libarchive'). And the patch file supplied by Michael has bugs. It contains at its beginning a patch of Portfile

diff --git libarchive/Portfile libarchive/Portfile
index 3678221b87..0c1f098326 100644
--- libarchive/Portfile
+++ libarchive/Portfile
@@ -25,9 +25,27 @@ depends_lib      port:bzip2 port:zlib port:libxml2 port:xz \
 
 patchfiles       patch-libarchive__archive_read_support_format_lha.c.diff
 
+####
+# the following section is to be removed when 3.3.2 is released. it is
+# a temporary fix for older Mac OS X versions, and is already upstream.
+
+revision         1
+
+patchfiles-append \
+                 patch-3.3.1_to_master.diff \
+                 patch-Makefile.am.diff
+
+depends_build    port:autoconf port:automake port:libtool
+
+post-patch {
+    system -W ${worksrcpath} "build/autogen.sh"
+}
+
+####
+
 configure.args   --enable-bsdtar=shared --enable-bsdcpio=shared \
                  --disable-silent-rules --without-nettle \
-                 --without-openssl --without-lzmadec
+                 --without-openssl
 
 livecheck.type  regex
 livecheck.regex libarchive-(\[0-9.\]+)\\.tar.gz

which has to be removed and applied separately to Portfile. Then his patch file needs to be split to match the names patch-3.3.1_to_master.diff and patch-Makefile.am.diff. These files belong into the files sub-directory in the directory where the Portfile resides. The second patch file is just this block at the end:

diff --git libarchive/files/patch-Makefile.am.diff libarchive/files/patch-Makefile.am.diff
new file mode 100644
index 0000000000..05e51c0eb0
--- /dev/null
+++ libarchive/files/patch-Makefile.am.diff
@@ -0,0 +1,11 @@
+--- Makefile.am.orig
++++ Makefile.am
+@@ -23,7 +23,7 @@
+ DISTCHECK_CONFIGURE_FLAGS = --enable-bsdtar --enable-bsdcpio
+ # The next line is commented out by default in shipping libarchive releases.
+ # It is uncommented by default in trunk.
+-DEV_CFLAGS=-Werror -Wextra -Wunused -Wshadow -Wmissing-prototypes -Wcast-qual -g
++# DEV_CFLAGS=-Werror -Wextra -Wunused -Wshadow -Wmissing-prototypes -Wcast-qual -g
+ AM_CFLAGS=$(DEV_CFLAGS)
+ PLATFORMCPPFLAGS = @PLATFORMCPPFLAGS@
+ AM_CPPFLAGS=$(PLATFORMCPPFLAGS)

Before you start splitting the patches file you need to correct the paths it uses by substituting all occurrences of [ab]/archivers/ with .

Anyway, on my Snow Leopard Power Book with Mac OS X 10.6.8 libarchive @3.3.1 does not build because of:

libtool: compile:  /usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I/opt/local/include -I/opt/local/include/libxml2 -pipe -Os -arch x86_64 -Wall -Wformat -Wformat-security -MT libarchive/archive_read_data_into_fd.lo -MD -MP -MF libarchive/.deps/archive_read_data_into_fd.Tpo -c libarchive/archive_read_data_into_fd.c -o libarchive/archive_read_data_into_fd.o >/dev/null 2>&1
libarchive/archive_read_disk_entry_from_file.c:677: error: ‘ACL_SYNCHRONIZE’ undeclared here (not in a function)
libarchive/archive_read_disk_entry_from_file.c: In function ‘translate_guid’:
libarchive/archive_read_disk_entry_from_file.c:757: warning: implicit declaration of function ‘getpwuuid’
libarchive/archive_read_disk_entry_from_file.c:757: warning: assignment makes pointer from integer without a cast
libarchive/archive_read_disk_entry_from_file.c:767: warning: implicit declaration of function ‘getgruuid’
libarchive/archive_read_disk_entry_from_file.c:767: warning: assignment makes pointer from integer without a cast
make[1]: *** [libarchive/archive_read_disk_entry_from_file.lo] Error 1

[ballapete (Peter "Pete" Dyballa)]

Seems I have to write the substitution rule a bit more precisely…

All occurrences of SPACE[ab]/archivers/ become just SPACE. And SPACE is just a single SPACE CHARACTER at U+0020.

I should better attach the corrected particles!

[thetrial (alabay)]

No chance, I don’t get it built. Neither with these files untouched, nor with a substitution. OSX 10.7. Went back to 3.2.2.

[dliessi (Davide Liessi)]

Replying to ballapete:

Right, it does not patch automatically. Patching has to be programmed into the Portfile ('port file libarchive'). And the patch file supplied by Michael has bugs.

This is not true: the patch provided by Michael is not a patch file to be applied by the Portfile, but is a patch to be applied manually to the ports tree in order to obtain the working Portfile and patches.

It can be applied with git apply filename to the root of the ports tree. Then after doing a portindex you can port upgrade libarchive.

It applies cleanly for me (except for warnings about whitespace, which can be ignored) and builds without errors.

[michaelld (Michael Dickens)]

Thanks, dliessi (Davide Liessi), for clarifying about the patch and how to use it. I just assumed folks know.

The reasons to patch all installs are that (1) it's a little easier; and (2) it keeps them all with the same code, which is easier to track down issues for. Thus, if at all possible, 10.5-10.8 using libstdc++ (or libc++ via the way to install it on older systems) should build and install from the same codebase as 10.9-10.12 using libc++. Not all code can do this (e.g., GLFW, which deprecated 10.6 a while back, but still supports 10.7 and newer (for now); in this case, we assign the latest commit that supports the older OS and stop updating for the older OSs in the hope that that code is good enough as a dependency. I'd always greatly prefer to not go this route, but sometimes you just have to. In the case for libarchive, a single patch should take care of the issue for all MacOS X / macOS installs, luckily.

[tehcog (tehcog)]

log

[tehcog (tehcog)]

Replying to dliessi:

It can be applied with git apply filename to the root of the ports tree. Then after doing a portindex you can port upgrade libarchive.

It applies cleanly for me (except for warnings about whitespace, which can be ignored) and builds without errors.

I tried this (mavericks), but I think I may have mucked things up a bit. This issue may be related to another outstanding issue. Any help to resolve this would be appreciated. Please see the attached log file.

Mar 18 14:54:38 NerdCenter === Update MacPorts
Mar 18 14:54:38 NerdCenter --->  Updating MacPorts base sources using rsync
Mar 18 14:54:42 NerdCenter MacPorts base version 2.4.1 installed,
Mar 18 14:54:42 NerdCenter MacPorts base version 2.4.1 downloaded.
Mar 18 14:54:42 NerdCenter --->  MacPorts base is already the latest version
Mar 18 14:54:43 NerdCenter === Update Portfiles
Mar 18 14:54:43 NerdCenter --->  Updating the ports tree
Mar 18 14:54:48 NerdCenter
Mar 18 14:54:48 NerdCenter === List Outdated Ports
Mar 18 14:54:49 NerdCenter dcmtk                          @3.6.1_20161102_0+png+ssl+tiff+xml
Mar 18 14:54:49 NerdCenter libarchive                     @3.2.2_1
Mar 18 14:54:49 NerdCenter
Mar 18 14:54:49 NerdCenter === Clean Outdated Ports
Mar 18 14:54:49 NerdCenter --->  Cleaning dcmtk
Mar 18 14:54:49 NerdCenter --->  Cleaning libarchive
Mar 18 14:54:49 NerdCenter
Mar 18 14:54:49 NerdCenter === Fetch Outdated Ports
Mar 18 14:54:50 NerdCenter --->  Fetching distfiles for dcmtk
Mar 18 14:54:50 NerdCenter --->  Fetching distfiles for libarchive
Mar 18 14:54:50 NerdCenter
Mar 18 14:54:50 NerdCenter === Upgrade Outdated Ports (port -p upgrade --enforce-variants outdated)
Mar 18 14:54:52 NerdCenter --->  Computing dependencies for libarchive
Mar 18 14:54:52 NerdCenter --->  Fetching archive for libarchive
Mar 18 14:54:52 NerdCenter --->  Attempting to fetch libarchive-3.3.1_0.darwin_13.x86_64.tbz2 from https://packages.macports.org/libarchive
Mar 18 14:54:53 NerdCenter --->  Attempting to fetch libarchive-3.3.1_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/libarchive
Mar 18 14:54:53 NerdCenter --->  Attempting to fetch libarchive-3.3.1_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libarchive
Mar 18 14:54:54 NerdCenter --->  Verifying checksums for libarchive
Mar 18 14:54:54 NerdCenter --->  Extracting libarchive
Mar 18 14:54:54 NerdCenter --->  Applying patches to libarchive
Mar 18 14:54:54 NerdCenter --->  Configuring libarchive
Mar 18 14:55:18 NerdCenter --->  Building libarchive
Mar 18 14:55:20 NerdCenter Error: Failed to build libarchive: command execution failed
Mar 18 14:55:20 NerdCenter Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_libarchive/libarchive/main.log for details.

}}}

[tehcog (tehcog)]

Replying to tehcog:

Replying to dliessi: This issue may be related to another outstanding issue. Any help to resolve this would be appreciated. Please see the attached log file.

After a 2nd look, It looks like same issue. I must be doing something wrong.

[michaelld (Michael Dickens)]

Guessing you didn't successfully apply the patch. libarchive will be at 3.3.1_1 with a successful patch. Just do "port info libarchive" to see, both before and after patching. Doesn't require a "portindex" or "port selfupdate" or whatever for the info to be updated.

[tehcog (tehcog)]

Replying to michaelld:

Guessing you didn't successfully apply the patch. libarchive will be at 3.3.1_1 with a successful patch. Just do "port info libarchive" to see, both before and after patching. Doesn't require a "portindex" or "port selfupdate" or whatever for the info to be updated.

Thanks for the help but this is what I have:

dleece::NerdCenter { /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/files }-> port info libarchive
libarchive @3.3.1_1 (archivers)
Variants:             universal

Description:          Libarchive is a programming library that can create and read several different streaming archive formats, including most popular tar variants, several cpio formats, 7zip and rar. It can also write shar archives.
Homepage:             http://libarchive.org/

Build Dependencies:   autoconf, automake, libtool
Library Dependencies: bzip2, zlib, libxml2, xz, lzo2, libiconv, lz4, expat
Platforms:            darwin
License:              BSD
Maintainers:          Email: toby@macports.org
                      Policy: openmaintainer

Initially it complained about not finding the .diff files, but after I placed them in the "files" directory it ran generating the same error.

[michaelld (Michael Dickens)]

OK. Can you do the following:

sudo port clean --all libarchive
sudo port install libarchive

and, assuming that errors out, then:

cp $(port logfile libarchive) ~/Desktop/libarchive_log.txt
bzip2 ~/Desktop/libarchive_log.txt

and, then attach the file "libarchive_log.txt.bz2" found on the Desktop to this ticket for us to review. We like clean and full log files.

[ballapete (Peter "Pete" Dyballa)]

A simple cure is to configure with --disable_acl. This lets libarchive build on Snow Leopard. Then no patches are needed.

[chillin-]

Replying to ballapete:

A simple cure is to configure with --disable_acl. This lets libarchive build on Snow Leopard. Then no patches are needed.

Can you please be more specific? Is this a port command switch? What is the full command you use to build on SL? Thanks.

edit: ah, edit portfile and add the switch?

[ballapete (Peter "Pete" Dyballa)]

Replying to chillin-:

Can you please be more specific? Is this a port command switch? What is the full command you use to build on SL? Thanks.

You have to edit the Portfile. It has:

 28 configure.args   --enable-bsdtar=shared --enable-bsdcpio=shared \
 29                  --disable-silent-rules --without-nettle \
 30                  --without-openssl --without-lzmadec

On that last line, # 30, just add the text --disable-acl, save the file, (port) clean libarchive (--all certainly not needed) , and try to rebuild/upgrade again.

To edit the Portfile you need elavated privileges, i.e. start your editor with sudo. How the Portfile can be found was already mentioned. On the command line you can do:

sudo <some editor> $(port file libarchive)

or

sudo <some editor> `port file libarchive`

[ballapete (Peter "Pete" Dyballa)]

I reported that bug on GitHub and received the message that is already fixed in trunk: ​https://github.com/libarchive/libarchive/issues/888#issuecomment-287607782.

[chillin-]

Well... libarchive Portfile edited correctly, but when installing, I get a tk build failure on SL (not you again, tk!)

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_tk/tk/work/tk8.6.6/unix/../macosx/tkMacOSXXStubs.c:893: warning: unused variable ?macDraw?
make: *** [tkMacOSXXStubs.o] Error 1

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

A simple cure is to configure with --disable_acl. This lets libarchive build on Snow Leopard. Then no patches are needed.

And what is the consequence of disabling acl? Will this be a loss of functionality if we do this on all OS versions?

Replying to chillin-:

Well... libarchive Portfile edited correctly, but when installing, I get a tk build failure on SL (not you again, tk!)

Unrelated to this ticket.

[chillin-]

Replying to chillin-:

Well... libarchive Portfile edited correctly, but when installing, I get a tk build failure on SL (not you again, tk!)

Unrelated to this ticket.

ya think? [ ​https://trac.macports.org/ticket/52090 ] Thanks.

idk why when installing libarchive the first thing port does is try to upgrade tk

But libarchive builds for me on SL with the edited Portfile when upgrading jasper. Can't explain.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

And what is the consequence of disabling acl? Will this be a loss of functionality if we do this on all OS versions?

My explicite reply got lost due to an SSL error, so s short repetition:

It adds functionality to port, because it can build a zillion of updated packages, and saves my time and nerves when I do not have to list all the updated packages that might hopefully build today.

BTW, I heard or rather read the rumour that it is possible to programme Portfile in a way that different values are applied for use in different operating system versions. So old SL with its incomplete ACL support will have to wait until the next release when the source will be prepared for that incomplete mac OS.

[tehcog (tehcog)]

Replying to michaelld:

bzip2 ~/Desktop/libarchive_log.txt

and, then attach the file "libarchive_log.txt.bz2" found on the Desktop to this ticket for us to review. We like clean and full log files.

Thanks michaelld, please find the attached log file.

[tehcog (tehcog)]

Mavericks Fail Log File

[kencu (Ken)]

Looks like the acl functions are a new addition to libarchive in the past few months, ergo the bugs. Disabling acl for now on the affected systems until its fixed in a release version would be not a big deal, IMHO.

[michaelld (Michael Dickens)]

@tehcog: thanks for the logfile. it looks like when I asked git to squash all commits the result somehow isn't what it should be. I don't know why. I know this by comparing the current file that's causing the error from the current GIT master to the patched version. Grr ... but, thanks for indirectly pointing this out. I'll work on YA patch to try.

[michaelld (Michael Dickens)]

New patch to try. As directed before, this patch is applied at the top level port directory, not at the Portfile-leve. If you applied the prior patch, you'll want to reverse it (e.g., "patch -R -p1 < ....") or reset the GIT branch before applying the new patch. I've verified that the resulting ACL files are current to GIT master, and hence should work on all Mac OS X / macOS versions. Hopefully.

[tehcog (tehcog)]

Replying to michaelld:

New patch to try. As directed before, this patch is applied at the top level port directory, not at the Portfile-leve. If you applied the prior patch, you'll want to reverse it (e.g., "patch -R -p1 < ....") or reset the GIT branch before applying the new patch. I've verified that the resulting ACL files are current to GIT master, and hence should work on all Mac OS X / macOS versions. Hopefully.

Thanks michaelld, this worked for me on Mavericks. Previously, I was kind of just fumbling around in there, but finally understood what you meant (about applying patch correctly) in you previous posts. Looks good, Thanks again.

[michaelld (Michael Dickens)]

Excellent & YW! It works for me on 10.7 Lion; I don't have a 10.6 or 10.8 install yet for testing on those, but I'd guess if it works on 10.7 and 10.9, it's likely to work on the others too. Anybody else testing?

[thetrial (alabay)]

If someone tells me step-by-step, I could try. 10.7 here.

[dliessi (Davide Liessi)]

Works for me on 10.6.

[tehcog (tehcog)]

Replying to thetrial:

If someone tells me step-by-step, I could try. 10.7 here.

@thetrial: Bear with me on this, if someone else has something to add, please chime in...

I un-installed libarchive.

I tried to install libarchive and got the following ACL_SYNCHRONIZE error:

:info:build libarchive/archive_read_disk_entry_from_file.c:677:34: error: use of undeclared identifier 'ACL_SYNCHRONIZE'
:info:build         {ARCHIVE_ENTRY_ACL_SYNCHRONIZE, ACL_SYNCHRONIZE}
:info:build                                         ^
:info:build libarchive/archive_read_disk_entry_from_file.c:1371:31: error: invalid application of 'sizeof' to an incomplete type 'const struct <anonymous struct at libarchive/archive_read_disk_entry_from_file.c:638:14> []'
:info:build                 for (i = 0; i < (int)(sizeof(acl_perm_map) / sizeof(acl_perm_map[0])); ++i) {
:info:build                                             ^~~~~~~~~~~~~~
:info:build 2 errors generated.

I dl'd the following files from this thread:

libarchive_fix_from_3.3.1_try_2.diff
patch-3.3.1_to_master.diff
patch-Makefile.am.diff

and placed them all in the same directory (any directory, in this case ~/dl_dir).

For my particualr ports installation, I cd'd to the following path:

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/

(there should basically be a list of ports directories here)

I then applied the patch:

git apply ~/dl_dir/libarchive_fix_from_3.3.1_try_2.diff

the libarchive PortFile was then 'patched' and the other 2 files (patch-3.3.1_to_master.diff, patch-Makefile.am.diff)were placed in the:
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/files
directory.

I verified this by running

port info libarchive

and got the following result:

libarchive @3.3.1_1 (archivers)
...

I then ran:

sudo port install libarchive

and all was well. Hope this helps.

[thetrial (alabay)]

Replying to tehcog:

Great! Thank you very much. Seems, I now managed. I did not get the git patch procedure. Due to I usually use zsh with ohmyzsh (pup and puni shortcuts) this was a bit tricky … returning to manual upgrading :-) And yes, the first try worked! Now I upgrade all the stuck stuff that had been waiting, at the moment gtk3, this will take a bit time. I hope, at the end everything is going to be fine.

[tomemm]

lion 10.7.5 patch attemp

[tomemm]

I followed the above lion patch step and all was fine until the very last step: sudo port install libarchive, where I recieved the following error message: Error: Unable to execute port: Could not open file: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/Portfile

The file was there, with superuser rw permissions.

I have attached my terminal process:

[tehcog (tehcog)]

Replying to tomemm:

I followed the above lion patch step and all was fine until the very last step: sudo port install libarchive, where I recieved the following error message: Error: Unable to execute port: Could not open file: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/Portfile

The file was there, with superuser rw permissions.

From your initial description, I also thought of permissions as a potential issue.

<DISCLAIMER>I am probably not qualified to help you in this area as I am a novice.</DISCLAIMER>

However, I also noticed strange behavior with respect to my ports installation when issuing 'port' commands while inside the actual port directory. Did you try issuing the 'sudo install' from your home directory (~)?

Just a shot in the dark.

[ryandesign (Ryan Carsten Schmidt)]

Replying to tomemm:

I followed the above lion patch step and all was fine until the very last step: sudo port install libarchive, where I recieved the following error message: Error: Unable to execute port: Could not open file: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/Portfile

The file was there, with superuser rw permissions.

Fix the permissions so that non-root users can also read it.

sudo chmod 644 /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/archivers/libarchive/Portfile

[tomemm]

Thank you. Rainer also suggested that, which I have done and libarchive appears to be successfully built. Now on to the libsdl2 failured that followed. Thank you to everyone!

[BrentSqAR]

brentsqar - port install libarchive

[BrentSqAR]

osx 10.6.8 - build failed for now

i applied the "try patch", placed the two others in there location, was then running install

i attached the log file

looks like that nearly all changes from diff are not applied (last part of the log), and it starts all with an unreversed former patch

is there some help?

[chillin-]

Replying to BrentSqAR:

osx 10.6.8 - build failed for now ... is there some help?

See #comment:71 above, builds on snow with edited portfile disabling ACL, no patch necessary

[ballapete (Peter "Pete" Dyballa)]

Replying to BrentSqAR:

osx 10.6.8 - build failed for now

i applied the "try patch", placed the two others in there location, was then running install

i attached the log file

As far as I can see only one patch was applied, patch-libarchive__archive_read_support_format_lha.c.diff, the one mentioned in the not patched, original, Portfile. Applying that GIT based patch will alter Portfile.

*I* do not know how to apply that GIT based patch. This method has not been described here, at least not in a way that I could understand it, so looked for another way out of the dilemma.

[ballapete (Peter "Pete" Dyballa)]

No, I was wrong, the GIT based patch is applied very late, 3,000 lines later. And again 1,000 lines later a third patch phase starts:

  58::debug:patch patch phase started at Sun Mar  5 18:06:32 CET 2017
3090::debug:patch patch phase started at Sat Mar 25 01:32:19 CET 2017
4086::debug:patch patch phase started at Sat Mar 25 01:37:02 CET 2017
5353::debug:patch patch phase started at Sat Mar 25 01:59:30 CET 2017

I'd say that you did not invoke port clean libarchive between your tries…

[BrentSqAR]

it works on 10.6.8

thanks to everybody here - great job.

(it worked after: 1. port clean libarchive, 2. git apply ...try_2.diff with the other two patches in the directory, 3. port install)

by the way: what i was missing, because after port clean i got a bunch of error messages (but with ignoring them for a moment it was still installing):

error: patch failed: archivers/libarchive/Portfile:23
error: archivers/libarchive/Portfile: patch does not apply
error: archivers/libarchive/files/patch-3.3.1_to_master.diff: already exists in working directory
error: archivers/libarchive/files/patch-Makefile.am.diff: already exists in working directory
error: archivers/libarchive/files/patch-libarchive__archive_read_support_format_lha.c_p1.diff: already exists in working directory

[michaelld (Michael Dickens)]

Thanks for the feedback,everyone. I think we have quorum on this latest patch. If @tobypeterson doesn't get to it first, I'll go ahead and commit today when I'm doing my weekly port updates.

[tobypeterson]

Go for it

[reeskm (Rees Machtemes)]

Confirmed git patch as above works on 10.5.8 PPC. This is one of only two ports not upgrading on my system, so I'm very happy that this fixes it!

[michaelld (Michael Dickens)]

In 04aecffe45e179d1c4f133856cbaaba14fbb873e/macports-ports:

libarchive: add patch to fix build on older Mac OS X

Fixes: #53712

[Ionic (Mihai Moldovan)]

Got fed up with not being able to do anything on my machine, so I applied this after waiting a few days...

[l2dy (Zero King)]

Build of 'libarchive' failed.

DEBUG: system -W /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_archivers_libarchive/libarchive/work/libarchive-3.3.1: build/autogen.sh
+ aclocal -I build/autoconf
+ case `uname` in
++ uname
+ glibtoolize --automake -c
+ autoconf
configure.ac:136: error: possibly undefined macro: AC_MSG_FAILURE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:310: error: possibly undefined macro: AC_CHECK_LIB
Command failed: build/autogen.sh
Exit code: 1

[dliessi (Davide Liessi)]

Built without errors here (Mac OS 10.6.8, Xcode 3.2.6).

[michaelld (Michael Dickens)]

Thanks @Ionic for getting this committed. I totally spaced when doing my commits last night & forgot about this one.

[dliessi (Davide Liessi)]

Replying to michaelld:

Thanks @Ionic for getting this committed.

But all buildbots failed and the error in comment:105 is taken from the buildbot logs. As I said, it builds without errors for me, but there is surely something wrong in the update, maybe a missing dependency for the autoconf system?

[ryandesign (Ryan Carsten Schmidt)]

Replying to l2dy:

Build of 'libarchive' failed.

This has also been reported separately as #53889.

[michaelld (Michael Dickens)]

Let's move the discussion to the new ticket.