23 Jun
2024
23 Jun
'24
12:15 a.m.
If I could say something a little more meta, and echoing an earlier
comment - autotools, configure, etc, don't do the port for you - it's up
to the author to decide and test what OS features are required, and if
something hasn't been too implicitly assumed, if a "needs this"
hasn't
been left out, then the "configure && make" process will give you the
right build for a system that is indeed, already supported. If it
doesn't build, we can interpret that as "not supported", or that the
author did not sufficiently adjust input to the build process, or test
similar-enough configurations, to get the right build for that system.
But that is not an indictment of this whole way of doing things, or the
tools themselves, necessarily. It may just mean that someone made some
fairly ordinary mistake along the way in setting up the build. Or that
the system on which we are trying to build is different in a way that
the author did not imagine.
On 06/22/2024 10:53 AM, Chet Ramey via TUHS wrote:
On 6/21/24 5:04 PM, Alexis wrote:
Chet Ramey via TUHS <tuhs(a)tuhs.org>
writes:
Sorry, i'm not sure i understand your question, particularly given
that i was writing about the situation where a fundamental part of
the build environment _hasn't_ changed .... Could you please
elaborate or rephrase?
I think we're kind of saying the same thing. The autotools can't update
dependencies if something in the environment changes, regardless of
whether
an OS update has occurred or not. That responsibility has to fall on the
admin or other tools.
On 6/20/24 7:35 PM, Alexis wrote:
If i
compile something on one of my OpenBSD boxen in the morning,
and then compile some other thing in the afternoon, without an OS
upgrade in-between, autoconf isn't going to find that libc.so has
changed in-between.
configure and config.cache compute the results for a given build
environment. If you change that, whose responsibility is it to update
the
dependencies?