Re: Compiling ncurses-6.1 on OpenBSD

2019-12-31 Thread Robert Smith
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

2019-12-29 Thread Thomas Dickey
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

2019-12-28 Thread Jonathan Gray
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   

Re: Compiling ncurses-6.1 on OpenBSD

2019-12-28 Thread guenther
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

2019-12-28 Thread Jonathan Gray
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

2019-12-28 Thread Thomas Dickey
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

2019-12-26 Thread Thomas Dickey
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

2019-12-26 Thread Stuart Henderson
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

2019-12-25 Thread Thomas Dickey
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===lists-long-full=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

2019-08-10 Thread Thomas Dickey
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