GNU bug report logs -
#75667
Emacs 30.0.93 build failure if -lz but not <zlib.h>
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sun, 19 Jan 2025 08:30:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 19 Jan 2025 16:33:52 -0800
with message-id <c4313f11-891d-49fa-b2bd-c876a835f865 <at> cs.ucla.edu>
and subject line Re: bug#75667: Emacs 30.0.93 build failure if -lz but not <zlib.h>
has caused the debbugs.gnu.org bug report #75667,
regarding Emacs 30.0.93 build failure if -lz but not <zlib.h>
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
75667: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75667
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
In the emacs-30.0.93 pretest, the build fails on cfarm119.cfarm.net
which is running AIX 7.3. To reproduce the problem on that platform:
/configure CC=/opt/IBM/openxlC/17.1.1/bin/ibm-clang
--with-jpeg=ifavailable --with-png=ifavailable --with-gif=ifavailable
--with-tiff=ifavailable --with-gnutls=ifavailable
gmake
The build eventually fails with:
CC decompress.o
decompress.c:23:10: fatal error: 'zlib.h' file not found
#include <zlib.h>
^~~~~~~~
As the #include is protected by "#ifdef HAVE_ZLIB", it appears that
'configure' assumes that if gcc -lz works then "#include <zlib.h>" will
work too. That assumption is incorrect on this platform.
I suppose HAVE_ZLIB could be changed to be true only if zlib.h can be
included; or perhaps the #include should be protected by #ifdef
HAVE_ZLIB_H (though this sounds more complicated). Up to whoever did the
zlib stuff.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
On 2025-01-19 01:24, Eli Zaretskii wrote:
> Where is zlib.h on that platform?
It isn't installed, as far as I can see. I expected it's in some
optional package that is absent on that build platform.
Although cfarm119 does have a file /opt/freeware/include/zlib.h, that
corresponds to /opt/freeware/lib/libz.a, not to what -lz picks up which
is /usr/lib/libz.a (a symlink to /usr/opt/rpm/lib/libz.a). I wouldn't
recommend mixing up versions like that.
> It's too late to make serious changes in the configury on the release
> branch, but maybe we should simply disable HAVE_ZLIB_H on AIX? Then
> we could find a proper solution on master.
Not sure that would be a good idea as this isn't an AIX-specific
problem. Anybody can mess up .h and -l in this way, on any OS.
On the same platform I discovered a similar problem with -lsqlite3. I
fixed both problems on master by installing the attached, and I'm
marking the bug as done.
For the release branch I suppose we can just say something like "just
use --without-zlib if you have problems".
As I'm sure you know, this library configury is waaay too complex and
idiosyncratic. Why don't libz and libsqlite3 use pkg-config, for
example? But I'm inclined to let the relevant library experts deal with
that whenever they have time.
[0001-Port-better-to-AIX-7.3-with-lz-but-not-zlib.h.patch (text/x-patch, attachment)]
[0002-Port-better-to-AIX-7.3-with-lsqlite3-but-not-sqlite3.patch (text/x-patch, attachment)]
This bug report was last modified 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.