From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2985 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Will musl work as a lsb alternative? (was Re: [musl] re: musl setup attempt) Date: Wed, 27 Mar 2013 08:58:25 -0500 Message-ID: <1364392705.18069.0@driftwood> References: <20130326184037.b97e4c63.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1364392729 26025 80.91.229.3 (27 Mar 2013 13:58:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 13:58:49 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-2986-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 27 14:59:15 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UKqse-0003eU-1N for gllmg-musl@plane.gmane.org; Wed, 27 Mar 2013 14:59:08 +0100 Original-Received: (qmail 5533 invoked by uid 550); 27 Mar 2013 13:58:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5525 invoked from network); 27 Mar 2013 13:58:41 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=UKmVU1gVerEX8p67jhmePWMhgLOMAsN8lkGPt0505XQ=; b=HyRd6MFV68GDHIaagAFlZBGCzOO4gN7sfwuoPGVoSI5B23peKN+hjNlMeWxH0Fxeue gihAO0LfP0O4AEUDuJY9YfvrfirHfM51L7IXTK5I+vlpmLE0aJtoIhewXPEbHsp4oKAa tOBIuDYJtngwJ06o1NA11qGrk3YRuiytPh9OSBYt1PU8VfICXkXuMiVqRu70lazl3T35 SvfJsms34sV05V/K67ZKiUilRU7K28s8D7DcntTESPfg+xy6R5wNEooU9WeB5hlECEJR oW2xrqbNaAvnZXpxPLlPTTDpA2CpSzFOyMmUPqEx2yntshhhNHMfNIFYcYUGmyW3BP8P l/rA== X-Received: by 10.50.192.138 with SMTP id hg10mr4093356igc.95.1364392709014; Wed, 27 Mar 2013 06:58:29 -0700 (PDT) In-Reply-To: <20130326184037.b97e4c63.idunham@lavabit.com> (from idunham@lavabit.com on Tue Mar 26 20:40:37 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQm3omuqaFYyYUUcBbHL2eoLi780mNmaJmOrNbfibe2YgQYYpemAReZsZFgdKoRignYcMTgT Xref: news.gmane.org gmane.linux.lib.musl.general:2985 Archived-At: On 03/26/2013 08:40:37 PM, Isaac Dunham wrote: > On Tue, 26 Mar 2013 19:03:28 -0400 > Rich Felker wrote: >=20 > > > > > Any suggestions, recommendations? Would I be better off sticking =20 > with > > > lsb or will musl do the job as well? Thanks for the help. > > > > Could you elaborate on what you mean by "sticking with LSB"? LSB is =20 > a > > specification for ABI, filesystem layout, etc. -- basically, what =20 > apps > > can expect from a "Linux system" -- not really a tool in itself. > Rich: > There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce =20 > binaries that > use the LSB ABI and are portable so you don't need to worry too much =20 > about glibc > symbol versioning, etc. Note that The Linux Standard base is a project of The Linux Foundation, =20 which is to Linux development what AOL was to the Internet. So expecting them to =20 define what is and isn't Linux is like Facebook saying "Blogs! Yes, that's a =20 thing I own, here's all you'll ever need to know about blogs and none of it =20 will ever live anywhere but facebook.com because I am the whole of the internet." > Laura: > If you don't want to ship any/many libraries and fully static =20 > binaries are not an > option, using lsbcc is your only otion. That does require the target =20 > distro to > provide LSB support, which is widespread but certainly not universal. I note that static linking binaries doesn't have significant downsides if you use sane libraries. For many years glibc's maintainer had very strong opinions that weren't necessarily supported by facts, but he's no longer maintainer (he left =20 to working at The Bank of Evil from "Despicable Me"), and nobody else has a problem with it. The size penalty using something like uClibc or musl is fairly small, =20 and the need to dlopen() things to make network resolution work are glibc =20 bugs that don't apply to other C libraries. > If you want binaries that can run _anywhere_, static linking with a =20 > generic > build of musl will work well (x86 musl compiles for i486 by default, =20 > although > you can change the minimum processor by setting CFLAGS to =20 > -march=3D...). These > will work to some degree as far back as 2.4.x distros (I tested on =20 > DSL), if > you don't need threading or full POSIX conformance (2.4 did not have =20 > what's > needed for full POSIX). This is actually _more_ portable than static linking against glibc, due =20 to their symbol versioning issues. > uclibc static linking will do better if supporting 2.4.x or very =20 > early 2.6.x > kernels is a high priority, though it's not fully POSIX conformant, =20 > LGPL > (requires distributing application source code or object file so =20 > customers > can relink), and slightly larger. Don't think about a uclibc shared =20 > binary > if you want portability; that way lies madness. I have prebuilt uClibc toolchains at http://landley.net/aboriginal/bin =20 (the cross-compiler-$ARCH.tar.bz2 files) if you want to try that. Add the =20 "bin" subdirectory of that tarball to your $PATH and use CROSS_COMPILE=3D$ARCH- =20 as your prefix (and yes you need the trailing dash on the prefix name or =20 it'll try to use i686cc instead of i686-cc). > Dynamically linked musl binaries are only going to work out-of-box on =20 > musl > systems or for those who installed musl with the same syslibdir; > it is possible to use the path/to/libc.so trick or an ELF =20 > editor > to circumvent this. Currently, you might want to include most of the > libraries if you go for this. Doing so is totally not worth it. If you put together a distro that =20 uses musl, distributing musl shared binaries makes sense. Otherwise, static =20 linking is not a bad thing. If people tell you it is, they probably got bad (stale) advice from the ex-glibc maintainer. Really: significant effort to avoid static linking -- not worth it. Rob=