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

s no actual arm64 hardware 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/ __

Re: Global autoconf cache

it could determine the BUILD and HOST arches itself then read the appropriate thing if needed). 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,

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

ks 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 -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

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

s of things, but they are problematic for distro build defaults, so there is a good reason 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 ju

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

project? If you do this do remember that we want it to work on multiarch systems too, where sysroot is not used (equivalent to sysroot=/) > Does this sound viable and acceptable for inclusion ? > Or is there another 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

all the build-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

orks in both cases. I don't know if there is 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?

uild, documented 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

c with the surrounding 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

m. 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. 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

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

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

actually 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

rs now so it's not yet clear to me why that cannot continue. And even 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: On time64 and Large File Support

existance of i686 as a build target. Right. > 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

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