> +*** 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__ is
> 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
> 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 top
[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 ex
> - 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 to
> 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, lib
>> 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 ha
>>> 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 so
>> 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
>> 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++ CPPFLAGS="-D__STDC
>> 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
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
> #ifdef UINT64_MAX
> typedef uint64_t TA_ULongLong;
> #else
> # error "No unsigned 64bit wide data type found."
> #endif
>
>
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
/* make `stdint.h' define `uint
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
Au
> 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
__
> However, I do wonder why GNU tar can't be smart enough to figure out
> what you meant when untarring with -z? I get why we need -j and -J
> for creating archives, but when unpacking them, what's wrong with
> using magic numbers to detect the compression format?
On Mac OS X Lion, this actually
> On 03/02/12 14:08, Keith Marshall wrote:
>> I'll dig out the MINGW_AC... "standard" macro I use, and post it later.
>
> Found it, quicker than I expected; attached.
Thanks! Shall I take care of __WIN32__also to be as much generic as
possible? According to
http://sourceforge.net/apps/media
Thanks for the answers, Vincent and Peter!
> You do as you do with whatever else you are requiring. Check if
> #include 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 archive, bu
>> 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
Folks,
is there an autoconf macro to detect MS Windows?
Werner
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
what we have learned in this thread?
Attached.
Werner
==========
2011-12-07 Werner Lemberg
doc: Mention __STDC_LIMIT_MACROS
* doc/autoconf.texi (Particular Type Checks): We need this
macro for C++ compilati
> 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
___
> 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 bu
>> 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 p
> 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 and checking for HAVE_UINT64_T.
HAVE_UINT64_T is *not* defined in my ...
> C++ compilers do not get these definition from stdint.h
>>#if defined UINT64_MAX || defined uint64_t
>>typedef uint64_t TA_ULongLong;
>>#else
>># error "No unsigned 64bit wide data type found."
>>#endif
>
> stdint.h will not define UINT64_MAX if __cplusplus is defined unless
> __STDC_LIMIT_MACROS is defined before you include it.
>> 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 opt
In my configure.ac file I have
AC_PROG_CC
AC_PROG_CPP
AC_TYPE_UINT64_T
In my C file I have
#include
#if HAVE_STDINT_H
# include
#endif
#if defined UINT64_MAX || defined uint64_t
typedef uint64_t TA_ULongLong;
#else
# error "No unsigned 64bit wide data type found."
[In case you receive this mulitple times, sorry for that.]
In my configure.ac file I have
AC_PROG_CC
AC_PROG_CPP
AC_TYPE_UINT64_T
In my C file I have
#include
#if HAVE_STDINT_H
# include
#endif
#if defined UINT64_MAX || defined uint64_t
typedef uint64_t TA_ULongLong;
In my configure.ac file I have
AC_PROG_CC
AC_PROG_CPP
AC_TYPE_UINT64_T
In my C file I have
#include
#if HAVE_STDINT_H
# include
#endif
#if defined UINT64_MAX || defined uint64_t
typedef uint64_t TA_ULongLong;
#else
# error "No unsigned 64bit wide data type found."
really "mks" that offers a Unix-like environment on top of
>the Win32 kernel.
To which Werner Lemberg replied:
>A documented list of allowed values for config.sub and the
>configuration types recognized by config.guess would be great...
I'll second Werner's comment; I
[No longer Cc'ed to [EMAIL PROTECTED] and [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: merel
[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 prep
33 matches
Mail list logo
