HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]

[Xin LI]

Hi,

Just a heads-up that zlib in base system (libz) has been updated to
1.2.4. We tried to keep -HEAD as close as possible to the vendor
version, but there is some changes in its internal data structure, and
we did not use versioned symbols in the past, making shared library
version bump unavoidable.

A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.

Please make sure that you have at least libxml2-2.7.6_2 in your ports
tree before even thinking about updating your ports tree. Older libxml2
uses some knowledge of zlib internals that has been changed in this
update which is known to cause problem.

- -------- Original Message --------
Subject: svn commit: r205471 - in head: . lib/libz lib/libz/contrib
lib/libz/doc sys/sys
Date: Mon, 22 Mar 2010 21:11:55 +0000 (UTC)
From: Xin LI <***@FreeBSD.ORG>
To: src-***@FreeBSD.ORG, svn-src-***@FreeBSD.ORG,
svn-src-***@FreeBSD.ORG

Author: delphij
Date: Mon Mar 22 21:11:55 2010
New Revision: 205471
URL: http://svn.freebsd.org/changeset/base/205471

Log:
Update to zlib 1.2.4 and add versioned symbols to the
library.

Sponsored by: iXsystems, Inc.

[Robert Watson]

Post by Xin LI
A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.
Please make sure that you have at least libxml2-2.7.6_2 in your ports tree
before even thinking about updating your ports tree. Older libxml2 uses
some knowledge of zlib internals that has been changed in this update which
is known to cause problem.

While the update sounds like a good idea (as does moving to symbol verisoning
for this library), I'm not yet convinced an MFC is a good idea given the
compatibility issues you describe. Perhaps you could clarify a bit the
failure mode: this affects only people who rebuild their ports using exactly
the same ports versions, but after having done an upgrade that includes this
update? It sounds like existing binaries will continue to work since they
will reference the old library version?

Robert N M Watson
Computer Laboratory
University of Cambridge

[Garrett Cooper]

Post by Robert Watson

Post by Xin LI
A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.
Please make sure that you have at least libxml2-2.7.6_2 in your ports tree
before even thinking about updating your ports tree. Older libxml2 uses
some knowledge of zlib internals that has been changed in this update which
is known to cause problem.

While the update sounds like a good idea (as does moving to symbol verisoning
for this library), I'm not yet convinced an MFC is a good idea given the
compatibility issues you describe. Perhaps you could clarify a bit the
failure mode: this affects only people who rebuild their ports using exactly
the same ports versions, but after having done an upgrade that includes this
update? It sounds like existing binaries will continue to work since they
will reference the old library version?

Yes, but the number of libraries which need to be fixed is a pain. If
you go the conservative (not ultra conservative) route, you'll have to
rebuild all dependencies of graphics/png and graphics/tiff (which
includes a ton of gnome apps, X, etc). Oh, and did I forget to mention
that libtool hardcodes paths and versioning information? Of course
most people won't see this fact until they run make delete-old-libs,
but it's a doosy... This is the primary reason why Gentoo Linux has a
script to clean up these [libtool] messes...

That point alone is a reason for being ultra-conservative with this
MFCing change. This won't affect folks building from scratch after
this commit, but it'll easily kill off an afternoon or day for folks
upgrading if they one isn't careful because the impact is large.

Of course scripting the activity to avoid these times of base system
library bumps is trivial, but my script that I whipped up still has
rough edges and I'd rather not submit it quite yet...

Thanks,
-Garrett

[Rainer Hurling]

Post by Garrett Cooper

Post by Robert Watson

Post by Xin LI
A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.
Please make sure that you have at least libxml2-2.7.6_2 in your ports tree
before even thinking about updating your ports tree. Older libxml2 uses
some knowledge of zlib internals that has been changed in this update which
is known to cause problem.

