From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5204 invoked from network); 23 Sep 2020 08:49:24 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Sep 2020 08:49:24 -0000 Received: (qmail 10144 invoked by uid 550); 23 Sep 2020 08:49:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10126 invoked from network); 23 Sep 2020 08:49:21 -0000 From: "Laurent Bercot" To: musl@lists.openwall.com Date: Wed, 23 Sep 2020 08:49:10 +0000 Message-Id: In-Reply-To: References: <4768019.hHWyC0TzgU@omega> <20200920135629.GI2947641@port70.net> <20200920171446.GB3265@brightrain.aerifal.cx> <2533200.g9kxISXj3W@omega> <20200922184610.GI3265@brightrain.aerifal.cx> User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrudeigddtkecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqughivghtlhhisggtsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpeeuiefhhfeuveegudejgfegudeufeevudeftdelveeifeffiedtieehteehtdevtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht Subject: Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 >All I need is GNU Make and preprocessor macros. It is a marriage made in h= eaven. 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