[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS
From: |
Bob Friesenhahn |
Subject: |
Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh |
Date: |
Fri, 25 Dec 2020 08:11:32 -0600 (CST) |
User-agent: |
Alpine 2.20 (GSO 67 2015-01-07) |
On Fri, 25 Dec 2020, Bruno Haible wrote:
Bob Friesenhahn wrote:
I would recommend to just document the problem and workaround in two places:
1) in the OmniOS community,
2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for
GNU people.
That seems reasonable.
OK, what can I write in (2)? Are the following values right?
solaris11omnios-x86-32-gcc CC="gcc -m32 -O2" CXX="g++ -m32 -O2"
CONFIG_SHELL=/bin/bash
solaris11omnios-x86-64-gcc CC="gcc -m64 -O2" CXX="g++ -m64 -O2"
CONFIG_SHELL=/bin/bash
Just plain 'gcc' is sure to work, and yes, your examples should work
on Intel/AMD_64 targets. For Illumos variants, there are multiple
ways to expose gcc (and clang). With OpenIndiana, it seems that 'gcc'
is a symbolic link to a 'gcc' in a /usr/gcc/7 directory tree which
contains a normal GCC installation footprint (e.g. contains
i386-pc-solaris2.11-gcc-7.5.0).
It is best not to focus specifically on OmniOS since the shell comes
from the Illumos parent and so OpenIndiana and other distributions
which derive from Illumos are likely to have this bug.
I didn't purposely diminish OmniOS. But Zack asked for our thoughts on
how to deal with a bug. As usual, "add workaround to the code" and
"add workaround to the documentation" are viable alternatives. In my
opinion, the size of the user base does play a role. If every other
circumstances were equal, I would spend more time on a workaround for
FreeBSD than on a workaround for OmniOS. And I would recommend the same
thing to Zack.
Unfortunately, FreeBSD popularity seems to be waning recently in spite
of being better than ever before. I am on both FreeBSD and Illumos
related lists and have noticed a considerable diminishment in FreeBSD
emails. FreeBSD users are lamenting the loss of popularity and
support.
Monopolies are harmful in general, and definitely harmful to free
software so it is good to support less popular systems in order to
protect the freedom of expression in development of free software and
in order to not limit competing inventions. In the GNU/Linux space,
there are relatively few individuals and some large corporations
making the key decisions.
How to estimate the size of the user base of an OS? Like you, I dislike
Google. But their trends site is a way to do such estimations, and I know
of no other or better way. (For packages, but not for OSes, there is also
the Debian popularity contest.)
It seems to estimate popularity for what people are searching for and
wanting to read or write about. This is not the same as actual usage.
Some software which appears on almost all systems is remarkably
unpopular. The older and more entrenched the software is, the less
interested people are in reading about it. Another factor is how
people obtain information and this varies based on the software. For
some software, the information is readily available locally (due to
excellent bundled documentation) and for other software it is most
common to enter a Google search.
Indeed, CLISP failed to achieve world domination. JavaScript did, instead.
I failed. ;-)
I did not enter the query, but I expect that Google would indicate
that Rust is incredibly popular, although there is actually hardly any
usage yet and it is unlikely there ever will be due to being
restrictive and difficult to use.
CLISP may have failed to achieve world domination but it has not
failed.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, (continued)
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, Bob Friesenhahn, 2020/12/23
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, Bob Friesenhahn, 2020/12/23
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, Zack Weinberg, 2020/12/23
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, Bob Friesenhahn, 2020/12/23
- [sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS, Zack Weinberg, 2020/12/24
- [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh, Zack Weinberg, 2020/12/24
- [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh, Bruno Haible, 2020/12/24
- [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh, Bob Friesenhahn, 2020/12/24
- Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh, Bob Friesenhahn, 2020/12/24
- Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh, Bruno Haible, 2020/12/24
- Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh,
Bob Friesenhahn <=