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.