Re: SableVM & Cygwin (was: Re: sablevm + windows)

On Sun, 2004-10-17 at 03:28, Gerrit P. Haase wrote:
> Grzegorz B. Prokopski wrote:
> > Why can't this struct be const?  We don't write to it.  Is this because
> > of how .data is handled in DLLs?  This would need some comment in the
> > patch so that next person that looks at this knew why it's there,
> > because it looks strange at the first sight.
> > 
> There is a variable or a pointer in this struct, so it is actually not
> constant since the target of the pointer holds different values, or the
> variable likewise.  This cannot be exported from the DLL.  The reason
> why Cygwin needs this change is that with gcc >= 3.3.3 those 'data' is
> written to .rdata sections in object files and these cannot be exported,
> it is not possible to build working executables when there are used
> variables or pointer to variables in const structs.  Most of the time
> there are these popt things causing problems, it seems that this is the
> usual way to code this, however it is no longer possible to do so on
> Cygwin.

Thanks for explanation, I think it all should go as a comment to this
#ifdef, when it's merged into the mainline.

> > * SableVM Classpath
> > 
> > Could you please handle the -no-undefined in similar way as it's done in
> > SableVM?  When cygwin is detected we set @NO_UNDEFINED@ to -no-undefined
> > We don't want to hardcode it.
> 
> In upcoming releases of classpath the -no-undefined flag will be
> handled.

You talked to Mark?  I couldn't catch him on IRC today.  Anyway, we
should release 1.1.7 before the next release of gnu classpath, so either
we include proper support for Cygwin in 1.1.7 ourselves or wait for
1.1.8.

> But why make this conditionally, it doesn't hurt if you use it
> elswhere too.

Are we sure of that?  When we worked on Cygwin port for the first time
(almost year ago) pretty much in every cygwin .patch I found the
-no-undefined was added conditionally, for Cygwin only.

Can anyone confirm or deny that -no-undefined will not break anything
on any POSIX platform?

> > +# override FLAGS for Cygwin
> > +AM_CFLAGS=-pedantic -Wmissing-declarations -Wmissing-prototypes
> > -Wstrict-prototypes -Wall -Wno-long-long -D_BSD_SOURCE
> > 
> > If you need to change flags, then I think it should be done again in
> > configure when Cygwin is detected.  Don't override, just add
> > conditionally what is needed or disallowed for Cygwin.
> > What actually are the flags that you need to add/remove? (-ansi ?)
> 
> Yes of course, I just changed what was needed to get it compiled so who 
> is interested can see what needs to be done, I don't want to distribute 
> or maintain SableVM as long as nobody pays for it.

Oh, I see.  But then for long term maintenance hardcoding a set of flags
is bad thing to do.  What you want to do is to remove/add what you need
and allow the rest to be changed as the development team wants it.

But I guess I need to hear from Peter what is his balance of hacks vs.
clean solutions in regards to maintaining SableVM in Cygwin.  From my
debian-maintainer experience I must say it's usually much better to work
out a clean solution and forward it upstream (so that it was maintained
there) than to maintain a port-specific hack.  And we really *are* open
to all clean solutions that would make SableVM work out-of-the-box on
Cygwin (or any other platform).

> It is only in this dircetory a problem and it is only the -ansi flag.

And this is *the* important information here.

> I'm in contact with the cygwin developers, however, tzname and timezone 
> / daylight are so called 'extensions' so strictly spoken not ANSI.  The 
> classpath maintainer is aware of that too, he said that it is not really 
> needed to use the -ansi flag, I think he will do s.th. about it.

> > I looked into /usr/include/time.h and I see:
> > 
> > extern __IMPORT time_t _timezone;
> > #define timezone ((long int) _timezone)
> > 
> > So isn't timezone already casted to a long int?  It should not be a
> > problem then, no?  What kind of error do you get while compiling?
> 
> Yes you're right.  But in newer classpath however, it is different,
> there is used _timezone if available and this really needs the cast
> then.

Maybe Mark could explain us why do they need to access _timezone, which
is not supposed to used (i.e. on my Linux there seem to be __timezone)
while there already exist 'timezone' variable that is the one provided
by the standard.

Cheers,

			Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski      <[email protected]>
Debian GNU/Linux           http://www.debian.org
SableVM - LGPL'ed Java VM  http://www.sablevm.org
Why SableVM ?!?            http://sablevm.org/wiki/Features