From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2405 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC. Date: Tue, 4 Dec 2012 18:22:45 -0500 Message-ID: <20121204232245.GK20323@brightrain.aerifal.cx> References: <20121201040620.GE20323@brightrain.aerifal.cx> <1354654133.27682.6@driftwood> <20121204214522.GJ20323@brightrain.aerifal.cx> <20121204150122.04c11f37.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 X-Trace: ger.gmane.org 1354663379 14248 80.91.229.3 (4 Dec 2012 23:22:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2012 23:22:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2406-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 05 00:23:12 2012 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 1Tg1pW-0003Vi-0l for gllmg-musl@plane.gmane.org; Wed, 05 Dec 2012 00:23:10 +0100 Original-Received: (qmail 11289 invoked by uid 550); 4 Dec 2012 23:22:57 -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 11281 invoked from network); 4 Dec 2012 23:22:57 -0000 Content-Disposition: inline In-Reply-To: <20121204150122.04c11f37.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2405 Archived-At: On Tue, Dec 04, 2012 at 03:01:22PM -0800, Isaac Dunham wrote: > > > - c99 compiler with support for gcc-style assembly language. > > Also needs weak symbols. Yes, thanks for pointing this out. > In real life this works out to "gcc, clang, or pcc"; there are > unidentified issues with Open64, icc might or might not work, and > same for Path64 and Sun Studio for Linux. I suspect firm is very close to working, and tinycc mob branch might also be close to working. icc is almost surely working unless there's some trivial issue; it supports everything we need. The Open64 (or was it path?) issues seem to be generating spurious relocations in the shared library; it should be working fine for static linking. > > > It would be nice if there was some kind of "musl manual". If you > > > want to write a program against the musl libc, what does it provide? > > > (HTML is fine, man page format is kinda archaic these days. This is > > > mostly posix, but not entirely.) > > For some folks, but not all. > (I prefer local documentation that can be viewed without a web-browser...) I think markdown, or something roughly equivalent, would be preferred. HTML and other formats could be generated from it if needed. > I still think that documenting what functions we support should be > mainly done in the linux-manpages project, which has fairly good > coverage and notes libc differences. What do you mean by this? You want linux-manpages to cover documenting what musl supports? > > In addition to this, certain functions in the standards have > > implementation-defined behaviors, which means an implementation is > > required to document what behavior it provides. One thing we should > > definitely document is iconv and locale behavior. Compiling a complete > Speaking of which, will musl support the "ASCII" and "" aliases for the C locale, or is that just bloat? (iirc, these were the issues with R that made libiconv necessary) > > list of the implementation-defined behavior musl needs to document > > would be a good project someone could help out with between now and > > 1.0. > > > > Dynamic vs static linking, "what is a dynamic linker and wazzit > > > _do_". Something on the whole "how to tell if your binary is built > > > against musl or some other libc, how to tell if it's statically or > > > dynamically linked" (fun with ldd and readelf -a), long ago I wrote > > > an intro to cross compiling if that's worth linking to... Stuff. > > > > Yes, the "how to tell what libc a binary is linked against?" is > > actually a really good FAQ topic (a question that really arises > > frequently). > > I use "strings $BINARY | grep ld.*so"; this lets me see the libc > required to run it (or if it's static) as well as arch. Well for static binaries, there's a lot more work. Also, incorrectly built (broken toolchain) dynamic-linked musl binaries could show /lib/ld-linux.so.2 as the program interpreter and "mostly" work (breaking in subtle ways) as long as the glibc dynamic linker is present on the system, so a good FAQ answer would at least cover this possibility and how to check for it. Rich