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

[Gerrit P. Haase]

Grzegorz B. Prokopski wrote:
> Hi Gerrit, Hi Peter,
> 
> I looked at the patches to screen what's really needed.
> 
> * SableVM
> 
> IIUC the "foreign" was used only because of libffi being 'included' into
> sources which, as discussed earlier, we can't accept.  BTW.  Some claim
> (I have not verified it) that you need to set this flag in the toplevel
> dir only.

If you use autoreconf --force --install the INSTALL file will be
overwritten, if you're GNU, then rename the INSTALL file, if you want to
keep it, then use foreign;)


> The only diff not related to inclusion of libffi was this:
> --- sablevm-1.1.6-orig/src/sablevm/sablevm.c
> +++ sablevm-1.1.6/src/sablevm/sablevm.c
> @@ -972,7 +972,11 @@
>  #define ARG_COPYRIGHT 11
>  #define ARG_NO_COPYRIGHT 12
>  
> +#ifndef __CYGWIN__
>    static const struct poptOption options[] =   /* description of
> command line options */
> +#else /* __CYGWIN__ */
> +  static struct poptOption options[] = /* description of command line
> options */
> +#endif /* __CYGWIN__ */
>    {
>      {"classpath", 'c', POPT_ARG_STRING, &argument, ARG_CLASS_PATH, "set
> class path", "\"PATH\""},
>      {"property", 'p', POPT_ARG_STRING, &argument, ARG_PROPERTY, "set
> system property", "\"NAME=VALUE\""},
> 
> 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.

> * 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. But why make this conditionally, it doesn't hurt if you use it
elswhere too.

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

It is only in this dircetory a problem and it is only the -ansi flag.
But I saw that it compiles ok, I have classpath 0.11 ready here too, it 
is all the same there, just remove -ansi for Cygwin globally.

> You asked:
> 
>>Is tzname and timezone not ANSI?  Why is it used in sablevm then?  Or
>>is the Cygwin time.h wrong about this?
> 
> 
> If it's any indication of anything - we haven't hit this problem on any
> other platform (i.e. *BSD), so maybe there's some common sense that
> these things should be made available even when -ansi is required?

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.


> But I am fine with removing -ansi for Cygwin.

Do so.

> You also said:
> 
>>And one more, I needed to cast timezone to an int to get it compiled
>>on Cygwin, here is defined timezone as time_t.
> 
> 
> 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.

I changed it as usual, because the -ansi it doesn't compile, after the
change it still doesn't compile, until I found the reason was -ansi I
didn't remember that the cast wasn't actually needed.


BTW, I will be on a business trip for the next week and cannot reply all 
my mail,

Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/