On Tue, Jul 05, 2016 at 14:46:08 +0000, Ben Abbott wrote:On Jul 5, 2016, at 7:10 AM, Ben Abbott <address@hidden> wrote:
On Jul 5, 2016, at 02:30, Sebastian <address@hidden> wrote:
Am 05.07.2016 um 02:33 schrieb Ben Abbott <address@hidden>:
Perhaps there is a bug that misses the libz when it is in /usr/lib when the prefix is something else?
Ben
Yes, that's quite possibly. Are you using libz from fink? (homebrew tries to use the preinstalled libs as much as possible). However, the good news: the patch does not hurt in my case.
@Marius: did you submit the patch to the tracker?
Sebastian
Fink uses Apple's libz.
Ben
I don’t fully understand what is happening, but thought I’d try some experiments.
Rather than applying the patch to Makefile.in (which is generated by Makefile.am) I tried direclty specifying zlib’s lib and include directories.
--with-z-includedir=/usr/include/
--with-z-libdir=/usr/lib/
Configure found zlib and was able to use it.
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h… yes
Z CPPFLAGS: -I/usr/include/
Z LDFLAGS: -L/usr/lib/
Z libraries: -lz
However, make still fails.
Next I tried Jordi’s recent change to /m4/acinclude.m4, this also failed.
I think this was accidentally broken with this changeset on the stablebranch before 4.0.3:http://hg.savannah.gnu.org/hgweb/octave/rev/44f7664689f2?revcount=20#l5.1and is probably not noticed on GNU systems because so many otherlibraries link with libz.For example, on my Debian system both libfreetype and libhdf5 are linkedwith libz as a dependency, so whether or not Z_LIBS is populated,liboctinterp will be implicitly linked with libz.
|