zziplib-0.13.49 +universal configure and build broken

[ejtttje@…]

Building libzzip with +universal breaks during configure when trying to determine the size of 'long'. Removing the line from configure.in and running autoreconfig allows it to build, but then dies during linking because the libzzipwrapper is only linked as the native architecture, not as universal. At this point I am stymied how to resolve.

I need universal libzzip so I can build my app as 32-bit (app currently depends on another library which only supports 32-bit) and then work towards fixing the other dependency so I can move to 64 bit as well.

[ejtttje@…]

debug log from stock build, see end "checking size of long... configure: error: cannot determine a size for long"

[ejtttje@…]

Patch to remove check for size of long from configure.ac

[ejtttje@…]

debug log after applying previous patch and running 'autoconf', note error "ld: warning: in ./.libs/libzzipwrap.dylib, file is not of required architecture"

[ejtttje@…]

The annoying thing is that after the patch it does build the object files for zzipwrap as 'universal', you can see that in both the log -arch commands and the results:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_libzzip/work/zziplib-0.13.49/Darwin_10.2.0_i386.d$ file zzipwrap/*.o
zzipwrap/wrap.o:     Mach-O universal binary with 2 architectures
zzipwrap/wrap.o (for architecture x86_64):	Mach-O 64-bit object x86_64
zzipwrap/wrap.o (for architecture i386):	Mach-O object i386
zzipwrap/zzipwrap.o: Mach-O universal binary with 2 architectures
zzipwrap/zzipwrap.o (for architecture x86_64):	Mach-O 64-bit object x86_64
zzipwrap/zzipwrap.o (for architecture i386):	Mach-O object i386

But the libzzipwrap.dylib is linked as only x86_64:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_libzzip/work/zziplib-0.13.49/Darwin_10.2.0_i386.d$ file zzipwrap/.libs/libzzipwrap.dylib
zzipwrap/.libs/libzzipwrap.dylib: Mach-O 64-bit dynamically linked shared library x86_64

[ejtttje@…]

Also note that in the original summary I mention running autoreconf, but this causes more trouble with libtool no longer working for linking:

../libtool: line 756: X--tag=CC: command not found
../libtool: line 789: libtool: ignoring unknown tag : command not found
../libtool: line 756: X--mode=link: command not found
../libtool: line 906: *** Warning: inferring the mode of operation is deprecated.: command not found
../libtool: line 907: *** Future versions of Libtool will require --mode=MODE be specified.: command not found
../libtool: line 937: libtool: warning: cannot infer operation mode from `/usr/bin/gcc-4.2': No such file or directory
../libtool: line 6656: libtool: you must specify a MODE: command not found
../libtool: line 6657: Try `libtool --help' for more information.: command not found

So instead after previous patch I used just 'autoconf' for the latter log file, which is using version 2.65 from macports, not the native 2.61 with OS X 10.6...

[ejtttje@…]

A Portfile patch, updates to 0.13.58 and fixes universal build

[ejtttje@…]

new version of no_config_long.patch to go with updated Portfile

[ejtttje@…]

updated pre-existing zzip/Makefile.in patch for 0.13.58

[ejtttje@…]

SOLVED: I found that updating the version to 0.13.58 fixes the secondary zzipwrap issues, so you can apply the included patch-libzzip_Portfile.diff to update the Portfile for a few minor universal build issues, and then include the two source patches, patch-configure.ac.diff and patch-zzib_Makefile.in.diff in the 'files' directory.

[macsforever2000@…]

r64707.