[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