>> I looked into the autoconf info files, section 'Limitations of
>> usual tools', and 'cp -l' wasn't explictly mentioned,
>
> Although tt's expecting a bit much for the Autoconf manual to say
> every option that *isn't* portable, as there are so many (and they
> proliferate), the manual could
Thanks to all who have answered!
>> I thought ln || ln -s was the standard
>> recipe here
>
> Yes, "cp -l" isn't required by POSIX and is not portable in
> general. For example, on AIX 7.1:
>
> $ cp -l a b
> cp: Not a recognized flag: l
> Usage: cp [-fhipHILPU][-d|-e] [-r|-R]
Folks,
I'm shocked to read in
https://apple.stackexchange.com/questions/464706/why-do-i-get-bad-file-descriptor-when-copying-using-hardlink-flag
that `cp -l` fails for recent macOS versions – a LilyPond user just
confirmed that, too...
What do you recommend to test for and/or to
>> it seems to me that the advice, while useful for autoconf, is very
>> outdated.
>
> Thanks, I installed the attached.
Thanks, too, for the quickly fix and reply!
Werner
The autoconf info pages say
‘dirname’
Not all hosts have a working ‘dirname’, and you should instead
use ‘AS_DIRNAME’ (*note Programming in M4sh::). [...]
Looking into the git repository log it seems this remark is ld,
essentially written before 1996. I now wonder whether
Take any `configure` script and move it to another directory. For
example, executing the script from Emacs gives
```
configure: error: cannot find sources (src/lisp.h) in . or ..
```
which is ok. However, and I consider this a bug, you get exactly the
same error message if you say
Hello Zack,
thanks for the analysis.
>> [autoconf 6d38e9fa2b]
>> [clang 9.0.1]
>> [https://github.com/libarchive/libarchive.git]
>>
>> fails as below.
> ...
>> checking whether C compiler accepts -Wall... yes
>> checking whether C compiler accepts -Wformat... yes
>> checking whether C
[for completeness I send this bug report to bug-autoconf, too]
[autoconf 6d38e9fa2b]
[clang 9.0.1]
[https://github.com/libarchive/libarchive.git]
Running
autoreconf -fvim
in libarchive's git repository, then executing
CC=clang ./configure
fails as below. I had to use autoconf version
It's a problem related to the groff source code, and it's not
something Autoconf can fix.
:-)
The attached patch might fix it. I haven't tested this patch, as I
stopped using csh over 35 years ago and never want to go back. I
think groff would be better off if it didn't worry about csh
Ultimately, it is partisan nonsense that the only file system that
can be agreed on is FAT, but that is the reality.
There really are many, many more elegant solutions than sharing
files using FAT! [...]
Note, however, that failure of FAT *is not obvious* for the casual
user! You have to
Folks,
after a few hours of debugging I've discovered that either MinGW awk
3.1.7 or MinGW autoconf 2.68's awk script as used in `config.status'
(to convert `foo.h.in' into `foo.h') has problems with CRLF: Only if
the original input file has Unix line endings, the script runs
successfully!
Yes, MSYS is set to use LF line endings.
OK. In other words, it is a problem of the awk script in
`config.status' which doesn't anticipate the CRLF case within a Unix
line ending environment...
And indeed, if I read the correctly correctly, the $ac_cs_awk_cr stuff
or something similar is
I've received the following bug report from Eli:
I've built Groff 1.21 on MS-Windows using the MinGW tools, and hit a
small snag when installing the result. The `install' target in the
top-level Makefile ends with this command
$(LN_S) $(version)$(revision) current
Since
Sometimes indirect expansion helps a lot in writing shell scripts. Is
`${!foo}' portable or an invention of Bash? Perhaps it makes sense to
mention this in the autoconf info file.
Werner
Sometimes indirect expansion helps a lot in writing shell scripts.
Is `${!foo}' portable or an invention of Bash?
it's specific to bash
Thanks.
Perhaps it makes sense to mention this in the autoconf info file.
maybe, but where would you stop?
You are right. Maybe a bad idea.
I agree. Can you retry with current git Autoconf (i.e., build and
install that somewhere, and run its autoreconf -vif on groff)?
I postpone this since...
If it doesn't work either, then I guess it would be interesting to see
sh -x ./configure
output for a small example configure
Folks,
please have a look at the two config.status files. One has been
created on my GNU/Linux box, the other one on MS-Windows:
uname -m = i1586
uname -r = 4.2/5.1
uname -s = UWIN-XP
uname -v = 2600
while the configure script runs successfully on both boxes, executing
config.status
What about adding a test to find out the extension of (static)
libraries? Having a LIBEXT variable would be quite helpful.
[...] you can alternatively use the gnulib module havelib (which
will use the logic in the config.rpath file to set libext).
This looks very promising, thanks! How
6½ years ago I've asked this:
What about adding a test to find out the extension of (static)
libraries? Having a LIBEXT variable would be quite helpful.
I've never got a response :-)
Werner
I wonder whether this is a BSD sed bug or whether I'm doing
something wrong.
GNU sed recognizes `\+' as shorthand for `\{1,\}', but POSIX leaves
its meaning undefined. I suspect BSD sed treats it like literal
`+'.
Other people already pointed that out to me. Thanks for your answer.
I suggest to add that `\?', `\+', and `\|' should not be used in sed
expressions because other sed implementations don't interpret those
entities specially. Inspite of marked as GNU extensions in sed.info,
it is easy to miss that.
Werner
21 matches
Mail list logo
