I've been trying to fill in as many gaps as possible in the config.sub
test suite (and finding a whole bunch of actual bugs in the process).
I have a short list of inputs where the actual code to handle them is
incomplete or broken, there's nothing in config.guess to use as a clue,
and I don't know
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply contin
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that as
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>> also
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
>
> I don't have anyth
Florian Weimer writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately won'
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compiler to call it with no
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using gcc'
On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this thread
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 features by
default in a near-future
On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> th
12 matches
Mail list logo
