[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <emd066d42c-4dbc-468a-b93a-2aebbdaa72e1@elzian>
Date: Wed, 23 Sep 2020 08:49:10 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Re: OS detection wrong on Alpine Linux 3.10
>All I need is GNU Make and preprocessor macros. It is a marriage made in heaven.
That works until you rely on features you cannot detect at compile
time. Example: the presence of a flock(), memmem(), or getpeereid()
function.
If you're only writing for Linux, you can generally get by, more or
less, with preprocessor macros and duct tape. If you're attempting to
write portable programs, however, you can run into a wall very fast.
>> If a project relies on implementation-defined behaviour and does not
>> perform detection, then it is broken and needs to be fixed. If its
>> build system does not allow it to perform detection, then it needs to
>> switch to a better build system.
>
>Again, your opinion.
It's really not. I did *not* enjoy writing my own configure scripts,
I would gladly have relied on preprocessor macros like a lot of
projects out there. Unfortunately, it soon appeared that doing so
would not be enough to meet my requirements of portability and
correctness, and that performing feature detection was a necessary evil.
My opinion, if you want to know it, is that it's a failure of
operating systems to have diverged that much and force programmers to
jump through hoops in order to be compatible across them, and that we
are collectively paying the price (technical debt) of commercial-based
and ego-based decisions. I hate it, but it's not in my power to change
it, and I have to adapt. And if I don't, the people who package my
software for various distributions will have to do the work for me; and
they're overloaded enough as is.
> I have build systems that work perfectly except
>when I have to jump through hoops for Musl.
That's a common misconception. The reality is that you have been
vendor-locked-in and lulled into a false sense of correctness; and
when porting your programs to musl, you are experiencing trouble
because of your reliance on proprietary (in spirit) extensions and
behaviours that musl does not match.
Do your programs also work perfectly, without patching, on various
BSDs? on MacOS? on Solaris? Do they work perfectly when cross-building?
Don't blame this on musl; blame it on the system that locked you in
and gave you bad habits.
>You are trying to set policy for me.
I'm being purely descriptive, and am only setting the necessary
policies for building correct, cross-buildable, portable projects.
>All I need to know is what version of Musl I am dealing with and I can
>configure myself.
Are you willing to maintain an #ifdef forest for all the versions of
all the libcs and all the kernels your programs may be used with, so
you can list exhaustively the available features in every configuration?
Because that's where your model leads. ;)
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
