Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.