> +*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined.
> + This ports better to MSVC, which does not support variable length
> + arrays and does not define __STDC__.
Suggestion:
```
*** AC_PROG_CC no longer tests for variable length arrays (VLAs), or
whether __STDC__
>> 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
> My suspicion is that you're running the old, broken version of GNU
> make that Apple ships with its Xcode environment.
Maybe the new GNU make is called 'gmake' on this platform?
Werner
>> 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
> I was recently added as the new maintainer of `libtool' [...]
Excellent news! However, are you aware that you haven't introduced
yourself on the 'libtool' mailing list?
Making you a maintainer must have been a very recent decision, since
on Oct 21st we accidentally discussed exactly that
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
[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 2.69 to create a
`configure` script that could be successfully
> - Run the bundled testsuite (plain ‘make check’ only, not ‘make
>distcheck’) on the following OS and CPU combinations, all of which
>are readily accessible to me: [...]
>
>This list is shorter than I would like, particularly in the OS
>department. I was hoping to get access
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
It seems it's en vogue for libs to ship their own broken
replacement rather than supplying a portable pkgconfig file... the
list is big, but these here are the most often used ones:
pcap-config, pcre-config, freetype-config, apr-1-config,
glib-config, gtk-config, ncursesw5-config,
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
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
I tend to work around these sorts of glitches using Gnulib; its
stdint module fixes the portability problem with
__STDC_LIMIT_MACROS that I know about. Admittedly Gnulib is not
for everybody.
Hehe. I use gnulib, so this is just fine for me.
Will test `stdint' module soon – I've never
Repeating your test verbatim I get the #error message!
How about if you compile with the following command instead?
g++ -D__STDC_LIMIT_MACROS -c t.cc
That fixes the problem on RHEL 6.4, anyway.
It works for me, too.
Will this problem be handled in a forthcoming autoconf release?
Will this problem be handled in a forthcoming autoconf release?
I'm afraid I don't understand the problem yet, as your original
email defined __STDC_LIMIT_MACROS, but now you're saying that
-D__STDC_LIMIT_MACROS fixes the problem.
Indeed, doing
./configure CC=g++
I tend to work around these sorts of glitches using Gnulib; its
stdint module fixes the portability problem with
__STDC_LIMIT_MACROS that I know about. Admittedly Gnulib is not
for everybody.
Hehe. I use gnulib, so this is just fine for me.
Will test `stdint' module soon – I've never
In 2011, there was the following thread started by me:
http://lists.gnu.org/archive/html/autoconf/2011-12/msg2.html
The solution that worked eventually was to put
AC_PROG_CC
AC_PROG_CPP
AC_TYPE_UINT64_T
into my configure.ac file, and
#include config.h
/* make `stdint.h'
Hello Paul!
neither `UINT64_MAX' nor `uint64_t' gets define
That's odd, because UINT64_MAX is defined for me, even for this
much-simpler program:
#include stdint.h
#ifdef UINT64_MAX
typedef uint64_t TA_ULongLong;
#else
# error No unsigned 64bit wide data type found.
#endif
If I
Is anybody aware of automake or autoconf rules to build an OS X
application bundle (and transforming it into a dmg file)?
autoconf-archive doesn't show anything up, and my search with google
wasn't successful...
Werner
___
Autoconf mailing list
Although I understand that autoconf is designed for the portability
and expecting a dictionary of compiler-specific options in there is
out of the scope, I'm interested in the appropriate place to collect
such.
Perhaps
http://www.gnu.org/software/autoconf-archive/
Werner
Folks,
is there an autoconf macro to detect MS Windows?
Werner
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
is there an autoconf macro to detect MS Windows?
Is that a joke? The trouble is, that autoconf requires a shell and
M4, which Windows doesn't provide (only in Cygwin). So MS Windows is
detected when autoconf/configure does not run...
Very witty :-) No, it's not a joke. I don't want to
Thanks for the answers, Vincent and Peter!
You do as you do with whatever else you are requiring. Check if
#include windows.h is there, and check if you can link with some
API of your choice. [...]
I would have expected something like this as a ready-to-run macro in
the autoconf-macro
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
In my configure.ac file I have
AC_PROG_CC
AC_PROG_CPP
AC_TYPE_UINT64_T
In my C file I have
#include config.h
#if HAVE_STDINT_H
# include stdint.h
#endif
#if defined UINT64_MAX || defined uint64_t
typedef uint64_t TA_ULongLong;
#else
# error No unsigned 64bit wide
My main question is: Why does the autoconf test succeeds (which
properly uses g++ for its test according to the config.log file)
but the compilation in my test file fails? A bug? A feature?
Sorry, I'm not sure about that bit. Does config.log show it using
any special compiler options
It's nothing to do with autoconf really, configure correctly finds
uint64_t, your C program then checks for UINT64_MAX or a uint64_t
macro instead of #include config.h and checking for HAVE_UINT64_T.
HAVE_UINT64_T is *not* defined in my config.h...
C++ compilers do not get these definition
I still don't understand the details of the autoconf problem (and I
still think that something is fishy), but defining this macro works
just fine :-)
Clearly, depending on an implementation-dependent macro is not
suitable for portable software.
So please tell me how to solve this properly
If the above guesswork holds,
It doesn't :-)
then I wonder why your project uses C++ file extensions and $CC
(your said it was a C file). It should be either C file extensions
and $CC, or C++ file extensions and $CXX. Or?
As Nelson Beebe has explained to me some time ago, there are a bunch
If you do need the UINT64_MAX etc macros as well as the uint64_t
type then you will have to define __STDC_LIMIT_MACROS.
Yep. I believe this is something I would have never found out without
assistance. Thanks again to all of you!
Werner
___
==
2011-12-07 Werner Lemberg w...@gnu.org
doc: Mention __STDC_LIMIT_MACROS
* doc/autoconf.texi (Particular Type Checks): We need this
macro for C++ compilation.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index d7d2231
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
[No longer Cc'ed to [EMAIL PROTECTED]]
Now, I took some more time to think about it, and here is my
proposal: when $4 is not given (was introduced in 2.50a, did not
exist before, so we are free to do whatever we want with it), just
do what Autoconf always did: merely check it can be
47 matches
Mail list logo
