[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130620163844.GZ29800@brightrain.aerifal.cx>
Date: Thu, 20 Jun 2013 12:38:44 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: gnulib cross-compiling issue with musl
On Thu, Jun 20, 2013 at 12:08:51PM -0400, Anthony G. Basile wrote:
> I see your point wrt no __MUSL__ macro, but in practice this is a
> tough one to live with. It is not just gnulib that makes
> assumptions about libc, although needing the internals of FILE is
> extreme given that implementation details are subject to change.
> Most of what I'm hitting porting Gentoo over are assumptions about
> what is provided or where it is provide or how it is provided (and
> standards be damned), and I can't play the usual game of #ifdef
> __MUSL__ as I did for uclibc.
Can you give me some examples? My experience with people trying to
determine these things has been that the assumption they wanted to
make using "#ifdef __MUSL__" was outdated by the time the next version
of musl was released. Tests of the form
#ifdef __MUSL__
/* interface foo is available */
#endif
would of course be relatively stable, as long as "foo" is a public
interface and not some internal interface you found and decided to
play with. However, tests of the form
#ifdef __MUSL__
/* assume interface or feature foo is not available */
#endif
would almost surely be wrong at some point in the future. Depending on
how you use the assumption, either build might break with future
versions of musl (for example, if you redefine something that was
missing from the headers), or you might omit features of the
application that would otherwise work with future versions of musl,
and if you fail to fully maintain the #ifdefs, a user of musl 1.5.0
next year building your package might be stuck with the featureset of
musl 0.9.10.
> I know you might respond with "that's
> what build systems are for", but ... ouch ... Not to derail, but
> gnulib was the my first experience of a sequence.
Most packages have configure scripts that can detect the presence or
absence of public interfaces easily, in ways that fully work with
cross-compiling. The packages that fail to do so are mostly core
Linux-specific components where the author assumed Linux==glibc. For
anything non-Linux-specific, lack of a configure script (or similar
build process) would basically mean either it only runs on the
author's system, or it's taken extreme care only to use standard POSIX
interfaces (and only the ones that aren't broken on major pseudo-POSIX
systems like OSX...).
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.
