Possible regression in AC_FC_WRAPPERS

[Sam James]

For reference, this was first observed in https://bugs.gentoo.org/775215.


signature.asc
Description: Message signed with OpenPGP

Re: Wrong order of preprocessor and compiler flags

[Sam James]

> On 24 Mar 2022, at 14:42, Bob Friesenhahn  
> wrote:
> 
> On Thu, 24 Mar 2022, Evgeny Grin wrote:
>> 
>> It's not uncommon to use CFLAGS for macros or for '-I' flags.
>> I think it's easy to imagine other conflicting situation where the order of 
>> used flags is significant.
> 
> It may not be uncommon, but it is a usage bug to use CFLAGS for pre-processor 
> options.  Such usages should be corrected.
> 
> Becides cases where the pre-processor may be used directly (not sure if there 
> are any), it should be considered that CPPFLAGS works for both the C and C++ 
> compilers but CFLAGS is only for the C compiler.
> 
>> Usage of CPPFLAGS before CFLAGS looks logical for me, I think autoconf 
>> should be fixed.
> 
> It does feel more logical.
> 

Agreed on both counts & with the original post. We handle stuff like this quite 
often downstream and would be glad to see this.

best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: gtk configure fails to detect XInput2.h

[Sam James]

> On 31 Jul 2022, at 00:16, alexandre schenberg  
> wrote:
> 
> Hi. I am currently running the configure script of gtk. It stops with the 
> message: "configure: error: *** XInput2 extension not found. Check 
> 'config.log' for more details.". Then I checked config.log. And there it is 
> says: "configure:23790: error: *** XInput2 extension not found. Check 
> 'config.log' for more details."  No very useful is it?
> 
> Then I did a little of online research and figured out that this extension 
> belongs to the libXi package. I built it and installed it to a dir.
> 
> Finally, I executed the configure script again, passing the include dir to 
> configure through the CPPFLAGS.
> 
> CPPFLAGS="-I/media/34GB/Arquivos-de-Programas-Linux/xorg/X11-1.3.6/include/ 
> -I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xorgproto-2018.1/include/ 
> -I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xi-1.5.0/include/"
> 
> And the result was: "configure: error: *** XInput2 extension not found. Check 
> 'config.log' for more details." I checked the include dir of Xi. Inside it 
> there is a X11 dir, inside of it an extensions dir, and inside it, XInput.h 
> and XInput2.h. So, it seems ok to me
> 
> I then gave alook at configure.ac. This is what: "grep XInput* configure.ac" 
> returned:
> 
> # set up things for XInput
>AC_CHECK_HEADER(X11/extensions/XInput2.h,
>AC_DEFINE(XINPUT_2, 1, [Define to 1 if XInput 2.0 is 
> available]))
>   AC_DEFINE(XINPUT_2_2, 1, [Define to 1 if XInput 2.2 is 
> available]),
>   [[#include ]])])
>[AC_MSG_ERROR([*** XInput2 extension not found. Check 'config.log' for 
> more details.])])
> 
> It might be a version issue? I gave a quick glance inside XInput2.h and did 
> not see any definition inside it.
> From libXi.la there is:
> 
> # Version information for libXi.
> current=7
> age=1
> revision=0
> 
> and xi.pc says:
> Version: 1.5.0
> 
> So, any ideas? Thanks for your time.
> 

You should report this issue to the GTK maintainers. That is their own 
configure check. Also, you haven't shared the full output of configure and 
config.log.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 10 Nov 2022, at 21:10, Michael Orlitzky  wrote:
> 
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>> 
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
> 
> While everyone else is discussing big ideas, it would be helpful for me
> personally if autoconf just made a release with the latest bugfixes.
> 
> I report these compatibility issues upstream, and it's awkward to have
> to tell the maintainers that they must cherry-pick a git commit,
> rebuild autoconf, and then autoreconf their project before they can
> even even think about exporting CFLAGS="-Werror=..." to build-test
> their project.
> 
> 

Before I dive into the rest of this thread: yes, this is one of
my main thoughts on the matter. Autoconf has a huge network
effect problem and letting the existing fixes start to propagate
would be most helpful.

Like it or not (and I don't like it), various software tries
to jam in -Werror (and sometimes -pedantic-errors, see rsync!) to their
configure scripts which means even prototype issues end up
causing problems.

Note that in autoconf git, we've also got 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
which is going to affect time_t efforts too, but that's
for another thread on libc-alpha at some point
when I want to bring up some issues.


signature.asc
Description: Message signed with OpenPGP

On time64 and Large File Support

[Sam James]

Hi all,

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-lfs

These would hard-enable the relevant #defines within glibc's headers and ensure 
that any
binaries built with such a glibc have both Large File Support (LFS) and time64 
support.

I've come to the conclusion it's infeasible to try handle the migration 
piecemeal. Various
mismatches can and will occur (and while it's more likely with time64, it's 
possible with LFS
too) [1].

We're now (possibly) on the eve of an autoconf 2.72 release which contains two 
changes
of note [2][3]
1. addition of a new AC_SYS_YEAR2038 macro;
2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.

Indeed, the gnulib version of change #2 is exactly how we ended up with
wget/gnutls breaking [1]. I feel this shows that the only approach
"supported" by glibc right now is untenable.

On reflection and after extensive discussion within Gentoo (although
I don't seek to speak for everybody there) - with special thanks to
David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
we don't think it's feasible to handle this in a piecemeal fashion -
at the very least not without spending a significant & for some,
undesirable amount of time on supporting "obsolete" 32-bit platforms.

Right now, we're forcing the year2038 autoconf cache variable off
to avoid more gnutls/wget instances and plan to do a hard-rebuild (new
set of "profiles" in Gentoo parlance) for 32-bit systems that
enable this. This will be difficult to do properly without having
significant stragglers without some support in glibc as proposed.

All that to say, I don't propose making these options unconditional,
because I think the boat has sailed as of glibc-2.34 [4], and I think
it's fair that autoconf keep the behaviour as described in git master
right now given the situation with glibc, but I don't think it's
a wise path for most distributions to follow.

See also a previous discussion on libc-alpha [5].

What do you think?

[0] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
[1] https://bugs.gentoo.org/828001
[2] 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
[3] 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bc66c26f488975ea9ad22033b9fa28809f4bf65e
[4] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
[5] https://sourceware.org/pipermail/libc-alpha/2022-January/134985.html

best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 11 Nov 2022, at 03:33, Zack Weinberg  wrote:
> 
> 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: yes, this is one of
>> my main thoughts on the matter. Autoconf has a huge network
>> effect problem and letting the existing fixes start to propagate
>> would be most helpful.
> 
> 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 have not been following the y2038 work closely.  Is it going to affect 
> things in a good way or a bad way??

I've started a discussion on libc-alpha about this, but I think it depends on 
how you view
the migration. I've come to the conclusion it's probably good but only after 
thinking
about it a lot. I wish it'd been discussed on the mailing lists first, as it's 
not obvious
that it's okay, and I'm not sure if others will even share my view.

Let's have the conversation there as it'll be easier to track.

Thanks for prompting me to write this up finally.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 10 Nov 2022, at 17:16, Zack Weinberg  wrote:
> 
> 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 release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.

Thank you for asking. The fixes in git get us there, I think, as far
as you can, with the exception of the stuff you (and I) mention below.

> 
> [...]
> 
> 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
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.  Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.
> 
> How important do you think it is for this to be fixed?
> 
> Are there any other changes you would like to see in a near-future
> Autoconf 2.72 in order to make this transition easier?

This might be a WONTFIX but let me mention it just for
the record:
1. AC_CHECK_FUNCS is, as you've noticed, very noisy.

I would support having a hardcoded list for certain CHOSTs
as Rich suggests to reduce noise, but I don't think we can
do this accurately very quickly.

I think for Gentoo's efforts, I might just build up a set
of cache variables for glibc/musl on each arch to
reduce the noise in logs. But that's time consuming
and brittle still, so I'm not sure.

(Note that Gentoo and Fedora are taking two complementary
but different approaches here:
we're diffing config.logs and other compiler
output, in addition to build logs, while Florian for Fedora
Is building a list of functions which *we know* are available
In a specific environment and patching gcc to spit out
logs when something in said list is missing. This mitigates
noise for things like functions in libbsd, which I'm finding
a bit of a pain.)

I'll see what others say.

2. I often have to set the following cache variables to
reduce noise in logs:
* ac_cv_c_undeclared_builtin_options="none needed"
* ac_cv_header_sys_types_h_makedev=no
* gl_cv_compiler_check_decl_option="-Werror=implicit-function-declaration" 
(obviously this is gnulib)
* gl_cv_minmax_in_limits_h=no

I don't know if we can do anything to make these tests smarter
or just leave it as-is. It's fine if we can't, as exporting the cache
vars is not a bad workaround for us when doing testing.

> 
> zw
> 
> p.s. GCC and Clang folks: As long as you’re changing the defaults out
> from under people, can you please also remove the last few predefined
> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
> -std=gnuXX modes?

I support this as well. This kind of thing has led to endless
bugs in userland, see https://reviews.llvm.org/D137511.



signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 11 Nov 2022, at 09:16, Paul Eggert  wrote:
> 
> On 2022-11-11 00:38, Sam James wrote:
>> All that to say, I don't propose making these options unconditional,
>> because I think the boat has sailed as of glibc-2.34 [4], and I think
>> it's fair that autoconf keep the behaviour as described in git master
>> right now given the situation with glibc, but I don't think it's
>> a wise path for most distributions to follow.
> As a practical matter, I expect that each distro will have to do a big-bang 
> move, assuming the distro want to support traditional 32-bit platforms at 
> all. It makes little sense to try to have some programs and libraries with 
> 32-bit time_t, while others have 64-bit time_t. Just switch to 64-bit time_t 
> everywhere.
> 
> This is not something distros can put off for long. We're only 15 years from 
> when 32-bit time_t stops working. If distros plan to to support traditional 
> 32-bit platforms, they really need to do the big-bang move soon. They can do 
> it by predefining _TIME_BITS=64 and _FILE_OFFSET_BITS=64, or by using the new 
> Autoconf macros, or whatever.
> 
> One possible way forward would be for glibc to change its defaults for 
> _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This 
> would make it easier to do a big-bang switch, which is what people need to do 
> anyway. The backward-compatibility argument for defaulting these to 32 is 
> making less and less sense as time goes on.

+1.

I completely agree and I've reached the same conclusion. My suggestion for 
configure args
was to be a bit more gentle and avoid controversy, but really, your suggestion 
would work and would
force distros to handle it at the same time, which is best for users.

(And I really did try to make piecemeal work, but I've decided it can't.)

I think we're at risk of distros either putting this off or equivocating which
just harms our users. I should've spoken up at the time of 2.34.

FWIW, musl did this and it really was for the best: 
https://musl.libc.org/time64.html.



signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[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
>> option. I'll outline why below.
>> 
>> 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.

I hadn't considered that option. I'll reflect on it. Please let me know
if you have further thoughts on this.

But that said, these binaries are broken anyway in 2038?

> We need to support legacy binaries on i386.  Few libraries are
> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis.  For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.

While I agree, I don't think it's as well-known that it should be that
these are ABI breaking and require inspection. It's being done ad-hoc
or in many cases, not at all.

Part of the use of this thread is, if nothing else, we can show upstreams
and other distros It if they're confused.

It's very easy to miss that a package has started enabling LFS
and then your opportunity to catch the ABI breakage is gone.

It doesn't help that I (and I suspect most distribution maintainers)
do all development on x86_64 and hence even ABI diffing isn't
going to notice. You have to specifically diff the build system, which I
do, but it's not easy if it's buried deep within gnulib or something.

> 
>> These would hard-enable the relevant #defines within glibc's headers
>> and ensure that any binaries built with such a glibc have both Large
>> File Support (LFS) and time64 support.
>> 
>> I've come to the conclusion it's infeasible to try handle the
>> migration piecemeal. Various mismatches can and will occur (and while
>> it's more likely with time64, it's possible with LFS too) [1].
>> 
>> We're now (possibly) on the eve of an autoconf 2.72 release which contains 
>> two changes
>> of note [2][3]
>> 1. addition of a new AC_SYS_YEAR2038 macro;
>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>> 
>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>> wget/gnutls breaking [1]. I feel this shows that the only approach
>> "supported" by glibc right now is untenable.
> 
> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
> 
> I thought the gnulib change has been reverted?
> 
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.
> 

Right, we need to be unified on this, because it's confusing enough
without unilateralism.



signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 11 Nov 2022, at 03:33, Zack Weinberg  wrote:
> 
> 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: yes, this is one of
>> my main thoughts on the matter. Autoconf has a huge network
>> effect problem and letting the existing fixes start to propagate
>> would be most helpful.
> 
> 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?
> 
>> Note that in autoconf git, we've also got
>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
>> which is going to affect time_t efforts too
> 
> I have not been following the y2038 work closely.  Is it going to affect 
> things in a good way or a bad way??
> 

Back to the original thread: I suspect it might be a better idea to 
(temporarily) revert the two changes
and omit it from 2.72 to allow the other changes to get out.

That's not a judgement on whether the changes will ultimately remain in 
autoconf, I'm just
hesitant to allow a discussion I've kicked off to derail something that we were 
planning
on doing anyway.

What do you think?


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 12 Nov 2022, at 03:40, Zack Weinberg  wrote:
> 
> 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't be able to
>> help us much.
> 
> I’m sadly not surprised.
> 
> 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 newer Perl and Bash and M4) is a thing that could happen.

I didn't want to ask you to do this because I felt fortunate enough
you were volunteering to handle 2.72, but this would indeed be a help,
because then I won't have to try persuade people they should totally upgrade,
and it should happen naturally enough with distro upgrades.

If you are willing, that would be welcome.

Of course, we'll have to go lobby them, but that is what it is :)



signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha 
>  wrote:
> 
> Sam James  writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer  wrote:
>>> We need to support legacy binaries on i386.  Few libraries are
>>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>>> distributions, no one is going to do that work, and we have to stick to
>>> whathever we are building today.
>> 
>> While I agree, I don't think it's as well-known that it should be that
>> these are ABI breaking and require inspection. It's being done ad-hoc
>> or in many cases, not at all.
> …
>>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>>> contains two changes of note [2][3]
>>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>>> 
>>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>>> "supported" by glibc right now is untenable.
>>> 
>>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>>> for Fedora unfortunately.
>>> 
>>> I thought the gnulib change has been reverted?
>>> 
>>> I really wish the rest of GNU would talk to glibc maintainers before
>>> overriding glibc maintainer decisions.
> 
> There seems to be a disconnect between Paul Eggert’s position on these
> changes and everyone else on this thread’s position.
> 
> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.
> If an application is being built on the machine where it’ll be used, and
> both it and the system support building it with 64-bit time_t and off_t,
> *why wouldn’t you*?  It has no impact on anything else to do that, and
> it future-proofs your installataion.
> 
> But everyone else is worrying about cases where, either, an application
> is built with 64-bit time_t and/or off_t and then copied to a different
> system where the underlying libraries *don’t* support that, or a *shared
> library* is rebuilt with 64-bit time_t and/or off_t and that silently
> changes its ABI out from under programs that use it.
> 

Precisely.

> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)
> 
> (It’s also unfortunate that, 20+ years after the invention of ELF symbol
> versioning, it’s still ridiculously difficult.  So many macros and
> assembly hacks and fighting with libtool.  But I digress.)
> 
> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
> in order to unblock C23 testing — am I correct?  It doesn’t resolve the
> larger issue, but it gives us more time to think about what the
> resolution ought to be.
> 
> What do you think?

This is really I think the best option while allowing us time & space
to complete the larger discussion.

We keep AC_SYS_YEAR2038 which lets upstreams opt in,
but it avoids the risk of sudden LFS-into-time64 rollover.

Year 2038 work is really important (which is why I brought
up the topic) but I don't want confusion around it to make
people avoid adopting 2.72 or leave us without a 2.72
at all.

I do sympathise with Paul's position, but I'm not
a believer in piecemeal anyway now and it's fair to say there's no
consensus on this yet.

Paul's point Is fair that distros who wish can set the cache var to
ff, so *if* you and Paul want to keep it in.

I could live with a bigger "please check this!" in NEWS. I don't think it's a
total disaster as long as we brief distros first, as we're already
doing it for gnuilb & upstreams may well end up doing themselves,
so the train is on its way out of the station anyway.

(I think we need to keep the discussion going on that front,
but I think it'd be wrong to let it block this release, as it

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 12 Nov 2022, at 00:53, Paul Eggert  wrote:
> 
> On 2022-11-11 15:25, Sam James wrote:
>> That's not a judgement on whether the changes will ultimately remain in 
>> autoconf, I'm just
>> hesitant to allow a discussion I've kicked off to derail something that we 
>> were planning
>> on doing anyway.
>> What do you think?
> 
> I'm hesitant to do that partly because the changes to _TIME_BITS are already 
> released in multiple packages and need to be dealt with, regardless of 
> whether they're backed out of Autoconf. This is because they've been in 
> Gnulib since July and several packages based on these Gnulib changes have 
> been released since then. Current Gnulib assumes these changes will appear in 
> the next Autoconf release; if that's not true, we'll need to upgrade Gnulib 
> and in the meantime the other packages released since July would still have 
> the changes whatever we do with Gnulib and/or Autoconf.
> 
> Since distros need to deal with the issue anyway, regardless of what Autoconf 
> and/or Gnulib does, I don't see why backing the changes out of Autoconf will 
> help all that much.
> 
> It should pretty easy for a distro to say "hold on, I don't want 64-bit 
> time_t yet" without changing either Autoconf or Gnulib so if you want to go 
> that route please feel free to do so.

The fact it's already shipped in gnulib & that the "real problem" is in glibc 
IMO means that I don't feel
strongly about reverting it.

You're right that distros have the toggle so as long as we mention this 
prominently enough in NEWS,
I don't have a strong objection to master being released as-is.


signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 04:20, Wookey  wrote:
> 
> On 2022-11-11 10:19 +0100, Florian Weimer wrote:
> 
> Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf
> in Debian.  We are currently doing a preliminary bootstrap to see what
> breaks. We strongly suspect that only a wholesale rebuild for the new
> ABI (i.e a new Debian architecture) is practical, but have not yet
> entirely ruled out attempting a migration within the existing armhf
> arch.
> 
> [snip]
> 
>> * 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-lfs
> 
> I don't quite follow the logic of this. glibc already has build-time macros 
> to set these two things:
> _TIME_BITS=64
> _FILE_OFFSET_BITS=64
> 
> why do we need configure options too?

How do you make sure that every program built uses it? Not every
program respects CPPFLAGS and even in CFLAGS, it's a bit
of a nuisance.

If you patch GCC, you don't cover Clang. If you patch system
compilers, that's messy but also doesn't help with custom-built programs.

Of course, we could just patch glibc and cheerily jam it in the headers,
but we run into the kind of problems that Joseph Myers mentions then,
I think (basically I'd want to make sure we do it right.)

> 
>>> We're now (possibly) on the eve of an autoconf 2.72 release which contains 
>>> two changes
>>> of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
> 
> Which is the opposite way round to glibc, where _TIME_BITS=64 requires
> _FILE_OFFSET_BITS=64, but not the other way round
> (_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding 
> something here?
> 

I wonder the same. I don't think it's obvious, and it may not be obvious
to people writing software using autoconf either...

> It doesn't seem right to me that AC_SYS_LARGEFILE should imply
> AC_SYS_YEAR2038. What is the reasoning behind that?
> 
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.  If we cannot revert this in
>> autoconf (and gnulib), this will very much endanger the Fedora i386
>> port.  Debian will probably be impacted in the same way.
> 
> I need to read around all this as I have only just become aware that
> the LFS thing is entangled with the timet_64 thing. Is there a good
> place to read _why_ one implies the other? It definitely complicates
> matters.

time64 has to imply LFS because of some structures like stat including
both off_t (LFS) and st_atim (time64), I think. Some of it is internal too.

Or do you mean LFS => time64? I have no idea for why that's
entangled in autoconf and gnulib.

> 
>>> On reflection and after extensive discussion within Gentoo (although
>>> I don't seek to speak for everybody there) - with special thanks to
>>> David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
>>> we don't think it's feasible to handle this in a piecemeal fashion -
>>> at the very least not without spending a significant & for some,
>>> undesirable amount of time on supporting "obsolete" 32-bit platforms.
> 
> Distros need to co-ordinate on this. If there are going to be new
> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
> them and use them. If distros are happy to migrate to these ABIs
> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
> i686-linux-gnu) then we should do that.
> 
> If half the distros migrate within the existing triplet and the rest use
> a new one, that sounds like a recipie for much confusion.
> 

100%. And also on sharing patches and known problems
and experience with the migration. All of it!

> I could write more, but I'll swot up a bit first :-)

It's not easy to find much about all of this! I almost
felt like I was missing something at first. :)

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 04:56, Wookey  wrote:
> 
> On 2022-11-12 04:28 +0000, Sam James wrote:
>> 
>> 
>>> On 12 Nov 2022, at 04:20, Wookey  wrote:
>>> 
>>> Distros need to co-ordinate on this. If there are going to be new
>>> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
>>> them and use them. If distros are happy to migrate to these ABIs
>>> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
>>> i686-linux-gnu) then we should do that.
>>> 
>>> If half the distros migrate within the existing triplet and the rest use
>>> a new one, that sounds like a recipie for much confusion.
>>> 
>> 
>> 100%. And also on sharing patches and known problems
>> and experience with the migration. All of it!
> 
> OK. It seems that the time is right to have this conversation. So we should 
> agree on a place to do it.
> 
> We have used the linaro cross-distro list in the past as it is
> intended for this sort of cross-cutting discussions. I can't think of
> a better place?
> https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/
> 
> Some of the right people are probably already there, but we should
> encourage others with relevant expertise to join.
> 

That list is new to me (sub'd now) but I'm fine with using it as long
as linaro are still OK with us using it and them maintaining it.

Thanks for taking the initiative!

If they aren't, we could request a list from lists.linux.dev
(Linux Foundation).

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
> 
> On 2022-11-11 07:11, Aaron Ballman wrote:
>> We believe the runtime behavior is sufficiently dangerous to
>> warrant a conservative view that any call to a function will be a call
>> that gets executed at runtime, hence a definitive signature mismatch
>> is something we feel comfortable diagnosing (in some form) by default.
> 
> As long as these diagnostics by default do not cause the compiler to exit 
> with nonzero status, we should be OK with Autoconf-generated 'configure' 
> scripts. 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 continue to tell people "don't do 
> that".
> 

Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


signature.asc
Description: Message signed with OpenPGP

Re: On time64 and Large File Support

[Sam James]

> On 12 Nov 2022, at 21:31, Paul Eggert  wrote:
> 
> On 2022-11-12 12:23, Wookey wrote:
>> we can't just have everyone who enabled LFS sometime in the
>> last 20 years suddenly being forced into the time_t change (can we?)
> 
> We've done it in the past.
> 
> AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. 
> Originally it affected only off_t; its effect on other types like ino_t came 
> later. Hence people who initially used AC_SYS_LARGEFILE were later "suddenly 
> forced" into an ino_t width change. Similarly for other non-off_t types that 
> AC_SYS_LARGEFILE affects.
> 
> So there's longstanding precedent for AC_SYS_LARGEFILE changing the width of 
> system types that were formerly unaffected. The difference is that time_t is 
> more widely used than ino_t etc., and people are understandably more 
> concerned about time_t changes.
> 

Thanks, that's a helpful bit of history I wasn't aware of there.

> 
> Because of the concerns raised in this thread it's become clear that what's 
> in Autoconf now is too drastic, and I've proposed (though not yet 
> implemented) a change that will cause AC_SYS_LARGEFILE to continue to not 
> affect time_t unless there's an affirmative request like "./configure 
> --enable-year2038". I am waiting for feedback on that from Zack and others, 
> and am hoping for quick turnaround on this because we do need a new Autoconf 
> release.
> 
> 

Sorry, I missed this until now.

That would work well for me too. It's fine for me at least if the same macro 
just haas additional compatibilities, even if a bit confusing
at first.

As for further changes (as the original post wasn't exclusive to autoconf),
I await comment from other glibc maintainers as I still feel like we're
pretty stuck about how to handle this overall. But your suggestion
(or zw's patch) puts out or dampens the autoconf fire at least.

Thanks for helping come to a compromise. I know this isn't
a simple or easy topic at all.


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 15 Nov 2022, at 13:30, Zack Weinberg  wrote:
> 
> 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 continue to tell people "don't do 
>>> that".
>>> 
>> 
>> Is there somewhere in the autoconf docs we actually say this?
>> 
>> I've seen a few instances of folks adding it themselves very
>> early in their configure scripts (which is a pain for distros
>> anyway) which then ends up affecting the rest.
> 
> It's mentioned in the NEWS entry for 2.70: 
> https://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS#n170

Thanks, sorry, I didn't think to check NEWS. This is good enough for me to link 
folks to, anyway, for the time being.

> Note that there have been bug reports for cases where running builds with 
> more warnings than configure uses (and I think also -Werror), means that 
> configure checks spuriously succeed (i.e. configure reports that something is 
> available, but then you get compiler errors on the code that tries to use 
> it).  I can't remember any concrete examples right now, though.

I can totally imagine that, don't stress about the examples.



signature.asc
Description: Message signed with OpenPGP

Re: Possible regressions with trunk autoconf (vs 2.71)

[Sam James]

> On 16 Nov 2022, at 09:06, Frederic Berat  wrote:
> 
> Hello again,
> 
> Some progress on this, it looks like, at least for libpng, there is at one
> place where the "Port AC_LANG_CALL" seems to be the culprit.
> Specifically, the "," in the C comment, is interpreted by M4 as argument
> split which in turn leads to the syntax error.
> I made a small test where I  "overquote" the snippet, which seems to work
> around the problem for this package at least, but there may be better
> solutions:

I did notice this issue but when I investigated the broken packages,
they were underquoting by the looks of it:
- 
https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-devel/autoconf?id=855f1f72f42c2f9b5ed97220e3ced97a35aa075b
- https://bugs.gentoo.org/871753

But it's very possible that, as you note, autoconf itself
has a problem and it was just bad luck wrt which packages
broke first.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: Possible regressions with trunk autoconf (vs 2.71)

[Sam James]

> On 16 Nov 2022, at 07:41, Frederic Berat  wrote:
> 
> Hello,
> 
> In the past few months, I worked on a tool that massively rebuild packages
> that depend on a specific other package, in order to help spot problems as
> early as possible (on Fedora and RHEL so far).
> 

I'm interested in this work. Would you mind letting me know if there's a place
I can keep up with developments? I've wanted to have some way of
Organising response to stuff like this and sharing patches for distros
for a while.

Maybe a mailing list to announce likely breakage and stuff which may
need backporting.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James]

> On 16 Nov 2022, at 15:27, Richard Biener  wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc  wrote:
>> 
>> Hey,
>> 
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>> 
 The idea is so obvious that I'm probably missing something, why autoconf
 can't use that idiom instead.  But perhaps the (historic?) reasons why it
 couldn't be used are gone now?
>>> 
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>> 
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>> 
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
> 
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
> 
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
>  |  ^~
> t.c:1:1: note: 'printf' is declared in header ''
>  +++ |+#include 
>1 | char printf(void);
> 
> so without -Werror this should be fine.
> 
Unrelated but I was a bit tempted to ask for throwing in 
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the 
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.

> Richard.


signature.asc
Description: Message signed with OpenPGP

Re: Possible regressions with trunk autoconf (vs 2.71)

[Sam James]

> On 18 Nov 2022, at 07:11, Frederic Berat  wrote:
> 
> Thanks, I'll update the bug I opened for them.

Could you share the links? Thanks.


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH] fix AC_CHECK_HEADER_STDBOOL regression

[Sam James]

> On 26 Dec 2022, at 18:11, Paul Eggert  wrote:
> 
> Thanks for reporting that. I installed that patch.
> 

Thanks, this should allow me to begin re-testing w/ autoconf from git.


signature.asc
Description: Message signed with OpenPGP

Re: Conditional AC_CHECK_HEADER

[Sam James]

> On 4 Feb 2023, at 13:42, Florian Weimer  wrote:
> 
> 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 run.  Making the
> AC_CHECK_HEADER invocation unconditional fixes that.
> 
> 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.

There's a tendency for quoting to go wrong with shell conditionals overall,
which is why I try to push people towards AS_IF.


signature.asc
Description: Message signed with OpenPGP

Re: Conditional AC_CHECK_HEADER

[Sam James]

> On 6 Feb 2023, at 06:00, Paul Eggert  wrote:
> 
> On 2023-02-04 09:26, Russ Allbery wrote:
>> The principle that one should always use an AS_* construct if one exists
>> rather than regular shell constructs could probably be documented more
>> aggressively.
> 
> I gave that a shot by installing the attached.From 84e4582f534d5e1ded05547c54ca518e31604b1e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 5 Feb 2023 21:48:15 -0800
Subject: [PATCH] doc: improve AS_IF doc

* doc/autoconf.texi: Improve documentation of AS_IF, AS_CASE, etc.
Clarify the advice about when AS_IF is needed, and follow that
advice in examples.
---
 doc/autoconf.texi | 239 ++
 1 file changed, 137 insertions(+), 102 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index cb03b6ca..c92c87e0 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -2352,8 +2352,8 @@ You are encouraged to use literals as @var{tags}.  In particular, you
 should avoid
 
 @example
-@dots{} && my_foos="$my_foos fooo"
-@dots{} && my_foos="$my_foos f"
+AS_IF([@dots{}], [my_foos="$my_foos fooo"])
+AS_IF([@dots{}], [my_foos="$my_foos f"])
 AC_CONFIG_@var{ITEMS}([$my_foos])
 @end example
 
@@ -2361,8 +2361,8 @@ AC_CONFIG_@var{ITEMS}([$my_foos])
 and use this instead:
 
 @example
-@dots{} && AC_CONFIG_@var{ITEMS}([fooo])
-@dots{} && AC_CONFIG_@var{ITEMS}([f])
+AS_IF([@dots{}], [AC_CONFIG_@var{ITEMS}([fooo])])
+AS_IF([@dots{}], [AC_CONFIG_@var{ITEMS}([f])])
 @end example
 
 The macros @code{AC_CONFIG_FILES} and @code{AC_CONFIG_HEADERS} use
@@ -3844,20 +3844,22 @@ displaying the options of the package @code{foo}.  Instead, you should
 write:
 
 @example
-if test "x$package_foo_enabled" = xyes; then
-  AC_CONFIG_SUBDIRS([foo])
-fi
+AS_IF([test "x$package_foo_enabled" = xyes],
+  [AC_CONFIG_SUBDIRS([foo])])
 @end example
 
 If a given @var{dir} is not found at @command{configure} run time, a
 warning is reported; if the subdirectory is optional, write:
 
 @example
-if test -d "$srcdir/foo"; then
-  AC_CONFIG_SUBDIRS([foo])
-fi
+AS_IF([test -d "$srcdir/foo"],
+  [AC_CONFIG_SUBDIRS([foo])])
 @end example
 
+These examples use @code{AS_IF} instead of ordinary shell @code{if} to
+avoid problems that Autoconf has with macro calls in shell conditionals
+outside macro definitions.  @xref{Common Shell Constructs}.
+
 If a given @var{dir} contains @command{configure.gnu}, it is run instead
 of @command{configure}.  This is for packages that might use a
 non-Autoconf script @command{Configure}, which can't be called through a
@@ -4384,11 +4386,10 @@ historical Lex:
 
 @example
 AC_PROG_LEX
-if test "x$LEX" != xflex; then
-  LEX="$SHELL $missing_dir/missing flex"
-  AC_SUBST([LEX_OUTPUT_ROOT], [lex.yy])
-  AC_SUBST([LEXLIB], [''])
-fi
+AS_IF([test "x$LEX" != xflex],
+  [LEX="$SHELL $missing_dir/missing flex"
+   AC_SUBST([LEX_OUTPUT_ROOT], [lex.yy])
+   AC_SUBST([LEXLIB], [''])])
 @end example
 
 The shell script @command{missing} can be found in the Automake
@@ -10093,24 +10094,25 @@ AC_MSG_CHECKING([how to get file system type])
 fstype=no
 # The order of these tests is important.
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
-#include ]])],
-  [AC_DEFINE([FSTYPE_STATVFS], [1],
- [Define if statvfs exists.])
-   fstype=SVR4])
-if test $fstype = no; then
-  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
-#include ]])],
-  [AC_DEFINE([FSTYPE_USG_STATFS], [1],
- [Define if USG statfs.])
-   fstype=SVR3])
-fi
-if test $fstype = no; then
-  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
-#include ]])]),
-  [AC_DEFINE([FSTYPE_AIX_STATFS], [1],
- [Define if AIX statfs.])
-   fstype=AIX])
-fi
+ #include 
+   ]])],
+  [AC_DEFINE([FSTYPE_STATVFS], [1],
+ [Define if statvfs exists.])
+   fstype=SVR4])
+AS_IF([test $fstype = no],
+  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
+#include 
+  ]])],
+ [AC_DEFINE([FSTYPE_USG_STATFS], [1],
+[Define if USG statfs.])
+  fstype=SVR3])])
+AS_IF([test $fstype = no],
+  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
+#include 
+  ]])],
+ [AC_DEFINE([FSTYPE_AIX_STATFS], [1],
+[Define if AIX statfs.])
+  fstype=AIX])])
 # (more cases omitted here)
 AC_MSG_RESULT([$fstype])
 @end group
