zlib autoconf question

zlib autoconf question

[Lars Magne Ingebrigtsen]

I'm not sure whether it's really necessary to check for zlib -- does
Emacs even build without png support these days? -- but perhaps it is.

Anyway, I wrote the obvious:

  AC_CHECK_LIB(z, inflateInit2, HAVE_ZLIB=yes, HAVE_ZLIB=no)

And that fails with:

/home/larsi/src/emacs/trunk/conftest.c:118: undefined reference to `inflateInit2'

But inflateInit2 definitely exists (it's the function decompress.c
uses).

However, running strings over libz says:

inflateReset
inflateReset2
inflateInit2_
inflateInit_

And

  AC_CHECK_LIB(z, inflateInit2_, HAVE_ZLIB=yes, HAVE_ZLIB=no)

works!

What's up with that?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Jérémie Courrèges-Anglas]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure whether it's really necessary to check for zlib -- does
> Emacs even build without png support these days? -- but perhaps it is.
>
> Anyway, I wrote the obvious:
>
>   AC_CHECK_LIB(z, inflateInit2, HAVE_ZLIB=yes, HAVE_ZLIB=no)
>
> And that fails with:
>
> /home/larsi/src/emacs/trunk/conftest.c:118: undefined reference to `inflateInit2'
>
> But inflateInit2 definitely exists (it's the function decompress.c
> uses).
>
> However, running strings over libz says:
>
> inflateReset
> inflateReset2
> inflateInit2_
> inflateInit_
>
> And
>
>   AC_CHECK_LIB(z, inflateInit2_, HAVE_ZLIB=yes, HAVE_ZLIB=no)
>
> works!
>
> What's up with that?

inflateInit2 is a macro that "calls" inflateInit2_.

-- 
jca | PGP : 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494

Re: zlib autoconf question

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But inflateInit2 definitely exists

As a function?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

>> But inflateInit2 definitely exists
>
> As a function?

I call it as such in decompress.c:

  if (inflateInit2 (&stream, 16 + MAX_WBITS) != Z_OK)
    return Qnil;

and it works there...
    
-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>>> But inflateInit2 definitely exists
>>
>> As a function?
>
> I call it as such in decompress.c:
>
>   if (inflateInit2 (&stream, 16 + MAX_WBITS) != Z_OK)
>     return Qnil;
>
> and it works there...

That doesn't matter.  What matters is that the symbol exists as a
function.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: zlib autoconf question

[Paul Eggert]

On 08/08/2013 04:14 AM, Lars Magne Ingebrigtsen wrote:
> AC_CHECK_LIB(z, inflateInit2_, HAVE_ZLIB=yes, HAVE_ZLIB=no)
> 
> works!
> 
> What's up with that?

inflateInit2 is a macro that invokes inflateInit2_,
a function that user code isn't supposed to call directly.
AC_CHECK_LIB can't check for macros, only functions.
I'd check for something that's a function, zlibVersion say.

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> inflateInit2 is a macro that invokes inflateInit2_,
> a function that user code isn't supposed to call directly.
> AC_CHECK_LIB can't check for macros, only functions.
> I'd check for something that's a function, zlibVersion say.

Ah, I see.  Thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Dmitry Antipov]

On 08/08/2013 04:49 PM, Lars Magne Ingebrigtsen wrote:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> inflateInit2 is a macro that invokes inflateInit2_,
>> a function that user code isn't supposed to call directly.
>> AC_CHECK_LIB can't check for macros, only functions.
>> I'd check for something that's a function, zlibVersion say.
>
> Ah, I see.  Thanks.

Reasonably modern environments should have zlib development
packages with pkg-config data (look for zlib.pc on your system),
so you can consider something like below:

PKG_CHECK_MODULES(ZLIB, zlib >= 1.2, HAVE_ZLIB=yes, HAVE_ZLIB=no)

Dmitry

Re: zlib autoconf question

[Eli Zaretskii]

> Date: Thu, 08 Aug 2013 16:57:50 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: emacs-devel@gnu.org
> 
> Reasonably modern environments should have zlib development
> packages with pkg-config data (look for zlib.pc on your system),

But not all of them have zlib.pc (e.g., on Windows zlib is distributed
without pkg-config support).

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But not all of them have zlib.pc (e.g., on Windows zlib is distributed
> without pkg-config support).

Checking for -lz directly makes more sense than checking for
pkg-config.  -lz is a very stable library, so looking at the version
number isn't particularly useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Ulrich Mueller]

>>>>> On Thu, 08 Aug 2013, Lars Magne Ingebrigtsen wrote:

> I'm not sure whether it's really necessary to check for zlib -- does
> Emacs even build without png support these days? -- but perhaps it
> is.

It certainly can be built without png support. Gentoo has a USE flag
that turns it off and it works.

I hope there will be an explicit configure option to enable/disable
zlib support, too?

Ulrich

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Ulrich Mueller <ulm@gentoo.org> writes:

> I hope there will be an explicit configure option to enable/disable
> zlib support, too?

Is there a reason to have such an option?  If -lz is present, I can't
really see why anybody would want Emacs to be built without it...

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Ulrich Mueller]

>>>>> On Sun, 11 Aug 2013, Lars Magne Ingebrigtsen wrote:

