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
). 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
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
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
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
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
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
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
_
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
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
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
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
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
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
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
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
16 matches
Mail list logo