While the update sounds like a good idea (as does moving to symbol verisoning
for this library), I'm not yet convinced an MFC is a good idea given the
compatibility issues you describe. Perhaps you could clarify a bit the
failure mode: this affects only people who rebuild their ports using exactly
the same ports versions, but after having done an upgrade that includes this
update? It sounds like existing binaries will continue to work since they
will reference the old library version?

Yes, but the number of libraries which need to be fixed is a pain. If
you go the conservative (not ultra conservative) route, you'll have to
rebuild all dependencies of graphics/png and graphics/tiff (which
includes a ton of gnome apps, X, etc). Oh, and did I forget to mention
that libtool hardcodes paths and versioning information? Of course
most people won't see this fact until they run make delete-old-libs,
but it's a doosy... This is the primary reason why Gentoo Linux has a
script to clean up these [libtool] messes...

To avoid the biggest trouble when updating I temporarily went another
way. Before 'make delete-old-libs' I made a copy of libz.so.5 under compat:

cp -p /lib/libz.so.5 /usr/local/lib/compat/
cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/

I plan to delete these copies in some weeks. Do you think this is ok or
do I have to expect unwanted side effects?

Thanks,
Rainer Hurling

Post by Garrett Cooper
That point alone is a reason for being ultra-conservative with this
MFCing change. This won't affect folks building from scratch after
this commit, but it'll easily kill off an afternoon or day for folks
upgrading if they one isn't careful because the impact is large.
Of course scripting the activity to avoid these times of base system
library bumps is trivial, but my script that I whipped up still has
rough edges and I'd rather not submit it quite yet...

[Garrett Cooper]

Post by Garrett Cooper

Post by Robert Watson

Post by Xin LI
A MFC of this update is planned, but we will have to make some rather
aggressive changes against the library and more testing.
Please make sure that you have at least libxml2-2.7.6_2 in your ports tree
before even thinking about updating your ports tree.  Older libxml2 uses
some knowledge of zlib internals that has been changed in this update which
is known to cause problem.

While the update sounds like a good idea (as does moving to symbol verisoning
for this library), I'm not yet convinced an MFC is a good idea given the
compatibility issues you describe.  Perhaps you could clarify a bit the
failure mode: this affects only people who rebuild their ports using exactly
the same ports versions, but after having done an upgrade that includes this
update?  It sounds like existing binaries will continue to work since
they
will reference the old library version?

Yes, but the number of libraries which need to be fixed is a pain. If
you go the conservative (not ultra conservative) route, you'll have to
rebuild all dependencies of graphics/png and graphics/tiff (which
includes a ton of gnome apps, X, etc). Oh, and did I forget to mention
that libtool hardcodes paths and versioning information? Of course
most people won't see this fact until they run make delete-old-libs,
but it's a doosy... This is the primary reason why Gentoo Linux has a
script to clean up these [libtool] messes...

To avoid the biggest trouble when updating I temporarily went another way.
cp -p /lib/libz.so.5 /usr/local/lib/compat/
cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/
I plan to delete these copies in some weeks. Do you think this is ok or do I
have to expect unwanted side effects?

I'm pretty sure that works as well (just make sure to rerun
ldconfig and ldconfig -32 after the fact -- or do /etc/rc.d/ldconfig
restart, boot your system into multiuser mode, etc, and you should be
in good shape); it should get you past this transition.

It would be nice if there an entry in UPDATING added for this to
warn people of the breakage and this potential suggested workaround
*HINT*...

Post by Garrett Cooper
That point alone is a reason for being ultra-conservative with this
MFCing change. This won't affect folks building from scratch after
this commit, but it'll easily kill off an afternoon or day for folks
upgrading if they one isn't careful because the impact is large.
Of course scripting the activity to avoid these times of base system
library bumps is trivial, but my script that I whipped up still has
rough edges and I'd rather not submit it quite yet...

Thanks,
-Garrett

[Michael Butler]

Post by Xin LI
Just a heads-up that zlib in base system (libz) has been updated to
1.2.4. We tried to keep -HEAD as close as possible to the vendor
version, but there is some changes in its internal data structure, and
we did not use versioned symbols in the past, making shared library
version bump unavoidable.