@@ -10151,12 +10153,13 @@ already defined a certain C preprocessor symbol, test the value of the
 appropriate cache variable, as in this example:
 
 @example
-AC_CHECK_FUNC([vprintf], [AC_DEFINE([HAVE_VPRINTF], [1],
-  [Define if vprintf exists.])])
-if test "x$ac_cv_func_vprintf" != xyes; then
-  AC_CHECK_FUNC([_doprnt], [AC_DEFINE([HAVE_DOPRNT], [1],
-   

Re: new snapshot available: autoconf-2.72c

[Sam James]

"Zack Weinberg"  writes:

> On Mon, Mar 27, 2023, at 11:38 AM, Jim Meyering wrote:
>> We're overdue for a new release, so here's a snapshot in preparation
>> for that, which I want to call 2.73 (skipping 2.72).  There has never
>> been an autoconf-2.72 release, yet `git describe` now prints 2.72c and
>> has been printing strings like v2.72a-92-g8db00aa8 for years.
>
> Just as a note, I thought this version numbering scheme was weird too the 
> first time I encountered it, but the historical practice has been that 2.72a, 
> 2.72b, 2.72c, etc. are beta releases of 2.72.

FWIW, the historical practice doesn't work very well for at least
Gentoo's package manager, and I believe this is true for other
distributions too.

That is, 2.72a > 2.72, although 2.72_alpha < 2.72. So Jim's decision
in this case has worked well here at least.
>
>>   https://meyering.net/ac/autoconf-ss.tar.xz  1.4 MB
>>   https://meyering.net/ac/autoconf-ss.tar.xz.sig
>>   https://meyering.net/ac/autoconf-2.72c.tar.xz
>
> Are you able to upload this to ftp.gnu.org as an official beta?
>

or alpha.gnu.org, I suppose.

>> NEWS
>> =
> ...
>>   Port to compilers that moan about K&R func decls
>>   More fixes for compilers that reject K&R function definitions.
>
> Compatibility with compilers that reject unprototyped function declarations 
> should maybe get a more prominent NEWS entry.
>

Yeah, given it's the impetus.

> zw



signature.asc
Description: PGP signature

Re: [platform-testers] new snapshot available: autoconf-2.72c

[Sam James]

Paul Eggert  writes:

> On 2023-03-28 13:57, Richard Purdie wrote:
>>  From a regression/failure point of view, the worrying issue is the
>> gpgme/mpg123 issue on x32 which also appears for musl 32 and 64 bit x86
>> targets.
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/6881/steps/11/logs/stdio
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6901/steps/11/logs/stdio
>
> Could you explain that a bit more? All I can see from the first log is:
>
> Summary: 2 tasks failed:
>
> /home/pokybuild/yocto-worker/musl-qemux86-64/build/meta/recipes-support/gpgme/gpgme_1.18.0.bb:do_compile

Also, which version of musl? If it's a musl snapshot from git, I think
that's expected because of the LFS changes they made.

I couldn't find the full logs either, just what Paul noted. I didn't
poke further as I wasn't sure if I was missing something obvious, then
got distracted :)



signature.asc
Description: PGP signature

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Sam James]

Florian Weimer  writes:

> * 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 you're aware of are useful to me)?
>
> The latest installment of this issue is here:
>
>   configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
>   
>
> I wasn't aware of this change from
> 33c26d2700f927432c756ccf7a4fc89403d35b95 ("Fix port of AC_FUNC_MMAP"),
> or maybe I just forgot about it:
>
> +#ifndef getpagesize
> +# ifdef _SC_PAGESIZE
> +#  define getpagesize() sysconf (_SC_PAGESIZE)
> +# elif defined _SC_PAGE_SIZE
> +#  define getpagesize() sysconf (_SC_PAGE_SIZE)
> +# elif HAVE_GETPAGESIZE
> +int getpagesize ();
> +# else
>
> This should indeed isolate this test from the outcome of the getpagesize
> check because it now prefers sysconf.

Thanks for raising this one - Zack had asked me for any outstanding
issues and I had something like this in the back of my head but couldn't
yet find a good summary.

Re: bug#68274: automake 1.16j nonnumerical version confuses scripts

[Sam James]

"Zack Weinberg"  writes:

> On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
>> On 13 Jan 2024 15:58, Karl Berry wrote:
>>> Another alternative: when this came up 30-odd years ago, rms changed the
>>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>>> that would at least have the benefit of following a recommendation, and
>>> as a side effect, would also fix jami's assumption (poor practice though
>>> it is, IMHO).
>>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>>> 
>>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>>> (rough guess with some grep counting) the .90 convention is by far the
>>> most common approach (a couple thousand), followed by the suffix letter
>>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>>> are both trailing the field. Other random conventions also present.
>>> 
>>> It all feels like bikeshedding to me, so my inclination is to do
>>> nothing.  If we do change, I think we should use .90.  --best, karl.
>>
>> using .90 is certainly better than single-letters.  if you're fine with
>> it, then let's switch.
>
> For what it's worth, I had planned to switch Autoconf, starting with the
> next release, to use *some* version numbering scheme for beta releases
> that sorts correctly according to things like strverscmp() and
> dpkg --compare-versions.  The "append a letter to the version number
> intended for the final release" convention makes these algorithms sort
> the betas *after* the release, which is backwards.
>
> My plan *was* to append letters to the version number for the *previous*
> release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
> which I think is what Automake is doing now) but I like .9x version numbers
> better because it's more common (as you observed) and therefore more likely
> to be understood at sight.  I'd actually forgotten that .9x versions were
> an official GNU recommendation.
>

