[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51C32913.9050603@opensource.dyc.edu>
Date: Thu, 20 Jun 2013 12:08:51 -0400
From: "Anthony G. Basile" <basile@...nsource.dyc.edu>
To: musl@...ts.openwall.com
Subject: Re: Re: gnulib cross-compiling issue with musl
On 06/18/2013 02:42 PM, Rich Felker wrote:
> On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote:
>
> I'm saying that musl intentionally does not provide any macros to
> identify itself. Changing this to help gnulib do one correct thing
> would not be worth dealing with all the incorrect usages it would lead
> to. And I'm confident that presence of such a macro would lead to lots
> of bugs in lots of applications, and to people blaming us for changing
> things when such incorrect applications break, on the basis of all the
> requests we have received from users for a __MUSL__ macro. In every
> case, we have been able to recommend clean portable solutions that did
> not involve hard-coding assumptions about musl.
>
Hi Rich,
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. 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.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
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.
