incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Diduck" <lancedid...@nyc.rr.com>
Subject RE: Cygwin build
Date Tue, 13 Sep 2005 00:27:06 GMT


<< Could you please look into it and open a bug for this with the details?>>
Sure. I'll just open bugs for all Cygwin issues (there are more) Usually I
wont open a bug report for something that the docs don't claim support for,
but JIRA is more then just for bug reports? 

Cygwin is very interesting --  NT originally had hooks for a POSIX1.1
compatibility layer that was never built. But Cygwin (other than the
filesystem issues) looks like what that layer may have looked like. With a
few tweaks it looks like the configuration system could support builds for
any compiler using the native or POSIX subsystems. 

Lance

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Sunday, September 11, 2005 8:26 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Cygwin build

Lance Diduck wrote:
> Notes on  Cygwin build __CYGWIN__ using gcc 3.4.4 BUILDTYPE=11s default
> modes 

Thanks for the feedback!

> 
> 1. <unistd.h> defines _SC_PAGESIZE and not _SC_PAGE_SIZE,  I put a
> define in
> memattr.cpp to get to compile, but I'm sure that's probably not the best
> place

That might be okay. AFAICS, _SC_PAGESIZE predates _SC_PAGE_SIZE and
while POSIX requires both to be #defined not all implementations are
up to date. I created stdcxx-19 for this:
http://issues.apache.org/jira/browse/STDCXX-19

> 
> 2. config.h file should have a entry for _RWSTD_NO_MADVISE I modified
> the
> build's config file directly, I'm not sre how to modify the things that
> generate the config.h in the first place.

There's a script that checks for the presence of function declarations
in system headers:
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/etc/config/src/libc_d
ecl.sh
It will need to be modified to check for madvise(). I created stdcxx-20:
http://issues.apache.org/jira/browse/STDCXX-20

> 
[...]
> 4. gas did not like the .type statements in atomic-i86.s so I commented
> them
> out for now. Some weird error claiming there was 'junk' on the line
> starting
> with the underscore. Pulled file up in hex mode, did not see anything
> unusual. Tried wrapping with .def /.endef but that didn't work either.
> Once
> the .S/.s issue is resolved, I'll look at this again.

That would be great! Once you've figured out what the problem is could
you please open a bug with the details?

> 
> User should be advised that catgets package should be installed (for
> gencat)
> which is not something they are likely to have.

Better yet, we should probably gracefully fall back on some alternative
when there's no gencat. Otherwise the std::messages facet won't work
and it won't be possible to customize the what() strings of the standard
exception classes (which would be caught by the test suite).

> 
> Warnings:
> /cygdrive/c/stdcxx7/stdcxx-2005-07-19/src/collate.cpp:502: warning:
> unused
> parameter 'src'
> 
> /cygdrive/c/stdcxx7/stdcxx-2005-07-19/src/collate.cpp:502: warning:
> unused
> parameter 'nchars'

This actually appears to be indicative of a more serious problem than
just a couple of unused variables: AFAICS, __rw_wcsnxfrm() assumes
that wcsnxfrm() exists and doesn't try to work around its absence.
If Cygwin really doesn't define wcsnxfrm() (i.e., if both
_RWSTD_NO_WCSXFRM and _RWSTD_NO_WCSXFRM_IN_LIBC are #defined) we
should probably implement our own transformation. Looking at
collate.cpp, though, I don't see a check for _RWSTD_NO_WCSXFRM_IN_LIBC,
just for the former (which only determines whether function is declared;
the latter tells us if it's also not defined).

Could you please look into it and open a bug for this with the details?

> 
> /cygdrive/c/stdcxx7/stdcxx-2005-07-19/src/wcodecvt.cpp: In function
> `std::codecvt_base::result __rw::__rw_libstd_do_out(const wchar_t*,
> const
> wchar_t*, const wchar_t*&, char*, char*, char*&, int, const
> __rw::__rw_codecvt_t*)':
> 
> /cygdrive/c/stdcxx7/stdcxx-2005-07-19/src/wcodecvt.cpp:840: warning:
> comparison is always true due to limited range of data type
> 
> 

Yes, the condition on line 840 (wchar_t (0xffff) >= *from_next) will
always hold if wchar_t is an unsigned type. We should silence the
warning. I created stdcxx-21 for this:
http://issues.apache.org/jira/browse/STDCXX-21

Martin



Mime
View raw message