On Sat, Dec 28, 2019 at 05:08:51PM -0500, Thomas Dickey wrote:
> On Thu, Dec 26, 2019 at 05:12:56PM -0500, Thomas Dickey wrote:
> > On Thu, Dec 26, 2019 at 01:13:11PM +0000, Stuart Henderson wrote:
> > > On 2019/12/25 16:23, Thomas Dickey wrote:
> > > > Since my message to bugs@openbsd.org was ignored,
> > > > I'll have to assume that they're not interested in discussing it,
> > > > and will keep in mind to document it as a pitfall in upcoming releases.
> > > 
> > > The toolchain isn't my area, but I suspect there's little enthusiasm
> > > for fixing a gcc-related problem especially one reported on amd64 - it's
> > > pretty much only still built there so that developers have an easy way
> > > to run it if they need to fix things in the base OS on the non-clang
> > > platforms which many developers don't have direct access to.
> > > 
> > > If the problem remains with /usr/bin/cc (which is clang on
> > > amd64/i386/arm/aarch64/mips64) then it would be useful to include the
> > > full steps to repeat the problem - the script is mentioned but not
> > > included in the bugs@openbsd.org mail.
> > 
> > I took a quick look at the clang (cc) build, but don't see that problem.
> > I haven't investigated the i386 configuration for a while - probably 
> > should...
> > 
> > > > > > > I revisited this, and can see half of the problem, which offers a 
> > > > > > > different
> > > > > > > workaround.  Comparing the specs files for the compiler in 6.2 
> > > > > > > and 6.5,
> > > > > > > I see that someone added a fallback for -L/usr/lib, apparently to 
> > > > > > > compensate
> > > > > > > for some other change.
> > > 
> > > The commit log was "Pass -L/usr/lib to the linker in preparation for
> > > switching to lld, which does not have a default search path."
> > > 
> 
> Taking a look at the i386, I see that as you hinted  cc==clang.
> 
> That's okay.  But there's an error in OpenBSD's header files which
> I'll have to work around for the time being.  It would be nice
> if someone fixed it:
> 
> /usr/include/ctype.h has
> 
> #if __POSIX_VISIBLE >= 200809
> #ifndef _LOCALE_T_DEFINED_
> #define _LOCALE_T_DEFINED_
> typedef void    *locale_t;
> #endif
> #endif
> 
> and (since ncurses uses no feature newer than this) my default build
> does this:
> 
>       -D_BSD_SOURCE -D_XOPEN_SOURCE=600

defining _XOPEN_SOURCE=600 results in __POSIX_VISIBLE 200112
defining _XOPEN_SOURCE=700 results in __POSIX_VISIBLE 200809
when not defining anything you'll get __POSIX_VISIBLE 200809

So if you want it to be visible either don't do any visibility
defines, use _XOPEN_SOURCE=700 or _POSIX_C_SOURCE=200809.

See /usr/include/sys/cdefs.h for details.

> 
> which produces this error:
> 
> compiling cursesmain (obj_s)
> In file included from ../c++/cursesmain.cc:39:
> In file included from /usr/include/c++/v1/iostream:38:
> In file included from /usr/include/c++/v1/ios:216:
> In file included from /usr/include/c++/v1/__locale:32:
> In file included from /usr/include/c++/v1/support/newlib/xlocale.h:26:
> /usr/include/c++/v1/support/xlocale/__strtonum_fallback.h:24:64: error: 
> unknown type name 'locale_t'
>                                                 char **endptr, locale_t) {
>                                                                ^
> because the locale_t use from iostream is improperly ifdef'd.
> 
> -- 
> Thomas E. Dickey <dic...@invisible-island.net>
> https://invisible-island.net
> ftp://ftp.invisible-island.net


Reply via email to