* Roger Leigh:
> I would propose to add:
>
> AC_PROG_CXX_STDCXX
> AC_PROG_CXX_CXX98
> AC_PROG_CXX_CXXTR1 [CXX98 with additional checks for TR1 headers]
> AC_PROG_CXX_CXX11
>
> With behaviour the same as the existing C macros.
This would be unwise because picking the most recent
compiler-supported
* Andrew W. Nosenko:
> ABI break by gcc-4.7.0 and 4.7.1 in c++11 mode was a bug (or
> misfeature, call it as you want). Fixed in gcc-4.7.2.
> From http://gcc.gnu.org/gcc-4.7/changes.html :
I've seen similar issues with GCC 4.7.2. I thought that this was
expected, so I didn't report it as a bug.
* Florian Weimer:
> * Andrew W. Nosenko:
>
>> ABI break by gcc-4.7.0 and 4.7.1 in c++11 mode was a bug (or
>> misfeature, call it as you want). Fixed in gcc-4.7.2.
>> From http://gcc.gnu.org/gcc-4.7/changes.html :
>
> I've seen similar issues with GCC 4.7.2.
* Andrew W. Nosenko:
>> I've since checked, and it was was with 4.7.1.
>>
>> Linking C++98 and C++11 code together is still officially unsupported,
>> even if it is supposed to work if you just use libstdc++. So I think
>> it's wrong to automatically default to C++11 when available.
>
> Why?
Bec
On 07/07/2016 10:15 PM, Peter Crady wrote:
This may be a stupid question but is there a good way to run autoconf in a
chrooted environment? From what I can tell the AS_UNAME function calls uname
which gets information about the base kernel that is installed and not the
kernel that is installed
On 09/01/2016 06:37 AM, Nick Bowler wrote:
It seems that the simplest short term solution is to just not use
-Werror when building packages. Other than the warning, the header
detection worked, and the test is behaving as documented, right?
-Werror does not work because warnings from autoconf
On 09/01/2016 04:27 AM, Zack Weinberg wrote:
glibc 2.25 is going to deprecate the definition of 'major', 'minor',
and 'makedev' by sys/types.h; see
https://sourceware.org/bugzilla/show_bug.cgi?id=19239 for rationale.
(It was found to be impractical to remove sys/types.h from stdlib.h.)
Unfortuna
* Ralf Wildenhues:
> or maybe use the setarch tool to set personality (I do not even know how
> portable/available this is -- it exists in RedHat Fedora), it may break,
> e.g. because of the __x86_64__ preprocessor define.
This is a bug. Debian only defines __x86_64__ when -m64 is given on
the c
* Bob Proulx:
> 2. User installs amd64 (aka x86-64) kernel. /usr/bin/ is x86 but can
>now run amd64 binaries too. So now the userland is a multiarch
>userland.
It's also possible to run an AMD64 kernel, but do not install any
AMD64 libraries. Technically, the system might be able to ru
* Paul Eggert:
>> Can I assume that any shell on a system, which has shared libraries,
>> understands `${foo:+bar}' and `${foo:-bar}' correctly, even if bar
>> happens to be `:'?
>
> Ultrix had shared libraries, I think;
Are you sure? When I worked with Ultrix, you couldn't create them
yourself.
I would like to define macros containing the standard paths, like this:
#define BINDIR "@bindir@"
It does not work due to this code in lib/autoconf/general.m4 (which
appears to be predate DESTDIR support):
# Installation directory options.
# These are left unexpanded so users can "make install e
* Michael Orlitzky:
> On 6/5/20 6:57 AM, Florian Weimer wrote:
>> I would like to define macros containing the standard paths, like this:
>>
>> #define BINDIR "@bindir@"
>>
>> It does not work due to this code in lib/autoconf/general.m4 (whi
* Nick Bowler:
>> It would like to get config.status expansion going, among other things.
>> It's nice to consolidate these things in a single place, and avoid
>> scattering such constructs and several places.
>>
>> What do you think about this?
>
> Autoconf is to be used as part of build systems
* Nick Bowler:
> On 05/06/2020, Florian Weimer wrote:
>> * Nick Bowler:
>>
>>>> It would like to get config.status expansion going, among other things.
>>>> It's nice to consolidate these things in a single place, and avoid
>>>> scatteri
* Perry Hutchison:
> Florian Weimer wrote:
>
>> I'm not convinced that this covers that particular corner case (build
>> at install time using a prefix setting that is different from configure
>> time).
>
> Can you describe a use case for this? It seems very
* Perry Hutchison:
> That being the case, what would be the use of capturing -- into a C
> header file, which is only used when building -- a variable setting
> passed to "make install"?
See the start of the thread. Assuming one has to hard-code installation
locations (let's not get into a debat
Previous thread about essentially the same issue:
From: Florian Weimer
Subject: Using @bindir@ etc. in C headers
To: autoconf@gnu.org
Date: Fri, 05 Jun 2020 12:57:48 +0200
Message-ID: <87ftb9u6dv@oldenburg2.str.redhat.com>
I must say the current approach is a bit painful.
Thanks,
F
* Zack Weinberg via Gcc:
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language fe
* Rich Felker:
> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were intend
* Sam James:
> In Gentoo, we've been planning out what we should do for time64 on
> glibc [0] and concluded that we need some support in glibc for a newer
> option. I'll outline why below.
>
> Proposal: glibc gains two new build-time configure options:
> * --enable-hard-time64
> * --enable-hard-lf
* Paul Eggert:
> On 2022-11-11 01:19, Florian Weimer wrote:
>
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>> I thought the gnulib change has been reverted?
>
> I'm not sure where you got that im
* Andreas K. Huettel:
>> >
>> > Proposal: glibc gains two new build-time configure options:
>> > * --enable-hard-time64
>> > * --enable-hard-lfs
>>
>> We should define new target triplets for this if it's really required.
>>
>
> That doesn't really help anyone *but* Debian ...
>
>> We need to su
* Sam James:
>> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>>
>> * Sam James:
>>
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>>
* Adam Sampson via Libc-alpha:
> Florian Weimer via Libc-alpha writes:
>
>> We should define new target triplets for this if it's really required.
>
> If the consensus on this does come down to the definition of new
> architecture triplets, are there any other changes t
* Arsen Arsenović:
> Evening,
>
> Adam Sampson writes:
>> If the consensus on this does come down to the definition of new
>> architecture triplets, are there any other changes that should (or
>> could) be made at the same time, beyond time64 and LFS?
>
> Forwarding a suggestion from Arfrever:
>>
* Paul Eggert:
> On 2022-11-14 04:41, Aaron Ballman wrote:
>> it's generally a problem when autoconf relies on invalid
>> language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be
> careful abou
And fix the header name in the documentation.
Probing first avoids triggering spurious undeclared
function errors. The error is harmless, but is a distraction when
looking at build differences.
This should not impact glibc compatibility because glibc never
provided .
---
lib/autoconf/headers.
* Zack Weinberg:
> On Thu, Nov 24, 2022, at 2:16 AM, Florian Weimer wrote:
>> And fix the header name in the documentation.
>>
>> Probing first avoids triggering spurious undeclared
>> function errors. The error is harmless, but is a distraction when
>> loo
Frederic asked a pointed question about it, and it turns out that is
unnecessary. We don't define makedev under that name in glibc, so
ignoring or not ignoring an implicit function declaration error cannot
change the outcome of an autoconf check. The failure merely moves from
compile stage to lin
The x11vnc configure.ac script contains this:
| if test "x$with_v4l" != "xno"; then
| AC_CHECK_HEADER(linux/videodev.h,
| [AC_DEFINE(HAVE_LINUX_VIDEODEV_H)],,)
| fi
This is the point where all the default header check are inserted, so
when the condition is false, they are not
* Russ Allbery:
> Florian Weimer writes:
>
>> I want to submit this upstream. Is there are some explanation somewhere
>> why it's not permitted to invoke AC_CHECK_HEADER under shell conditional
>> statement? I couldn't find it in the manual.
>
>
* Richard W. M. Jones via Libc-alpha:
> On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
>> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
>> >IMHO if distros really want to deal with this, they need to be able to
>> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuil
* Andreas Schwab via Libc-alpha:
> On Mär 02 2023, Paul Eggert wrote:
>
>> Another thing that's different is that when off_t grew in the 1990s,
>> people said they needed a wider off_t RIGHT NOW, because programs wouldn't
>> work on large inputs otherwise.
>
> That is only true for rather few sele
* Michael Orlitzky:
> On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
>> All:
>>
>> Will the latest version of autoconf work by default when the compiler has
>> these options enabled?:
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>>
>
> I think the two fixes we're
* Zack Weinberg:
> Paul Eggert made some changes back in May that attempt to address this:
> commits 028526149ee804617a302ccef22cc6adbda681b0 and
> 33c26d2700f927432c756ccf7a4fc89403d35b95. Do you have a minimized
> test case for the problem (both the original problem and any remaining
> issues y
* Alan Coopersmith:
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042
This change:
#ifndef __cplusplus
+#if __STDC_VERSION__ >= 199901L
+#include
+#else
typedef enum
{
false = 0,
true
} bool;
+#endif
# define RT_C_DECLS
* Paul Eggert:
> diff --git a/NEWS b/NEWS
> index 20dbc173..4ba8f3fe 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes.
>C11 and later. Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
>to use VLAs if available.
>
> +*** AC_PROG_CXX now pr
* Paul Eggert:
> On 2024-05-27 03:35, Florian Weimer wrote:
>> Does this turn on experimental language modes by default? That's
>> probably not what we want.
>
> What do C++ developers want these days? Autoconf should have a
> reasonable default, and C++11 is sure
We are using AC_TRY_COMMAND in glibc's configure.ac to log executed
commands in config.log
What's the recommended replacement for that?
Thanks,
Florian
I'm writing a library that will require large-file support on 32-bit GNU
platforms (so that off_t and ino_t are 64 bits wide, otherwise data
structure layout would change). What is the canonical way to enforce
this?
I guess it's not a good idea to force applications to include the
config.h file t
Bob Friesenhahn wrote:
> I recommend defining your own equivalents to off_t & ino_t (if needed)
> which are *always* 64 bits wide. Only your library implementation
> uses the system off_t & ino_t definitions and they are not used in
> your public library headers. This way your library has a cons
41 matches
Mail list logo
