Re: Compiling ncurses-6.1 on OpenBSD
Thank you.. Please no haters, but on a development system I was able to mv
/usr/libncurse* /usr/lib/form* /usr/lib-disabled, build and install as normal,
and then replace the libraries, mv /usr/lib-diabled/* /usr/lib
I think your comment some time ago about OpenBSD seeing what it thinks is the
abi version being better and that it prefers using the one in /usr/lib was
correct.
-Robert
> On Dec 30, 2019, at 1:34 AM, Thomas Dickey wrote:
>
> On Sun, Dec 29, 2019 at 11:41:29PM +0100, Robert Smith wrote:
>> 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?
>
> The workaround is to use clang, with the _XOPEN_SOURCE symbol predefined.
>
> I just did a build, modifying my routine build from
>
> build-my-ncurses
>
> to
>
> CPPFLAGS='-D_XOPEN_SOURCE=800' with-clang build-my-ncurses
>
> "with-clang" is a local script:
>
> #!/bin/sh
> # $Id: with-clang,v 1.3 2011/05/21 17:05:49 tom Exp $
> # use clang for compiler and lint
> # xen-fedora12
> export CC=clang
> export CXX=clang++
> export LINT=clang-lint
> exec "$@"
>
> and "build-my-ncurses" is a script that I use to build/install several
> configurations.
>
> The configure script checks if _XOPEN_SOURCE is already defined,
> and skips adding what's requested if overridden.
>
>>
>> -Robert
>>
>>
>>> On Dec 28, 2019, at 11:08 PM, 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 +, 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
>>>
>>> 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
>>> https://invisible-island.net
>>> ftp://ftp.invisible-island.net
>>
>
> --
> Thomas E. Dickey
> https://invisible-island.net
> ftp://ftp.invisible-island.net
Re: Compiling ncurses-6.1 on OpenBSD
On Sun, Dec 29, 2019 at 11:41:29PM +0100, Robert Smith wrote:
> 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?
The workaround is to use clang, with the _XOPEN_SOURCE symbol predefined.
I just did a build, modifying my routine build from
build-my-ncurses
to
CPPFLAGS='-D_XOPEN_SOURCE=800' with-clang build-my-ncurses
"with-clang" is a local script:
#!/bin/sh
# $Id: with-clang,v 1.3 2011/05/21 17:05:49 tom Exp $
# use clang for compiler and lint
# xen-fedora12
export CC=clang
export CXX=clang++
export LINT=clang-lint
exec "$@"
and "build-my-ncurses" is a script that I use to build/install several
configurations.
The configure script checks if _XOPEN_SOURCE is already defined,
and skips adding what's requested if overridden.
>
> -Robert
>
>
> > On Dec 28, 2019, at 11:08 PM, 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 +, 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
> >
> > 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
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
>
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Sat, Dec 28, 2019 at 04:40:54PM -0800, Philip Guenther wrote: > On Sat, 28 Dec 2019, Jonathan Gray wrote: > > 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: > ... > > > 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. > > Thomas's point is that our c++ unconditionally pulls in > and <__locale> and perhaps others > which unconditionally use locale_t, despite locale_t being conditionally > defined. > > So, when did C++ start permitting and/or requiring locale_t to be > provided? > > One or more of these is presumably then true: > a) our C++ headers need #if's to skip all locale_t stuff when you select > an environment before locale_t was added > b) our header needs to broaden its conditional to go ahead and > provide locale_t (and the functions?) when in a C++ environment that > should have them It would appear that locale_t is not part of a C++ standard but libc++ assumes it exists and has fallbacks if it doesn't. Index: __bsd_locale_fallbacks.h === RCS file: /cvs/src/lib/libcxx/include/__bsd_locale_fallbacks.h,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 __bsd_locale_fallbacks.h --- __bsd_locale_fallbacks.h4 Feb 2019 16:55:45 - 1.1.1.3 +++ __bsd_locale_fallbacks.h29 Dec 2019 02:46:31 - @@ -45,6 +45,7 @@ int __libcpp_wctob_l(wint_t __c, locale_ return wctob(__c); } +#if __POSIX_VISIBLE >= 200809 inline _LIBCPP_INLINE_VISIBILITY size_t __libcpp_wcsnrtombs_l(char *__dest, const wchar_t **__src, size_t __nwc, size_t __len, mbstate_t *__ps, locale_t __l) @@ -52,6 +53,7 @@ size_t __libcpp_wcsnrtombs_l(char *__des __libcpp_locale_guard __current(__l); return wcsnrtombs(__dest, __src, __nwc, __len, __ps); } +#endif inline _LIBCPP_INLINE_VISIBILITY size_t __libcpp_wcrtomb_l(char *__s, wchar_t __wc, mbstate_t *__ps, locale_t __l) @@ -60,6 +62,7 @@ size_t __libcpp_wcrtomb_l(char *__s, wch return wcrtomb(__s, __wc, __ps); } +#if __POSIX_VISIBLE >= 200809 inline _LIBCPP_INLINE_VISIBILITY size_t __libcpp_mbsnrtowcs_l(wchar_t * __dest, const char **__src, size_t __nms, size_t __len, mbstate_t *__ps, locale_t __l) @@ -67,6 +70,7 @@ size_t __libcpp_mbsnrtowcs_l(wchar_t * _ __libcpp_locale_guard __current(__l); return mbsnrtowcs(__dest, __src, __nms, __len, __ps); } +#endif inline _LIBCPP_INLINE_VISIBILITY size_t __libcpp_mbrtowc_l(wchar_t *__pwc, const char *__s, size_t __n, Index: __locale === RCS file: /cvs/src/lib/libcxx/include/__locale,v retrieving revision 1.5 diff -u -p -r1.5 __locale --- __locale17 Jun 2019 22:28:51 - 1.5 +++ __locale29 Dec 2019 02:01:06 - @@ -28,8 +28,10 @@ #elif defined(__sun__) # include # include -#elif defined(_NEWLIB_VERSION) || defined(__OpenBSD__) +#elif defined(_NEWLIB_VERSION) # include +#elif defined(__OpenBSD__) +# include #elif (defined(__APPLE__) || defined(__FreeBSD__) \ || defined(__EMSCRIPTEN__) || defined(__IBMCPP__)) # include Index: support/newlib/xlocale.h === RCS file: /cvs/src/lib/libcxx/include/support/newlib/xlocale.h,v retrieving revision 1.5 diff -u -p -r1.5 xlocale.h --- support/newlib/xlocale.h4 Feb 2019 17:04:36 - 1.5 +++ support/newlib/xlocale.h29 Dec 2019 02:51:50 - @@ -10,20 +10,18 @@ #ifndef _LIBCPP_SUPPORT_NEWLIB_XLOCALE_H #define _LIBCPP_SUPPORT_NEWLIB_XLOCALE_H -#if defined(_NEWLIB_VERSION) || defined(__OpenBSD__) +#if defined(_NEWLIB_VERSION) #include #include #include #include -#if !defined(__OpenBSD__) #if !defined(__NEWLIB__) || __NEWLIB__ < 2 || \ __NEWLIB__ == 2 && __NEWLIB_MINOR__ < 5 #include #include -#endif -#endif #include +#endif #endif // _NEWLIB_VERSION Index: support/openbsd/xlocale.h === RCS file: support/openbsd/xlocale.h diff -N support/openbsd/xlocale.h --- /dev/null 1
Re: Compiling ncurses-6.1 on OpenBSD
On Sat, 28 Dec 2019, Jonathan Gray wrote: > 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: ... > > 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. Thomas's point is that our c++ unconditionally pulls in and <__locale> and perhaps others which unconditionally use locale_t, despite locale_t being conditionally defined. So, when did C++ start permitting and/or requiring locale_t to be provided? One or more of these is presumably then true: a) our C++ headers need #if's to skip all locale_t stuff when you select an environment before locale_t was added b) our header needs to broaden its conditional to go ahead and provide locale_t (and the functions?) when in a C++ environment that should have them Philip Guenther
Re: Compiling ncurses-6.1 on OpenBSD
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 +, 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
> https://invisible-island.net
> ftp://ftp.invisible-island.net
Re: Compiling ncurses-6.1 on OpenBSD
On Thu, Dec 26, 2019 at 05:12:56PM -0500, Thomas Dickey wrote:
> On Thu, Dec 26, 2019 at 01:13:11PM +, 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
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
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Thu, Dec 26, 2019 at 01:13:11PM +, 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." > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
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 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."
Re: Compiling ncurses-6.1 on OpenBSD
On Wed, Aug 14, 2019 at 04:10:17PM -0400, Thomas Dickey wrote:
> On Wed, Aug 14, 2019 at 12:22:44PM -0500, Robert Smith wrote:
> > Thank you for the hard work on this Thomas. Have we heard anything back
> > from
> > OpenBSD team on this?
>
> nothing. My cc' on the weekend was returned, and I attempted to subscribe
> using the link which the majordomo gave without success.
>
> But visiting
>
> https://lists.openbsd.org/cgi-bin/mj_wwwusr?user=&passw=&func=lists-long-full&extra=bugs
>
> and subscribing there got it to accept it. (today). Then I bounced my
> mail at the mailing list, to see if that would work, but went to find
> an archive - found here
>
> http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-bugs-f183916.html
>
> ...which appears to have my earlier attempt actually succeeded.
>
> (I didn't use sendbug, because my mail routing is a little complicated,
> and I only keep it working on the Debian machines).
>
> > I see progress made on several different parts, but I'm not of any wholistic
> > solution to get this to link correctly.
> >
> > I'm going to give the spec file a shot.
>
> I think that if you added that to the $CFLAGS, it would work (sort of ugly,
> but a workaround)
I noticed that there's an OpenBSD 6.6 from October.
However, this linker defect exists in that version as well.
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.
> > -Robert
> >
> >
> > > On Aug 10, 2019, at 5:19 PM, Thomas Dickey wrote:
> > >
> > > On Mon, Jul 22, 2019 at 10:21:28AM +0900, Robert Smith wrote:
> > >> Dear Thomas, here is my build script for 5.9, when I change the source
> > >> file to 6.1 all it does it duplicate this 5.6 file to a 6.1 file, and I
> > >> have to manually add any tweaks if necessary.
> > >>
> > >> root@h1up:/usr/src/build_system_v2/build_scripts# cat ncurses-5.9_ug
> > >> echo Compiling and Installing ncurses-5.9
> > >
> > > 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.
> > >
> > > I'm looking at this file:
> > > /usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/specs
> > >
> > > which has a line with this information:
> > > %{!static:--eh-frame-hdr} %{!shared:%{!nostdlib:%{!r*:%{!e*:-e
> > > __start%{shared:-shared} %{R*}%{static:-Bstatic}
> > > %{!static:-Bdynamic}%{rdynamic:-export-dynamic}%{assert*}
> > > %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}
> > > %{!nostdlib:-L/usr/lib}
> > >
> > > That
> > > %{!nostdlib:-L/usr/lib}
> > >
> > > is the added text. Using ktrace, I could see that the arguments passed
> > > to collect2 (part of the compiler) put a "-L/usr/lib" before any of the
> > > command-line arguments:
> > >
> > > [0] = "/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/collect2"
> > > [1] = "--eh-frame-hdr"
> > > [2] = "-e"
> > > [3] = "__start"
> > > [4] = "-Bdynamic"
> > > [5] = "-dynamic-linker"
> > > [6] = "/usr/libexec/ld.so"
> > > [7] = "-L/usr/lib"
> > > [8] = "-o"
> > > [9] = "clear"
> > > [10] = "/usr/lib/crt0.o"
> > > [11] = "/usr/lib/crtbegin.o"
> > > [12] = "-L../lib"
> > > [13] = "-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1"
> > > [14] = "../obj_s/clear.o"
> > > [15] = "../obj_s/clear_cmd.o"
> > > [16] = "../obj_s/tty_settings.o"
> > > [17] = "-lncurses"
> > > [18] = "-lgcc"
> > > [19] = "-lc"
> > > [20] = "-lgcc"
> > > [21] = "/usr/lib/crtend.o"
> > >
> > > So the loader gets libncurses.so immediately without bothering to pay
> > > any attention to its parameters.
> > >
> > > Just reverting that change doesn't work (won't link), so I can see it's
> > > just half the story. But it's enough to see that it probably wasn't
> > > intended behavior.
> > >
> > > You might want to open a bug report with the OpenBSD developers here:
> > >
> > > http://www.openbsd.org/report.html
> > >
> > > (cc'ing them, anyway).
> > >
> > > According to
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
> > >
> > > you could make a custom "specs" file with a -L../lib before the
> > > -L/usr/lib,
> > > using the "-specs=" flag and pass that in your $CFLAGS
> > >
> > > (In a quick check, that works for me).
> > >
> > > --
> > > Thomas E. Dickey
> > > https://invisible-island.net
> > > ftp://ftp.invisible-island.net
> >
>
> --
> Thomas E. Dickey
> https://invisible-island.net
> ftp://ftp.invisible-island.net
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: Compiling ncurses-6.1 on OpenBSD
On Mon, Jul 22, 2019 at 10:21:28AM +0900, Robert Smith wrote:
> Dear Thomas, here is my build script for 5.9, when I change the source file
> to 6.1 all it does it duplicate this 5.6 file to a 6.1 file, and I have to
> manually add any tweaks if necessary.
>
> root@h1up:/usr/src/build_system_v2/build_scripts# cat ncurses-5.9_ug
> echo Compiling and Installing ncurses-5.9
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.
I'm looking at this file:
/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/specs
which has a line with this information:
%{!static:--eh-frame-hdr} %{!shared:%{!nostdlib:%{!r*:%{!e*:-e
__start%{shared:-shared} %{R*}%{static:-Bstatic}
%{!static:-Bdynamic}%{rdynamic:-export-dynamic}%{assert*}
%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}%{!nostdlib:-L/usr/lib}
That
%{!nostdlib:-L/usr/lib}
is the added text. Using ktrace, I could see that the arguments passed
to collect2 (part of the compiler) put a "-L/usr/lib" before any of the
command-line arguments:
[0] = "/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1/collect2"
[1] = "--eh-frame-hdr"
[2] = "-e"
[3] = "__start"
[4] = "-Bdynamic"
[5] = "-dynamic-linker"
[6] = "/usr/libexec/ld.so"
[7] = "-L/usr/lib"
[8] = "-o"
[9] = "clear"
[10] = "/usr/lib/crt0.o"
[11] = "/usr/lib/crtbegin.o"
[12] = "-L../lib"
[13] = "-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.5/4.2.1"
[14] = "../obj_s/clear.o"
[15] = "../obj_s/clear_cmd.o"
[16] = "../obj_s/tty_settings.o"
[17] = "-lncurses"
[18] = "-lgcc"
[19] = "-lc"
[20] = "-lgcc"
[21] = "/usr/lib/crtend.o"
So the loader gets libncurses.so immediately without bothering to pay
any attention to its parameters.
Just reverting that change doesn't work (won't link), so I can see it's
just half the story. But it's enough to see that it probably wasn't
intended behavior.
You might want to open a bug report with the OpenBSD developers here:
http://www.openbsd.org/report.html
(cc'ing them, anyway).
According to
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
you could make a custom "specs" file with a -L../lib before the -L/usr/lib,
using the "-specs=" flag and pass that in your $CFLAGS
(In a quick check, that works for me).
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
