mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Laurent Bercot" <ska-dietlibc@skarnet.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Re: OS detection wrong on Alpine Linux 3.10
Date: Wed, 23 Sep 2020 08:49:10 +0000	[thread overview]
Message-ID: <emd066d42c-4dbc-468a-b93a-2aebbdaa72e1@elzian> (raw)
In-Reply-To: <CAH8yC8=T+ou5_3UGXn1Tj5=531_qtLZV5vJ9v9_KL7xE=4ELBQ@mail.gmail.com>

>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


  reply	other threads:[~2020-09-23  8:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4768019.hHWyC0TzgU@omega>
2020-09-20 10:12 ` Dmitry V. Levin
2020-09-20 11:19   ` Bruno Haible
2020-09-20 12:18     ` Ariadne Conill
2020-09-20 13:56     ` Szabolcs Nagy
2020-09-20 17:14       ` Rich Felker
2020-09-20 19:21         ` Bruno Haible
2020-09-20 20:58           ` Hadrien Lacour
2020-09-21  6:53           ` A. Wilcox
2020-09-21 11:46             ` Florian Weimer
2020-09-22 18:46           ` Rich Felker
2020-09-22 20:18             ` Bruno Haible
2020-09-22 20:33               ` Jeffrey Walton
2020-09-22 20:39             ` Jeffrey Walton
2020-09-22 21:04               ` Laurent Bercot
2020-09-22 21:17                 ` Jeffrey Walton
2020-09-23  8:49                   ` Laurent Bercot [this message]
2020-09-23 13:13                     ` James Y Knight
2020-09-23 16:08                       ` Rich Felker
2020-09-23 16:16                         ` Jeffrey Walton
2020-09-23 16:26                           ` Ariadne Conill
2020-09-23 16:57                             ` Jeffrey Walton
2020-09-23 16:36                           ` Rich Felker
2020-09-20 12:19   ` Ariadne Conill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emd066d42c-4dbc-468a-b93a-2aebbdaa72e1@elzian \
    --to=ska-dietlibc@skarnet.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).