[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121204232245.GK20323@brightrain.aerifal.cx>
Date: Tue, 4 Dec 2012 18:22:45 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from
IRC.
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.
> <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.
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
