Re: [ft-devel] building freetype on z/OS

[Antoine Leca]

annubius hosted at hotmail.com wrote:
> For the most part it's building but I run into an error
> with zconf.h.  Since it includes unistd.h it has the declaration of
> getopt which conflicts with stdio.h.

This is a clear violation of the Posix standard, as <unistd.h> and <stdio.h>
are two standard include files to be provided with your compiler, and they
should interoperate quietly, so you should not get an conflict error just by
including those two files jointly...

However I guess this is not the reason why you made this point (furthermore,
bashing the OS vendor here is not likely to give any fruitful advance.)


> If the #include<unistd.h> in zconf.h is removed for unistd.h then
> all is well.

OK, so what you are really asking/suggesting is to that we
investigate/revise _why_ we are #including <unistd.h> in "zconf.h", ain't
you?

"zconf.h" is one of the three places in Freetype where we do so if I am not
mistaken, the second one being the src/tools/ftrandom/ftrandom.c but since
it is not even protected I assume this ftrandom is an utilitary tool we can
ignore for the moment, and the third one are the Unix+VMS ftsystem.[hc] to
provide memory-mapping, but there I do not expect problems.


The zconf.h source has currently:

#ifdef HAVE_UNISTD_H
#  include <sys/types.h> /* for off_t */
#  include <unistd.h>    /* for SEEK_* and off_t */
#  define z_off_t  off_t
#endif
#ifndef SEEK_SET
#  define SEEK_SET        0       /* Seek from beginning of file.  */
#  define SEEK_CUR        1       /* Seek from current position.  */
#  define SEEK_END        2       /* Set file pointer to EOF plus "offset"
*/
#endif
#ifndef z_off_t
#  define  z_off_t long
#endif

... and it always had since the adding of this module in 2002; so this is
something we inheritated from zlib.

In fact, the current version of zlib have an even more elaborated setup:
#if HAVE_UNISTD_H
#  include <sys/types.h> /* for off_t */
#  include <unistd.h>    /* for SEEK_* and off_t */
#  ifdef VMS
#    include <unixio.h>   /* for off_t */
#  endif
#  define z_off_t off_t
#endif
[ ... rest unchanged... ]


SEEK_* ought to be defined in <stdio.h> at any rate, which would be included
anyway in Freetype (not so sure with raw zlib); so if I trust the comments,
this all boils down to trigger the eventual typedefinition of z_off_t based
on off_t. And off_t is not ANSI C, which explain the strecht.

Posix requires off_t to be defined in both <sys/types.h> and <unistd.h>, and
SEEK_* only in <unistd.h>; I guess Jean-Loup and Mark did put both headers
in order to accomodate the widest audience, including ancient
configurations; we do not have such requirement (beyond ANSI C that is), and
the scene might have evolved somewhat here, so perhaps we can restrict
ourselves to #include just <sys/types.h> (which is less problematic, and
more common as unistd.h too), and drop the unistd.h stuff altogether.

The idea would then be to test about HAVE_SYS_TYPES_H rather than
HAVE_UNISTD_H, or perhaps even directly aiming at finding off_t typedef (can
we?); so it requires high surgery in the autoconfigure stuff, something I am
not able to do in a ten-minute post like this one :-)
If someone (Werner ?) has the free time to test it over the week end, please
do, it'll provide Annubius a speedier solution.

At any rate, comments are most welcome! I am such a newbie at those Unix
intrincacies that I am perhaps on wrong bases...


Furthermore, we should probably add a note somewhere about the VMS test to
get at <unixio.h> (which is probably here to get 64-bit support...)


> I also determined that it had to do due with the
> -D_ALL_SOURCE flag that was used on the xlC compiler.

Well, this means the library went away from the requirement of ANSI
compatibility (for this compiler). Did you build using `configure`, or by
sticking to the "normal" method?

> Is this something that is needed for freetype to
> work successfully?

Officially it should not, provided your compiler strictly conforms to the
ANSI/ISO C standard. Since the above looks like a standard infringement to
me (although of a different standard), my guess is that you are suffering of
the same cause here.


Antoine

[ Courtoisie copy to the OP ]