I was planning on finally filing a bug for this because I couldn't really
package the latest automake pre-release given it totally breaks our
sorting (and afaik sorting in every other PM too).

We're used to .9x and it works fine for us.

thanks,
sam

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Sam James]

Paul Eggert  writes:

> On 2024-04-26 08:10, Zack Weinberg wrote:
>
>> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
>> Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
>> unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
>> test fails, and __STDC_NO_VLA__ was not defined by the compiler,
>> then AC_DEFINE([__STDC_NO_VLA__], 1)
>
> Although the basic strategy sounds reasonable, AC_PROG_CC is
> documented to operate by setting compiler options not via AC_DEFINE,
> so presumably this should put -D__STDC_NO_VLA__ into $CC rather than
> use AC_DEFINE.
>
> I installed the attached patch, which is less ambitious but should
> address the original problem report. The attached patch doesn't
> preclude your suggestion, which can be done later as needed.
>
> [2. text/x-patch; 0001-Port-better-to-MSVC.patch]...

Note that "or later" isn't right -- C23 makes VLAs mandatory again.


signature.asc
Description: PGP signature

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Sam James]

Antonin Décimo  writes:

> Le mar. 30 avr. 2024 à 15:01, Sam James  a écrit :
>>
>> Paul Eggert  writes:
>>
>> > On 2024-04-26 08:10, Zack Weinberg wrote:
>> >
>> >> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
>> >> Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
>> >> unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
>> >> test fails, and __STDC_NO_VLA__ was not defined by the compiler,
>> >> then AC_DEFINE([__STDC_NO_VLA__], 1)
>> >
>> > Although the basic strategy sounds reasonable, AC_PROG_CC is
>> > documented to operate by setting compiler options not via AC_DEFINE,
>> > so presumably this should put -D__STDC_NO_VLA__ into $CC rather than
>> > use AC_DEFINE.
>> >
>> > I installed the attached patch, which is less ambitious but should
>> > address the original problem report. The attached patch doesn't
>> > preclude your suggestion, which can be done later as needed.
>> >
>> > [2. text/x-patch; 0001-Port-better-to-MSVC.patch]...
>>
>> Note that "or later" isn't right -- C23 makes VLAs mandatory again.
>
> I don't think that's true… Wikipedia links to the paper modifying the
> standard:
>
>> For these reasons, we propose to make variably-modified types
>> mandatory in C23. VLAs with automatic storage duration remain an
>> optional language feature due to their higher implementation
>> overhead and security concerns on some implementations (i.e. when
>> allocated on the stack and not using stack probing).
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

You're right - I confused VLAs with VMTs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896#c13.

Thanks!

>
> Best regards,
> Antonin


signature.asc
Description: PGP signature