This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]