This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

Adding ..

/*
* This is hard-configured for FreeBSD.
*/
#include <sys/types.h>
#define z_off_t off_t
#define off64_t off_t <-----
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif

.. to /usr/include/zconf.h seems to resolve this breakage,

imb

[Dag-Erling Smørgrav]

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

They should not use off64_t. More importantly, they should not rely on
zlib to provide it.

DES

[Tom Uffner]

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.

[Xin LI]

Post by Tom Uffner

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.

Just because they used to compile DOES NOT mean they were right. It's
NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see:

http://www.delorie.com/gnu/docs/glibc/libc_13.html

Cheers,

[Tom Uffner]

Post by Xin LI

Post by Tom Uffner

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.

Just because they used to compile DOES NOT mean they were right. It's
http://www.delorie.com/gnu/docs/glibc/libc_13.html

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 2010-04-01 15:49:37.000000000 -0400
+++ configure 2010-04-01 15:50:50.000000000 -0400
@@ -5337,7 +5337,7 @@
#include <dvdread/nav_read.h>
int main(void) { return 0; }
EOF
- cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE \
+ cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
-ldvdread $_ld_dl && _dvdread=yes && _res_comment="external"
fi
fi
@@ -7412,8 +7412,6 @@
if test "$_largefiles" = yes || freebsd ; then
CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then
- # dvdread support requires this (for off64_t)
- CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE"
cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN"
fi
fi

[Xin LI]

Hi, Tom,

On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner <***@uffner.com> wrote:
[...]

Post by Tom Uffner
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
--- configure.orig      2010-04-01 15:49:37.000000000 -0400
+++ configure   2010-04-01 15:50:50.000000000 -0400
@@ -5337,7 +5337,7 @@
 #include <dvdread/nav_read.h>
 int main(void) { return 0; }
 EOF
-    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE \
+    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
      -ldvdread $_ld_dl && _dvdread=yes && _res_comment="external"
  fi
 fi
@@ -7412,8 +7412,6 @@
 if test "$_largefiles" = yes || freebsd ; then
  CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
  if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then
-    # dvdread support requires this (for off64_t)
-    CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE"
    cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN"
  fi
 fi

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,

[Garrett Cooper]

Post by Xin LI
Hi, Tom,
[...]

Post by Tom Uffner
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
--- configure.orig      2010-04-01 15:49:37.000000000 -0400
+++ configure   2010-04-01 15:50:50.000000000 -0400
@@ -5337,7 +5337,7 @@
 #include <dvdread/nav_read.h>
 int main(void) { return 0; }
 EOF
-    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE \
+    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
      -ldvdread $_ld_dl && _dvdread=yes && _res_comment="external"
  fi
 fi
@@ -7412,8 +7412,6 @@
 if test "$_largefiles" = yes || freebsd ; then
  CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
  if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then
-    # dvdread support requires this (for off64_t)
-    CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE"
    cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN"
  fi
 fi

%%%
#define FOO 1
%%%

Actually, `CFLAGS += -DFOO=1' is different from `CFLAGS += -DFOO' (I
think Xin Li meant to state the former format).

$ for i in -DBAR -DFOO -DFOO=1 -DFOO=2; do echo "$i"; cc -c $i
test_defined.c; done
-DBAR
-DFOO
test_defined.c:2:2: warning: #warning FOO is defined
test_defined.c:6:2: warning: #warning FOO is 1
test_defined.c:10:2: warning: #warning FOO is non-zero
-DFOO=1
test_defined.c:2:2: warning: #warning FOO is defined
test_defined.c:6:2: warning: #warning FOO is 1
test_defined.c:10:2: warning: #warning FOO is non-zero
-DFOO=2
test_defined.c:2:2: warning: #warning FOO is defined
test_defined.c:10:2: warning: #warning FOO is non-zero
$ cat test_defined.c
#ifdef FOO
#warning FOO is defined
#endif

