incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Diduck" <>
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. 


-----Original Message-----
From: Martin Sebor [] 
Sent: Sunday, September 11, 2005 8:26 PM
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:

> 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:
It will need to be modified to check for madvise(). I created 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
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:


View raw message