bug-autoconf
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]