This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: gtk-peer compile fixes for gcc-2.95
- From: Archie Cobbs <archie at dellroad dot org>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: Archie Cobbs <archie at dellroad dot org>, tromey at redhat dot com, commit-classpath at gnu dot org, java-patches at gcc dot gnu dot org
- Date: Fri, 9 Apr 2004 10:35:00 -0500 (CDT)
- Subject: Re: gtk-peer compile fixes for gcc-2.95
Mark Wielaard wrote:
> > Haven't tried this patch but am suspicious of it.
>
> Could you try it and report how well it does/doesn't work?
That may take me a while because my machine has gcc 2.95 and all the
wrong versions of autoxxx.
Since _POSIX_SOURCE restricts the available namespace from what it
otherwise would be, why do we need to include it at all?
> > 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).
Then how about making the autotools not add the -D_POSIX_SOURCE flag unless
it detects that there is no need to use any non-POSIX functions. But my
guess is reliably determining this condition could get very tedious.
> 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.
Not sure what you're saying, but please don't break building with gcc-2.95.
> > 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?
It's because of "sinclude $(JAVA_DEPEND)" in lib/Makefile.am. This is
not an automake command so it passes through unmodified. Unfortunately
there's no workaround that I know of (automake doesn't have a generic
include function).
In pratice this is not a major problem, we just have to specify that
gmake is required to build Classpath on non-Linux platforms; lots of
other apps have a similar requirement.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com