#if FOO == 1
#warning FOO is 1
#endif

#if FOO
#warning FOO is non-zero
#endif

[...]

Thanks,
-Garrett

[Xin LI]

Post by Tom Uffner

Post by Tom Uffner

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of "off64_t".

it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.

Just because they used to compile DOES NOT mean they were right.  It's
http://www.delorie.com/gnu/docs/glibc/libc_13.html

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
--- configure.orig      2010-04-01 15:49:37.000000000 -0400
+++ configure   2010-04-01 15:50:50.000000000 -0400
@@ -5337,7 +5337,7 @@
 #include <dvdread/nav_read.h>
 int main(void) { return 0; }
 EOF
-    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE \
+    cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
      -ldvdread $_ld_dl && _dvdread=yes && _res_comment="external"
  fi
 fi
@@ -7412,8 +7412,6 @@
 if test "$_largefiles" = yes || freebsd ; then
  CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
  if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then
-    # dvdread support requires this (for off64_t)
-    CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE"
    cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN"
  fi
 fi

I think the latest (1.2.4.1) zlib has a bug that prevents using
-D_LARGEFILE64_SOURCE at all, and expects -D_LARGEFILE64_SOURCE=1.
I'll submit a patch to upstream :(

Cheers,

[Dag-Erling Smørgrav]

Post by Xin LI

Post by Tom Uffner

Post by Michael Butler
This breaks most (if not all) of the QT4-dependent ports for the
lack of a definition of "off64_t".

it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 & everything that depends on it.

Just because they used to compile DOES NOT mean they were right. It's
http://www.delorie.com/gnu/docs/glibc/libc_13.html

Nor is it correct on Linux. As the above link says, _LARGEFILE64_SOURCE
is a hack that was introduced to ease the transition from 32-bit off_t
to 64-bit off_t. The correct idiom is to define _FILE_OFFSET_BITS to 64
before including <sys/types.h> and <sys/stat.h>.

http://www.delorie.com/gnu/docs/glibc/libc_13.html

That was *fourteen years ago*, almost to the day. There is *no* excuse
for using this hack today. *Especially* in software that was written
long after that document was published. *Especially* when all you need
to do to get it right is add AC_SYS_LARGEFILE to configure.ac and use
off_t, struct stat and stat() / lstat() (without the "64" suffix) as if
none of this had ever happened.

And yes, I *will* keep harping on this until people Get It.

DES

[Mark Linimon]

Post by Dag-Erling Smørgrav
And yes, I *will* keep harping on this until people Get It.

You're harping at the wrong people. Complain to the application authors,
not to the poor slobs trying to maintain the ports collection.

There's a lot of crap code out there on the internet. If we want to
insist that all the application authors both a) write good code and that
b) understands how FreeBSD does things, well, we can do that, but it's
not going to have much effect.

Probably 75%+ of the application authors neither know nor care that
their code is being run on anything other than Linux. In extreme
cases we've enountered authors who outright refuse to accept our
patches, either due to philosophical disagreement or just due to the
xtra hassle.

I'd just be happy if we could keep what we have working, without
"surprise" regressions. I'm not going to get in the business of trying
to preach to the application authors. Feel free.

mcl

[Dag-Erling Smørgrav]

Post by Mark Linimon
Probably 75%+ of the application authors neither know nor care that
their code is being run on anything other than Linux.

I think you missed the bit where what they're doing is wrong on Linux,
too.

DES

[Garrett Cooper]

Post by Dag-Erling Smørgrav
And yes, I *will* keep harping on this until people Get It.

You're harping at the wrong people.  Complain to the application authors,
not to the poor slobs trying to maintain the ports collection.
There's a lot of crap code out there on the internet.  If we want to
insist that all the application authors both a) write good code and that
b) understands how FreeBSD does things, well, we can do that, but it's
not going to have much effect.
Probably 75%+ of the application authors neither know nor care that
their code is being run on anything other than Linux.  In extreme
cases we've enountered authors who outright refuse to accept our
patches, either due to philosophical disagreement or just due to the
xtra hassle.

