Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Fri, 01 Sep 2006 18:50 +0200:
Anyway... there are a couple of options. I would be happy to implement
any of these:
- modify configure.in to define _GNU_SOURCE on linux systems. This is
very clean. The only minor downside is that it might allow developers
to accidentally commit code that isn't portable that would have caused a
compile error before.
- change pread/pwrite in dbpf-bstream.c to explicitly be
pread64/pwrite64. The downside is that without _GNU_SOURCE defined we
still have to give our own prototypes for pread64/pwrite64.
- define _GNU_SOURCE only in dbpf-bstream.c. This might be the least
intrusive option.
Actually my header files seem to protect pread and friends under
_USE_UNIX98 (on glibc-2.3.2, 2.3.6, and glibc-2.4 is all I checked).
You can get that by defining a less pervasive set of features than
_GNU_SOURCE, which basically turns on everything. Like
_XOPEN_SOURCE = 500 should be enough.
But, regardless of which defines you prefer, I agree with Murali and
would like to minimize the effect by constraining the define to only
the single source file. I remember being shocked in the past to
find that behavior changed when using _GNU_SOURCE, beyond just
having extra features available. And your argument about
portability is compelling.
On gentoo the man page actually lists _XOPEN_SOURCE 500 as the magic
#define to add when using pread/pwrite, so that was the route that I
tried first. This breaks the pvfs2 build, though- apparently that flag
also turns off some features that we already use in addition to adding
new ones. It may work when limited to specific source files, though.
I'll figure out which of these flags works best when applied as Murali
suggested and come back with a patch.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
