From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2982 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Will musl work as a lsb alternative? (was Re: [musl] re: musl setup attempt) Date: Tue, 26 Mar 2013 19:03:28 -0400 Message-ID: <20130326230328.GP20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364339029 31078 80.91.229.3 (26 Mar 2013 23:03:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 23:03:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2983-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 27 00:04:14 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 1UKcub-0007tQ-Tu for gllmg-musl@plane.gmane.org; Wed, 27 Mar 2013 00:04:14 +0100 Original-Received: (qmail 24461 invoked by uid 550); 26 Mar 2013 23:03:47 -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 24416 invoked from network); 26 Mar 2013 23:03:41 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2982 Archived-At: On Tue, Mar 26, 2013 at 09:02:29AM -0400, LM wrote: > On 3/14/13, Szabolcs Nagy wrote: > > if exec fails then something is wrong before the application > > starts, maybe you can see what happens if you strace the > > loader, which you can do by > > > > strace path/to/libc.so wavpack > > Thanks for the suggestion. Found the problem. Bad link during > installation. It's working fine now. > > I've built some applications with musl and so far, it's working really > well. What I'm really curious about and one of the reasons I wanted > to try musl out was that I was wondering if it could be used to do > some of the things lsb proponents say lsb (Linux Systems Base) can do. Yes and no. > Specifically, I'd like to be able to build applications with the > compiler and have them work if I take them to any ix86 system. So, if > I built the applications on a Debian system, I'd like to be able to > still run them on a Red Hat system or OpenSuse or Slackware, etc. as > long as the system uses the same type of processor. In principle, the binary should not depend on the distro it was built on/for. musl is better-equipped to give this property than glibc, since linking with glibc introduces a lot of symbol version issues that make it impossible to use the binary on a system with even slightly-older glibc, even if the older glibc, in principle, has everything it should need to run the binary. In practice, the other areas where distros differ heavily are: - which options/optional-dependencies they build various third-party libraries with. - where they store files belonging to various libraries/packages. If you're building apps against musl, then you're _probably_ not going to be using the existing library files installed by your distro unless it's a musl-based distro. You might be able to get them to work, but the main point of the partial ABI-compatibility is to allow use of "important" libraries for which you don't have source, not to allow use of the full existing ecosystem of glibc-linked libraries a distro might have. The latter may eventually be possible, but aiming for it is a lot of work with diminishing benefits.. > Am also wondering > if it would be necessary to build everything statically or whether it > would work dynamically if all required libraries were available on the > target system. Another option might be to build an application with > the C library linked in statically and the rest of the libraries > dynamic. Still looking into pros and cons for the various options. There's presently no support for static linking libc but still using dynamic linking. Adding support is not impossible, but also not easy. Anyway, for what you're talking about, it's really not necessary. Full dynamic linking will work, but you probably want to be providing the libraries. > If this sounds feasible, my next question is about building musl to > handle C++. I read in the list archives that there was a successful > C++ build. I also read this can't be done as a wrapper. Found the > list of cross-compilers at ( See Gregor's musl-cross repository. It contains the gcc patches and build scripts to get a compiler with C++ support targetting musl. This works for building native compilers too. If you get stuck, feel free to ask for help on the IRC channel; it's very active. > http://wiki.musl-libc.org/wiki/Getting_started ) and was thinking the > crossx86-i486-linux-musl-0.9.9.tar.xz might do the trick. However, > are there any instructions for building the cross-compilers and the > C++ implementation like there are for the install information? Would > like to try to build the C/C++ cross-compilers from source. Am hoping > they can coexist with my current gnu C/C++ compiler on my Debian > system the way the lsb compilers coexist with it. Yes, just install them in their own location. > Any suggestions, recommendations? Would I be better off sticking 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 a specification for ABI, filesystem layout, etc. -- basically, what apps can expect from a "Linux system" -- not really a tool in itself. Rich