The problem actually was most likely the fact that the functionality
wasn't properly documented or that people didn't thoroughly read or
understand the documentation before implementing the feature. If
there's anything that I've learned from cleaning up messes in the past
(to be fair, some which I've created as well), it's that a lot of
incorrect logic is created by misunderstanding things and/or making
false assumptions on how things should work.

But yes, zlib is buggy w.r.t. the item Xin Li mentioned and needed to
be fixed. Too many folks try to resolve application porting issues by
using inline:

#ifndef SOME_LARGELY_USED_CONSTANT_INTRODUCED_IN_VERSION_B
/* #define a constant or typedef a feature */
#endif

This generally quasi-works in versions A (assuming the application
runs and the developer upstream did their testing on version A's
software... heh) or version C (typically a Linux) developer decided
that they wanted to change the definition and dashed the consequences
about backwards compatibility in their code. kernel.org sources are
riddled with this kind of `decision making'.

But I digress...

-Garrett

[Xin LI]

Hi,

Post by Garrett Cooper

Post by Mark Linimon

Post by Dag-Erling Smørgrav
And yes, I *will* keep harping on this until people Get It.

You're harping at the wrong people. Complain to the application authors,
not to the poor slobs trying to maintain the ports collection.
There's a lot of crap code out there on the internet. If we want to
insist that all the application authors both a) write good code and that
b) understands how FreeBSD does things, well, we can do that, but it's
not going to have much effect.
Probably 75%+ of the application authors neither know nor care that
their code is being run on anything other than Linux. In extreme
cases we've enountered authors who outright refuse to accept our
patches, either due to philosophical disagreement or just due to the
xtra hassle.

The problem actually was most likely the fact that the functionality
wasn't properly documented or that people didn't thoroughly read or
understand the documentation before implementing the feature. If
there's anything that I've learned from cleaning up messes in the past
(to be fair, some which I've created as well), it's that a lot of
incorrect logic is created by misunderstanding things and/or making
false assumptions on how things should work.

To be fair, the usage of _LARGEFILE64_SOURCE IS documented, people just
don't pay enough attention. GNU headers choose to use #ifdef
_LARGEFILE64_SOURCE instead of #if _LARGEFILE64_SOURCE == 1, to be
pedantic, the latter form is correct. [1]

Post by Garrett Cooper
But yes, zlib is buggy w.r.t. the item Xin Li mentioned and needed to
be fixed. Too many folks try to resolve application porting issues by

If we use Large File Summit's documentation, it's not at all zlib's issue.

Post by Garrett Cooper
#ifndef SOME_LARGELY_USED_CONSTANT_INTRODUCED_IN_VERSION_B
/* #define a constant or typedef a feature */
#endif
This generally quasi-works in versions A (assuming the application
runs and the developer upstream did their testing on version A's
software... heh) or version C (typically a Linux) developer decided
that they wanted to change the definition and dashed the consequences
about backwards compatibility in their code. kernel.org sources are
riddled with this kind of `decision making'.

Applications aiming to be portable should not define _LARGEFILE64_SOURCE
at all, on any *BSD platforms.

And, if they really want to do that, they should either use
- -D_LARGEFILE64_SOURCE or #define _LARGEFILE64_SOURCE 1 in the first place.

No, it's not zlib's fault. We may workaround the application bug on
FreeBSD by removing all these checks in zlib.h and zconf.h, as they
doesn't affect FreeBSD's base system's headers at all, HOWEVER, it's
still the application's bug and should be fixed upstream.

[1] http://www.unix.org/version2/whatsnew/lfs20mar.html

Cheers,
- --
Xin LI <***@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die

[Dag-Erling Smørgrav]

Post by Xin LI
Applications aiming to be portable should not define _LARGEFILE64_SOURCE
at all, on any *BSD platforms.

nor on Linux.

DES