Re: 4.0.3 doesn't build on MacOS X

[Ben Abbott]

On Jul 5, 2016, at 23:56, Mike Miller <address@hidden> wrote:

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 stable
branch before 4.0.3:

http://hg.savannah.gnu.org/hgweb/octave/rev/44f7664689f2?revcount=20#l5.1

and is probably not noticed on GNU systems because so many other
libraries link with libz.

For example, on my Debian system both libfreetype and libhdf5 are linked
with libz as a dependency, so whether or not Z_LIBS is populated,
liboctinterp will be implicitly linked with libz.

Rik pushed a fix.

https://savannah.gnu.org/bugs/?48407

Ben