bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling ncurses-6.1 on OpenBSD


From: Robert Smith
Subject: Re: Compiling ncurses-6.1 on OpenBSD
Date: Sun, 29 Dec 2019 23:41:29 +0100

Dear Thomas,

It's interesting to see some new discussion around this whereas I am attempting 
to build it again.

I was just reviewing some of the correspondence from earlier in the year to see 
if there was anything I could do to get some kind of build working. Even ugly.

Is there a work around available that I can test?

-Robert


> On Dec 28, 2019, at 11:08 PM, Thomas Dickey <address@hidden> 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 address@hidden 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 address@hidden 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
> 
> 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 <address@hidden>
> https://invisible-island.net
> ftp://ftp.invisible-island.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]