From: Isaac Dunham <idunham@lavabit.com>
To: musl@lists.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC.
Date: Tue, 4 Dec 2012 15:01:22 -0800 [thread overview]
Message-ID: <20121204150122.04c11f37.idunham@lavabit.com> (raw)
In-Reply-To: <20121204214522.GJ20323@brightrain.aerifal.cx>
On Tue, 4 Dec 2012 16:45:22 -0500
Rich Felker <dalias@aerifal.cx> 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.
<snip>
> > 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 <idunham@lavabit.com>
next prev parent reply other threads:[~2012-12-04 23:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 2:21 idunham
2012-12-01 2:04 ` Rob Landley
2012-12-01 4:06 ` Rich Felker
2012-12-01 8:18 ` Isaac Dunham
2012-12-04 20:48 ` Rob Landley
2012-12-04 21:45 ` Rich Felker
2012-12-04 23:01 ` Isaac Dunham [this message]
2012-12-04 23:22 ` Rich Felker
2012-12-05 0:58 ` Rob Landley
-- strict thread matches above, loose matches on Subject: below --
2012-11-29 20:50 Rob Landley
2012-11-29 21:15 ` Justin Cormack
2012-11-29 21:51 ` Luca Barbato
2012-11-30 1:30 ` Rich Felker
2012-12-01 0:04 ` Rob Landley
2012-11-30 9:21 ` Rob Landley
2012-11-30 11:08 ` Szabolcs Nagy
2012-12-01 2:00 ` Rob Landley
2012-11-30 1:27 ` Rich Felker
2012-11-30 8:11 ` Truls Becken
2012-11-30 14:29 ` Luca Barbato
2012-11-30 19:05 ` Rich Felker
2012-11-30 20:16 ` nwmcsween
2012-11-30 20:20 ` Rich Felker
2012-11-30 20:32 ` nwmcsween
2012-11-30 20:25 ` Szabolcs Nagy
2012-11-30 20:26 ` Rich Felker
2012-11-30 21:14 ` Luca Barbato
2012-11-30 21:26 ` Rich Felker
2012-12-01 0:04 ` Rob Landley
2012-11-30 4:38 ` Jens Staal
2012-11-30 7:08 ` Daniel Bainton
2012-11-30 13:26 ` Hiltjo Posthuma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121204150122.04c11f37.idunham@lavabit.com \
--to=idunham@lavabit.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).