Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

anywhere). yes, a proper autoreconf is better for lots of reasons but it doesn't really make any difference for our purposes. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf

Re: Global autoconf cache

). Are the variables for configured BUILD and HOST arch available at the time this script is read in? I suppose I should just try this. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

break? There have been some theoretical or obscure issues brought up so far in this thread, and some history, but I haven't seen much that looks like a good enough reason not to default to use current unless configured not to (which anyone shipping a 'special' config.sub/guess can use. Wookey

Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

for the path walk. Now we could patch autoconf in Debian (and other distros patch it too) to deal with this, but the whole point of this excercise is to fix this upstream so that over time the problem will just fade into history. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM

Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)

workaround that i missed ? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

Re: autocon and sub-packages

dependencies easily available at build-time. Distro-people believe this is superior to every upstream trying to do it with their own random-version, maybe-forked embedded copy :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

Re: Hierarchical autoconf project with cross-compiled subproject

a more autotoolsy way of dealing with this. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

Re: How to update config.guess?

mented on https://wiki.debian.org/Autoreconf It's also a good idea to prod upstream to update to recent versions to save others this hassle. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature _

Re: Reautoconfing

ng world. Testing that things build with the tools now, as opposed to the tools available when the tarball was generated, demonstrates that the software can still be built from source. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature

Re: Reautoconfing

On 2020-12-20 13:37 -0800, Paul Eggert wrote: > On 12/20/20 12:25 PM, Wookey wrote: > > We realise that it was/is not the autotools design, but that design > > only works well when the auto* bits get updated reasonably often. > > Yes, the design assumes that Autoconf etc

Re: On time64 and Large File Support

On 2022-11-12 04:28 +, 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 > > the

Re: On time64 and Large File Support

6-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. I could write more, but I'll swot up a bit first :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature

Re: On time64 and Large File Support

if it is a good idea to complete both transitions in the same upheaval 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?). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature

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

ally affected by this. Is there a quick way to test? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature

Re: On time64 and Large File Support

gt; Essentially i686 with 64-bit time_t needs to be considered > an entirely new build target. Either distros want to support > to this new target as a whole, or they want to stick with > the old target. Which is essentially x32, that has existed for some years (but has had little ado

Re: On time64 and Large File Support

On 2023-03-02 21:50 -0800, Paul Eggert wrote: > On 3/2/23 19:30, Wookey wrote: > > Gnulib automatically changing the ABI for packages that use it > > (and have LFS already enabled) is deeply unhelpful... > This change to Gnulib was reverted in December[1] and that propagated in