Re: gtk-peer compile fixes for gcc-2.95

[Mark Wielaard]

Hi,

On Fri, 2004-04-09 at 17:35, Archie Cobbs wrote:
> Mark Wielaard wrote:
>
> > 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.

Aha! OK, then in the end you will like my patch (even if you don't like
the c compiler flags that I currently use for it). Since the reason I
went through all the trouble was because I noticed the build was broken
for gcc-2.95. What I want to achieve with the new setup is that we
easily find out about such issues even when we use "modern" gcc-3.x. The
-ansi -std=c89 -pedantic setup almost makes sure this is the case,
except for the fact that we need longlong support (so we add
-Wno-long-long) which is also supported with gcc-2.95 and we need access
to "modern" POSIX/GNU/BSD networking/file funtions like ftruncate and
fsync which are available on almost any system we care about (and when
they aren't out auto* setup should make sure the functions that do
depend on those features do work anyway (with less functionality of
course).

The side benefit will be that when we do finally add -Werror we can be
pretty sure that GNU Classpath compiles out of the box with not only
gcc-2.95 and gcc-3.x, but on almost any ISO C 90 compliant environment
(with longlong support and "modern" POSIX/GNU/BSD networking/file c
library methods).

> > 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.

Could you supply a patch for INSTALL that documents this?

Thanks,

Mark

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