Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Bob Friesenhahn <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.bugs
Message-ID <[email protected]>
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
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.