for the wiki: a __MUSL__ alternative

for the wiki: a __MUSL__ alternative

[writeonce]

Greetings,

Since requests for a __MUSL__ macro still come in every now and then, I 
thought it might be useful to add to the wiki the following text at the 
end of the section "why is there no __MUSL__ macro?"

If you have a situation that (temporarily) requires that you can 
identify the libc being used, consider the following trick: as part of 
your configuration script, locate libc.so, then create a symlink from 
libc.so to /some/temporary/folder/ldd, and finally execute 
/some/temporary/folder/ldd 2>&1 | grep 'musl libc';  Based on the 
outcome, you could then add -D__MUSL__ to the relevant environment variable.

I hope that helps,
zg

Re: for the wiki: a __MUSL__ alternative

[Rich Felker]

On Thu, May 01, 2014 at 03:41:19AM -0400, writeonce@midipix.org wrote:
> Greetings,
> 
> Since requests for a __MUSL__ macro still come in every now and
> then, I thought it might be useful to add to the wiki the following
> text at the end of the section "why is there no __MUSL__ macro?"
> 
> If you have a situation that (temporarily) requires that you can
> identify the libc being used, consider the following trick: as part
> of your configuration script, locate libc.so, then create a symlink
> from libc.so to /some/temporary/folder/ldd, and finally execute
> /some/temporary/folder/ldd 2>&1 | grep 'musl libc';  Based on the
> outcome, you could then add -D__MUSL__ to the relevant environment
> variable.

The whole point of the wiki answer is that doing this is wrong. Adding
a "here's a way to do it anyway" rather defeats the purpose and is
just going to get us more trouble in the long term. In any case, this
only works when dynamic linking is available, and it requires the
ability to run programs for the target which breaks cross compiling
and therefore violates one of the biggest rules for built scripts.

Rich

Re: for the wiki: a __MUSL__ alternative

[writeonce]

On 05/01/2014 08:51 AM, Rich Felker wrote:
> On Thu, May 01, 2014 at 03:41:19AM -0400, writeonce@midipix.org wrote:
>> Greetings,
>>
>> Since requests for a __MUSL__ macro still come in every now and
>> then, I thought it might be useful to add to the wiki the following
>> text at the end of the section "why is there no __MUSL__ macro?"
>>
>> If you have a situation that (temporarily) requires that you can
>> identify the libc being used, consider the following trick: as part
>> of your configuration script, locate libc.so, then create a symlink
>> from libc.so to /some/temporary/folder/ldd, and finally execute
>> /some/temporary/folder/ldd 2>&1 | grep 'musl libc';  Based on the
>> outcome, you could then add -D__MUSL__ to the relevant environment
>> variable.
> The whole point of the wiki answer is that doing this is wrong. Adding
> a "here's a way to do it anyway" rather defeats the purpose and is
> just going to get us more trouble in the long term. In any case, this
> only works when dynamic linking is available, and it requires the
> ability to run programs for the target which breaks cross compiling
> and therefore violates one of the biggest rules for built scripts.
>
> Rich
>
>
You are absolutely right, and my thought was to provide a _temporary_ 
solution until everyone get convinced...  but I certainly see your 
point.  It later occurred to me that this won't work with 
cross-compilation, and while there is an even more deviant trick for 
that scenario as well, this time I'm keeping it to myself;-)

zg

Re: for the wiki: a __MUSL__ alternative

[Oliver Schneider]

Hey Rich,

On 2014-05-01 12:51, Rich Felker wrote:
> The whole point of the wiki answer is that doing this is wrong. Adding
> a "here's a way to do it anyway" rather defeats the purpose and is
> just going to get us more trouble in the long term. In any case, this
> only works when dynamic linking is available, and it requires the
> ability to run programs for the target which breaks cross compiling
> and therefore violates one of the biggest rules for built scripts.
you're right and I admire how steadfast you are in your resolve.

Initially I desired to have this myself so that I could give attribution
within the program depending on whether it was built with musl-libc or
another libc. Right now I have simple used a define on the command line
to tell whether it's a build with musl-libc or not.

Also, I don't think the proposed solution is very elegant. In this case
it'd be better to pass parameters using the specs file, no?

// Oliver

Re: for the wiki: a __MUSL__ alternative

[Khem Raj]

On Fri, May 2, 2014 at 3:44 AM, Oliver Schneider
<musl-mailinglist@f-prot.com> wrote:
> Right now I have simple used a define on the command line
> to tell whether it's a build with musl-libc or not.

I think this is a OK approach, lot of software identify the libc and
take actions for configuring
so if we have to compile existing software we have to try to fix the
package which may not be possible
always but not defining it may help cleaning up the libc identifying
define in packages

Re: for the wiki: a __MUSL__ alternative

[writeonce]

On 05/02/2014 06:44 AM, Oliver Schneider wrote:
> Hey Rich,
>
> On 2014-05-01 12:51, Rich Felker wrote:
>> The whole point of the wiki answer is that doing this is wrong. Adding
>> a "here's a way to do it anyway" rather defeats the purpose and is
>> just going to get us more trouble in the long term. In any case, this
>> only works when dynamic linking is available, and it requires the
>> ability to run programs for the target which breaks cross compiling
>> and therefore violates one of the biggest rules for built scripts.
> you're right and I admire how steadfast you are in your resolve.
>
> Initially I desired to have this myself so that I could give attribution
> within the program depending on whether it was built with musl-libc or
> another libc. Right now I have simple used a define on the command line
> to tell whether it's a build with musl-libc or not.
>
> Also, I don't think the proposed solution is very elegant. In this case
> it'd be better to pass parameters using the specs file, no?
>
> // Oliver
>
>
As far as elegance goes, you're right (I wasn't aiming at too much 
elegance with that kind of a temporary solution).  But if I understand 
you correctly(*), two reasons not to use the .specs file are: 1) there 
are native musl compilers that do not use the wrapper's .specs file; and 
2) by turning __MUSL__ into a built-in macro of such native compilers, 
and likewise by defining __MUSL__ in the .specs file, you'll be making 
the macro available to everybody without requiring extra effort, which I 
believe is what we'd like to avoid.

(*) I read 'specs' as a reference to musl-gcc.specs

-zg (regretfully for bringing this up in the first place...)