commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gtk-peer compile fixes for gcc-2.95


From: Mark Wielaard
Subject: Re: gtk-peer compile fixes for gcc-2.95
Date: Fri, 09 Apr 2004 17:21:18 +0200

Hi Archie,

On Fri, 2004-04-09 at 16:53, Archie Cobbs wrote:
> > This gives us ISO C90 pedantic ansi, but with longlong (jlong) support
> > and modern POSIX and BSD C library functions/prototypes (we actually
> > need fsync and ftruncate for example which aren't in ISO C 90 so the
> > glibc headers wouldn't define it with the above two defines).
> 
> Haven't tried this patch but am suspicious of it.

Could you try it and report how well it does/doesn't work?

> _BSD_SOURCE is a Linux-ism and means nothing on FreeBSD. However,
> _POSIX_SOURCE on FreeBSD (as it should) will have the effect of
> removing all non-POSIX declarations from the #include'd namespace.
>
> Surely Classpath uses some non-POSIX functions (otherwise why would
> _BSD_SOURCE be required on Linux?), so hopes are dim on this working.

Thanks for the info, I came up with the above settings by trial and
error. I hope they are as strict as needeed. There should indeed not be
any non-POSIX-isms in the current source except when the build can
detect that it is save to use in the build environment (that is why we
use the autotools). Enabling the compiler checks (only gcc at the
moment, but that is what most people use) should help us catch such
things. I would love to hear better suggestions on gcc compiler flags
that help us with this.

My main concern was that some older GNU/Linux and BSDs distributions are
still stuck on gcc-2.95 which doesn't accept all constructs that gcc-3.x
does. The AM_CLFAGS that are set when gcc is detected should make use
aware when this happens. When all warnings are cleaned up we can even
add -Werror to make sure no new suspicious code sneaks in.

> I'd prefer to not have Linux specific code in Classpath if we can
> help it (the biggest offender is that Classpath won't even build
> unless "make" is really "gmake").

I thought automake would take care of making sure the correct make was
available/selected. If the build doesn't use gmake when it should could
you provide a patch that makes it do that? And/Or make our autotools
setup better so it doesn't depend on gmake if not necessary?

Thanks,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]