Date: Thu, 1 Apr 2010 21:30:55 -0700 From: Xin LI <delphij@gmail.com> To: Tom Uffner <tom@uffner.com> Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] Message-ID: <h2ga78074951004012130w2efad015o91226aa98dfd230b@mail.gmail.com> In-Reply-To: <4BB4FB35.2040703@uffner.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <r2oa78074951003312051kca872e0el511273674bd9e4b@mail.gmail.com> <4BB4FB35.2040703@uffner.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Tom,
On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner <tom@uffner.com> wrote:
[...]
> i realize this. i was just adding to the list of ports that no longer
> build after this change. ghostscript is kind of important for print
> support.
>
> i doubt this is "right" either, but it is a quick & dirty way to
> make mplayer compile again:
>
> --- configure.orig =C2=A0 =C2=A0 =C2=A02010-04-01 15:49:37.000000000 -040=
0
> +++ configure =C2=A0 2010-04-01 15:50:50.000000000 -0400
> @@ -5337,7 +5337,7 @@
> =C2=A0#include <dvdread/nav_read.h>
> =C2=A0int main(void) { return 0; }
> =C2=A0EOF
> - =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64
> -D_LARGEFILE64_SOURCE \
> + =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 \
> =C2=A0 =C2=A0 =C2=A0 -ldvdread $_ld_dl && _dvdread=3Dyes && _res_comment=
=3D"external"
> =C2=A0 fi
> =C2=A0fi
> @@ -7412,8 +7412,6 @@
> =C2=A0if test "$_largefiles" =3D yes || freebsd ; then
> =C2=A0 CFLAGS=3D"$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64"
> =C2=A0 if test "$_dvdread" =3D yes || test "$_libdvdcss_internal" =3D yes=
; then
> - =C2=A0 =C2=A0# dvdread support requires this (for off64_t)
> - =C2=A0 =C2=A0CFLAGS=3D"$CFLAGS -D_LARGEFILE64_SOURCE"
> =C2=A0 =C2=A0 cygwin && CFLAGS=3D"$CFLAGS -DSYS_CYGWIN"
> =C2=A0 fi
> =C2=A0fi
Specifying -DFOO basically means in C code one have:
%%%
#define FOO 1
%%%
This would not cause problem for zlib, at least not for zlib 1.2.4.1.
However, defining it do cause *64 interfaces being included, the
assumption doesn't seem right, according to my understanding of GNU
libc's manual.
I was wrong in a previous e-mail that it's not -D_LARGEFILE64_SOURCE
itself being broken, but #define _LARGEFILE64_SOURCE broken if it's
not defined as '1'. GNU libc seems to test whether this is defined,
rather than testing it against '1' (zlib do this).
So in conclusion:
a) We actually face two different types of problems, one is defining
_LARGEFILE64_SOURCE on FreeBSD, this is not right. It should not be
defined at all; another is to have "#define _LARGEFILE64_SOURCE"
instead of "#define _LARGEFILE64_SOURCE 1", this type would break not
only on FreeBSD but perhaps some other platforms, unfortunately this
seems to be common. Should one hit either case, please have it fixed
by upstream developers, as it would benefit not only FreeBSD but also
other platforms.
b) For now I have implemented a temporary solution on -HEAD by
unifdef'ing _LARGEFILE64_SOURCE, _LFS64_SOURCE on zlib.h and zconf.h,
so ports may appear as "fixed". This is not ideal since it makes us
to diverge away from zlib. A better solution is under discussion and
this situation MAY change in the next import.
Cheers,
--=20
Xin LI <delphij@delphij.net> http://www.delphij.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h2ga78074951004012130w2efad015o91226aa98dfd230b>