From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2404 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC. Date: Tue, 4 Dec 2012 15:01:22 -0800 Message-ID: <20121204150122.04c11f37.idunham@lavabit.com> References: <20121201040620.GE20323@brightrain.aerifal.cx> <1354654133.27682.6@driftwood> <20121204214522.GJ20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354662096 3394 80.91.229.3 (4 Dec 2012 23:01:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2012 23:01:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2405-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 05 00:01:49 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 1Tg1Uq-0000UN-RN for gllmg-musl@plane.gmane.org; Wed, 05 Dec 2012 00:01:48 +0100 Original-Received: (qmail 1868 invoked by uid 550); 4 Dec 2012 23:01:36 -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 1860 invoked from network); 4 Dec 2012 23:01:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=lz9TBIP3PiuNVk+obAbwK+/xDVZLKROAuLOse5YJ4jXVSRD4IsWxK5lX2MO8FUo2UxFWKm242uwU60msDr3lQEUnjtALuJPWwo3krsSepgUaSJ9S/GORNjzL0UMEuyCeOIDFAQd8ISqcKMhiUSkfy++QBXEVFKjX1AKbyVmm/4I=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20121204214522.GJ20323@brightrain.aerifal.cx> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2404 Archived-At: On Tue, 4 Dec 2012 16:45:22 -0500 Rich Felker wrote: > > The "what are musl's dependencies" faq entry is a mix of bullet > > points and non-bullet point material that doesn't just clarify the > > bullet points. It doesn't mention what "make" you need (posix-2008 > > compliance should be enough?) and the shell is implicit (does _not_ > > need bash, posix-2008 again good enough?). Did we actually test > > Linux 2.6.0? > > Make needs to be GNU make or compatible. Writing makefiles for POSIX > make is an exercise in wasting maintenance time; there's no way to > write general or wildcard based rules. As far as I know, it should > work even with ancient versions of GNU make (pre-GPL3), and would > probably work with a minimal clone of GNU make (but GNU make itself is > already very light and portable). I've used GNU make 3.80, which is the earliest one is _likely_ to encounter (except on distros from last century). Debian Squeeze still uses 3.81, which is pre-GPL3. > Shell is not really required at all since you can write your own > config.mak based on the sample one. Configure is intended to require > just POSIX sh, not anything from bash; I've never even used it with > bash myself. configure works with Busybox and Debian ash, all 3 ksh variants (PD/MirBSD and ksh93), bash... basically every POSIX-style shell except posh, which apparently doesn't support one of the signals we trap. (If I can figure out which one, I'll report it as a bug: posh is supposed to be "Debian Policy" conformant, which is a minimally extended superset of POSIX.) > > - c99 compiler with support for gcc-style assembly language. Also needs weak symbols. 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. > > 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...) > Yes, this would be covered in the proposed manual, an outline for > which I posted to this list a couple weeks back. Right now I'm leaning > towards having it be my main project between the last 0.9.x release > and 1.0, to have a major addition for 1.0 (the manual) without the > risk of regressions from major code changes. > > > If we're not up to writing something, w link to the POSIX spec with > > the list of functions we've implemented, plus the man7 pages on the > > linux variations thereof (and system calls) and maybe the Linux > > Standard Base sort of collectively covers it. > > Basically, my idea is that the manual will "defer to POSIX and ISO C" > on functions specified by them, with specific notes on extended > behavior in these functions beyond what the standards require. For > nonstandard functions, early versions of the manual will probably > provide a list of what's provided with notes wherever they differ > significantly from the GNU or BSD functions they're modelled on. Later > we could expand this documentation to actually cite the relevant BSD > or Linux man pages. 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. > 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. -- Isaac Dunham