Re: [platform-testers] new snapshot available: sed-4.4.104-290c
Paul Eggert writes on Tue, 27 Mar 2018 18:38:54 -0700:
>> ...
>> > test=${1##*/}
>> >
>> > I would strongly urge removal of such shell extensions.
>>
>> That syntax has been standard ever since POSIX formalized the shell in
>> IEEE Std 1003.2-1992 (I just pulled out my trusty printed copy and
>> checked). It's a bit of a stretch to call it an "extension" 26 years
>> after standardization.
>> ...
I just looked up that standard (page 37) and tried its several
examples with /bin/sh on Solaris 10. To my surprise, some of them
produced errors, and not the output shown in those examples.
I then repeated the experiment with /usr/xpg4/bin/sh, and they
worked as shown in POSIX.
Next, I looked at the manual page for sh:
DESCRIPTION
The /usr/bin/sh utility is a command programming language that executes
commands read from a terminal or a file.
The /usr/xpg4/bin/sh utility is a standards compliant shell. This util-
ity provides all the functionality of ksh(1), except in cases discussed
in ksh(1) where differences in behavior exist.
So, Solaris 10 /bin/sh is not fully in accord with POSIX, and thus
remains the most `primitive' shell that we have to deal with in
practice. I suspect that we'll be running Solaris 10 systems for at
least another five or so years at my site.
I've always found the shell's ${parameterword} expansion
rules hard to remember, and so, instead of
$ x=/one/two/three
$ echo ${x##*/}
three
I normally use
$ basename $x
three
---------------
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Re: sed-4.3 build comments
I've now completed builds of sed-4.3.p2 with CC=clang LDFLAGS=--rtlib=compiler-rt I have 68 builds where that did the trick, and another 12 where the failure rate was low enough to allow sed to be installed (though I did not do those installs). However, I also have 23 builds where the above recipe did not succeed, either because the compiler did not recognize the option, or it could not find the library that it refers to, and that library is indeed missing from the vendor packaging system. What a mess! I'm inclined now to leave my build-all configuration files for clang unchanged, and simply declared that despite all of the effort that has gone into clang, it still is not a mature compiler, sigh --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: sed-4.3 build comments
Paul Eggert writes today about the missing __muloti4() in clang builds on numerous platforms: >> Thanks, this turns out to be LLVM bug 16404, an unfixed bug I wish I'd >> known. I installed the attached patches to Gnulib to stop using >> integer-overflow builtins on Clang, which should work around the LLVM >> bug. In the meantime, on Fedora you can work around the sed problem by >> installing the Clang-related compiler-rt package and by building with >> LDFLAGS=-rtlib=compiler-rt, I looked at the description of that bug at https://llvm.org/bugs/show_bug.cgi?id=16404 and find that I share the annoyance of many of the posters in a compiler's being unable to find its own libraries. Nevertheless, I just started a series of 106 builds of sed-4.3.p2 (containing the patches 0001-dfa-fix-return-typo.patch 0001-localename-tests-port-to-NetBSD-7.patch ) using clang, launched like this: build-all -u clang-all --env LDFLAGS=--rtlib=compiler-rt sed-4.3.p2 Several are still in progress, but of the ones that have completed, it seems that the LDFLAGS value does the trick of getting a successful build. Because I expect to be using clang for builds of many other packages, I'm adding that LDFLAGS settings to the configuration files for build-all for all those on which it solves the problem. Although sed's configure script could check for clang and the 128-bit multiply that triggers the missing function problem, it would seem better to have autoconf handle that, in view of the reticence of the clang developers to repair their clear error. However, getting a new autoconf pushed to developer sites is a huge task, so I'm just going to supply the fix locally for my build-all procedures. --------------- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: minus_zero-related tests fail to compile on ppc with recent gcc
Bruno Haible [EMAIL PROTECTED] asks about my problem report of compiling the expression -LDBL_MIN * LDBL_MIN on Mac OS X PowerPC systems: ... While Nelson Beebe's report says Apple Mac OS X 10.x PowerPC, I could not reproduce any problem on MacOS X 10.3.9.) ... The problem definitely exists, and as I noted, I've seen it in my own code, and had to work around it. I have a later O/S release, and newer compilers: % sw_vers ProductName:Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S165 % system_profiler Hardware: Hardware Overview: Machine Name: Power Mac G4 Machine Model: PowerMac3,6 CPU Type: PowerPC G4 (3.3) Number Of CPUs: 2 CPU Speed: 1.42 GHz L2 Cache (per CPU): 256 KB L3 Cache (per CPU): 2 MB Memory: 2 GB Bus Speed: 167 MHz Boot ROM Version: 4.6.0f1 Serial Number: ... % uname -a Darwin .math.utah.edu 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc PowerMac3,6 Darwin % cat foo.c static long double one = 1.0L * 1.0L; static long double quarter = 0.5L * 0.5L; static long double third = 1.0L / 3.0L; #include float.h long double minus_zero = -LDBL_MIN * LDBL_MIN; % which cc gcc /usr/bin/cc /usr/local/bin/gcc % cc --version powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) ... % cc -c foo.c foo.c:3: error: initializer element is not constant foo.c:5: error: initializer element is not constant % gcc --version gcc (GCC) 4.3.0 20070817 (experimental) ... % gcc -c foo.c foo.c:3: error: initializer element is not constant foo.c:5: error: initializer element is not constant --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: fpending issues on LSB: [sys/types.h does not define size_t]
Paul Eggert [EMAIL PROTECTED] writes about the failure of sys/types.h in the Linux Standards Base to define size_t. ... Nelson H. F. Beebe [EMAIL PROTECTED] writes: This is the same problem as before with size_t being used before it is defined with this compiler. stdio_ext.h is one thing; it's not standardized. But sys/types.h is another. The compiler is seriously broken if sys/types.h does not define size_t. As I recall, the last mainstream POSIX-like operating system that didn't have size_t in sys/types.h was 4.3BSD-Reno (circa 1990), a system so old that we haven't supported it for ages. POSIX has required sys/types.h to define size_t for quite some time. Jim indicated that he'd rather not worry about implementations that are this far out of the mainstream. Can you please fix this with the LSB compiler, or get it fixed? ... Here is the relevant section of POSIX (IEEE Std 1003.1-2001 (Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992) that confirms Paul's statement: ... 12927 NAME 12928 sys/types.h -- data types 12929 SYNOPSIS 12930 #include sys/types.h 12931 DESCRIPTION 12932 The sys/types.h header shall include definitions for at least the following types: ... 12963 size_t Used for sizes of objects. ... Neither ISO C89 nor ISO C99 Standards mention any header files in the sys/*.h location. This lack-of-definition failure is readily exhibited: % cat bug-lsbcc.c #include sys/types.h size_t p; % lsbcc -c bug-lsbcc.c bug-lsbcc.c:2: error: syntax error before p bug-lsbcc.c:2: warning: data definition has no type or storage class I signed up on the LSB discussion list this morning http://lists.freestandards.org/mailman/listinfo/lsb-discuss to see if has been discussed there I have also since done a Web search, which turned up a report of the same problem from 2003-07-18 14:16: http://sourceforge.net/tracker/index.php?func=detailaid=773937group_id=1107atid=101107 Given that three years have passed since that bug report, no bug resolution is recorded, and my LSB compilers are new and dated 2006-05-25, I doubt that another problem report would have any effect. --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
Re: fpending issues on LSB
Paul Eggert asks about the build of m4-1.4.7 with lsbcc on GNU/Linux
IA-32 (Fedora Core 5):
...
Let's see what the bug is first. It could just be an installation messup.
What is the output of this command?
/opt/lsb/bin/lsbcc -E -DHAVE_CONFIG_H -I. -I.. close-stream.c
...
I tried that, and found that when ../config.h contains
#define HAVE_STDIO_EXT_H 1
the preprocessor produces
__BEGIN_DECLS
extern size_t __fbufsize (FILE *__fp) __THROW;
...
__END_DECLS
and the lsbcc compiler chokes on those wrappers.
With gcc, the __BEGIN_DECLS and __END_DECLS macros do not appear in
the preprocessor output. A grep of /usr/include/* shows many uses of
them, with these definitions:
/usr/include/sys/cdefs.h:# define __BEGIN_DECLS extern C {
/usr/include/sys/cdefs.h:# define __BEGIN_DECLS
The cdefs.h file is included by gcc via the path stdio.h -
features.h - cdefs.h.
However, lsbcc has many of its own header files, including stdio.h,
and it never includes features.h, and thus, never gets definitions
of __BEGIN_DECLS and __END_DECLS.
Because of the binary portability promised by the LSB API, I feel that
open source and free software developers should be testing their code
with LSB compilers, such as lsbcc and lsb++. That is why I included
pointers to where they can be found in my problem report. I have
started to use lsbcc in tests of my own packages, but I still have
some that won't build yet in LSB.
The LSB is described in this recent book:
@String{pub-PHPTR = Pren{\-}tice-Hall PTR}
@String{pub-PHPTR:adr = Upper Saddle River, NJ 07458, USA}
@Book{LSBT:2005:BAL,
author = {Core Members of the Linux Standard Base Team},
title =Building applications with the {Linux Standard Base},
publisher =pub-PHPTR,
address = pub-PHPTR:adr,
pages =xxvi + 246,
year = 2005,
ISBN = 0-13-145695-4,
ISBN-13 = 978-0-13-145695-2,
LCCN = QA76.76.O63 B8375 2004,
bibdate = Thu Jun 22 05:22:21 2006,
bibsource =z3950.loc.gov:7090/Voyager,
note = Foreword by Theodore Ts'o. Includes CD-ROM.,
URL = http://www.freestandards.org/; http://www.lanana.org/;
http://www.linuxbase.org/;
http://www.linuxbase.org/test/registered.html;
http://www.phptr.com/title/0131456954;,
acknowledgement = ack-nhfb,
baseteam = Stuart Anderson and Mark Brown and Kevin Caunt and
Marvin Heffler and Andrew Josey and George Kraft IV and
Radhakrishnan Sethuraman and Matt Taggart and Kristin
Thomas and Theodore Ts'o and Mats Wichmann and Chris
Yeoh,
subject = Linux; Operating systems (Computers); Application
software; Development,
}
---
- Nelson H. F. BeebeTel: +1 801 581 5254 -
- University of UtahFAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] -
- 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL
PROTECTED] -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---
Re: vasprintf on DEC
Paul Eggert [EMAIL PROTECTED] writes in response to my comments earlier today about a test failure of m4-1.4.7 that was traced to a deficient snprintf() library function that was added locally because that function is absent from the vendor libraries: ... It looks like I have to go looking again for a better free implementation of snprintf(), sigh... That may be needed for other packages, but as far as I know it shouldn't be needed for gnulib-using packages like GNU M4; it should work fine on hosts that lack snprintf entirely. Could you please try building GNU M4 on your host without using any locally-installed libraries? It's supposed to work. ... I've just created some new config files for my automated build process that drop the specification of the local library for snprintf(), and did builds of m4-1.4.7 with both cc and with gcc; all tests were successful, and I've installed the cc build. It is nice that m4 is able to adapt to a missing snprintf() (my own packages do this too, by falling back to the unsafe sprintf()). --- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: [EMAIL PROTECTED] - - 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL PROTECTED] - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - ---