>> I hope there will be an explicit configure option to enable/disable
>> zlib support, too?

> Is there a reason to have such an option? If -lz is present, I can't
> really see why anybody would want Emacs to be built without it...

Emacs may be built one one host where the shared library is present,
and the resulting binary then distributed to another host where it
isn't.

It's a common scenario with Gentoo's binary packages, and without a
configure option to suppress autodetection of the library, there's no
way to do proper tracking of dependencies.

Ulrich

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Ulrich Mueller <ulm@gentoo.org> writes:

> Emacs may be built one one host where the shared library is present,
> and the resulting binary then distributed to another host where it
> isn't.

Is that a relevant issue with -lz?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Ulrich Mueller]

>>>>> On Mon, 12 Aug 2013, Lars Magne Ingebrigtsen wrote:

> Ulrich Mueller <ulm@gentoo.org> writes:
>> Emacs may be built one one host where the shared library is
>> present, and the resulting binary then distributed to another host
>> where it isn't.

> Is that a relevant issue with -lz?

Otherwise I wouldn't have mentioned it. Fact is that Gentoo has a
global USE flag that allows to disable zlib support.

And adding a configure option should be simple enough.

Ulrich

Re: zlib autoconf question

[Paul Eggert]

Ulrich Mueller wrote:
> And adding a configure option should be simple enough.

I gave it a shot, in trunk bzr 113803.

Re: zlib autoconf question

[Eli Zaretskii]

> Date: Sun, 11 Aug 2013 22:28:04 +0200
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: emacs-devel@gnu.org
> 
> >>>>> On Sun, 11 Aug 2013, Lars Magne Ingebrigtsen wrote:
> 
> >> I hope there will be an explicit configure option to enable/disable
> >> zlib support, too?
> 
> > Is there a reason to have such an option? If -lz is present, I can't
> > really see why anybody would want Emacs to be built without it...
> 
> Emacs may be built one one host where the shared library is present,
> and the resulting binary then distributed to another host where it
> isn't.

The real solution to such problems is to probe for the availability of
the shared library at run time.

Re: zlib autoconf question

[Stefan Monnier]

> The real solution to such problems is to probe for the availability of
> the shared library at run time.

+1


        Stefan

Re: zlib autoconf question

[Stefan Monnier]

> The real solution to such problems is to probe for the availability of
> the shared library at run time.

Or even better, to rely on an FFI (so not only you check availability
at run-time, but you don't even need to have the library at
compile-time).


        Stefan

Re: zlib autoconf question

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Ulrich Mueller <ulm@gentoo.org>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 12 Aug 2013 09:58:51 -0400
> 
> > The real solution to such problems is to probe for the availability of
> > the shared library at run time.
> 
> Or even better, to rely on an FFI (so not only you check availability
> at run-time, but you don't even need to have the library at
> compile-time).

That's similar to what the Windows port does with all the optional
libraries: the headers are required during the compilation, but the
libraries are not.  They are loaded when needed, with the equivalents
of dlopen and dlsym.

Re: zlib autoconf question

[Stefan Monnier]

> That's similar to what the Windows port does with all the optional
> libraries: the headers are required during the compilation, but the
> libraries are not.  They are loaded when needed, with the equivalents
> of dlopen and dlsym.

With an FFI you don't even need the headers.  The library could be used
even if it didn't exist back when Emacs was built.


        Stefan

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> With an FFI you don't even need the headers.  The library could be used
> even if it didn't exist back when Emacs was built.

If you look at how much scaffolding is typically needed to use a C
library in Emacs, I'm not sure how realistic that is.  I mean -- zlib is
a pretty straightforward library.  I look at decompress.c and try to
envision how much Emacs Lisp would have to be exposed to C things, and I
think it's perhaps ... a lot.

I've done quite a bit of FFI in Lispworks.  It's kinda grody.  I frequently
end up with a bit of C scaffolding just to make things easier.

And Lispworks doesn't have all the funky concepts that Emacs has.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

One crucial point about libraries that handle file formats
(compressed, or images) is that if they don't carefully check their
input for invalid format, they can be openings for an attack.

Are there groups that carefully study these libraries to make sure
they detect all erroneous input?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: zlib autoconf question

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Are there groups that carefully study these libraries to make sure
> they detect all erroneous input?

zlib is a pretty mature library.  Is gzip based on it these days, or
does it use a separate implementation?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: zlib autoconf question

[Paul Eggert]

Lars Magne Ingebrigtsen wrote:

> zlib is a pretty mature library.  Is gzip based on it these days, or
> does it use a separate implementation?

gzip's still separate, but we're considering changing it to use zlib,
as zlib seems to be more reliable than gzip's own implementation.

To answer Richard's question, yes, various groups look for bugs in
both zlib and gzip.

Re: zlib autoconf question

[Dmitry Antipov]

On 08/12/2013 12:28 AM, Ulrich Mueller wrote:

> Emacs may be built one one host where the shared library is present,
> and the resulting binary then distributed to another host where it
> isn't.
>
> It's a common scenario with Gentoo's binary packages, and without a
> configure option to suppress autodetection of the library, there's no
> way to do proper tracking of dependencies.

+1, and don't forget about --without-all configuration.

Dmitry