Why there's no __MUSL__ macro question

Why there's no __MUSL__ macro question

[Sérgio Marques]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Hi all,

I've seen that there's already a topic on

http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F

but I would like to understand the reasoning for not having it defined.

Maybe by explaining my use case someone can explain why the macro is not
needed:

I has installing an *R* package in an Alpine linux distribution that uses
musl. That R package needed to be compiled using musl

"Command failed (1)

Failed to run system command:

'/usr/lib/R/bin/R' --vanilla CMD INSTALL '/tmp/RtmpDPDGNf/Rcpp'
--library='/app/packrat/lib/x86_64-alpine-linux-musl/3.2.3' --install-tests
--no-docs --no-multiarch --no-demo

The command failed with output:
* installing *source* package 'Rcpp' ...
** package 'Rcpp' successfully unpacked and MD5 sums checked
** libs
x86_64-alpine-linux-musl-g++ -I/usr/lib/R/include -DNDEBUG
-I../inst/include/ -Os -fomit-frame-pointer    -fpic  -Os
-fomit-frame-pointer  -c Date.cpp -o Date.o
x86_64-alpine-linux-musl-g++ -I/usr/lib/R/include -DNDEBUG
-I../inst/include/ -Os -fomit-frame-pointer    -fpic  -Os
-fomit-frame-pointer  -c Module.cpp -o Module.o
x86_64-alpine-linux-musl-g++ -I/usr/lib/R/include -DNDEBUG
-I../inst/include/ -Os -fomit-frame-pointer    -fpic  -Os
-fomit-frame-pointer  -c Rcpp_init.cpp -o Rcpp_init.o
x86_64-alpine-linux-musl-g++ -I/usr/lib/R/include -DNDEBUG
-I../inst/include/ -Os -fomit-frame-pointer    -fpic  -Os
-fomit-frame-pointer  -c api.cpp -o api.o
api.cpp:40:30: fatal error: execinfo.h: No such file or directory
compilation terminated.
/usr/lib/R/etc/Makeconf:141: recipe for target 'api.o' failed
make: *** [api.o] Error 1
ERROR: compilation failed for package 'Rcpp'
* removing '/app/packrat/lib/x87_64-alpine-linux-musl/3.2.3/Rcpp'"

It happens that the failure is todo with the fact that is no macro in
api.cpp which uniquely identifies we're in a distribution that is using
musl, so the compiler ends up executing some code invalid for that
arquitecture/distribution.

How are we expected to solve this kind of problem if not by using the
__MUSL__ macro?

Thanks in advance.

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]

Re: Why there's no __MUSL__ macro question

[Kurt H Maier]

On Wed, Mar 23, 2016 at 01:08:16PM +0000, Sérgio Marques wrote:
> 
> How are we expected to solve this kind of problem if not by using the
> __MUSL__ macro?

The recommended solution is to fix the code to be portable, instead of
installing yet another special-case workaround.

In this case, wrapping the "#include <execinfo.h>" line in an
#ifdef __GLIBC__ would be more appropriate than special-casing for musl,
since musl is not the only environment that lacks execinfo.h.  I suspect
this code would also fail to build on cygwin, for instance.

If there existed a __MUSL__ macro, the maintainers of software like this
would just use it instead of writing portable code.  By refusing to
implement a __MUSL__ macro, musl is helping to urge projects in the
right direction.

khm

Re: Why there's no __MUSL__ macro question

[Shiz]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]


> On 23 Mar 2016, at 14:28, Kurt H Maier <khm@sdf.org> wrote:
> 
> On Wed, Mar 23, 2016 at 01:08:16PM +0000, Sirgio Marques wrote:
>> 
>> How are we expected to solve this kind of problem if not by using the
>> __MUSL__ macro?
> 
> The recommended solution is to fix the code to be portable, instead of
> installing yet another special-case workaround.
> 
> In this case, wrapping the "#include <execinfo.h>" line in an
> #ifdef __GLIBC__ would be more appropriate than special-casing for musl,
> since musl is not the only environment that lacks execinfo.h.  I suspect
> this code would also fail to build on cygwin, for instance.
> 
> If there existed a __MUSL__ macro, the maintainers of software like this
> would just use it instead of writing portable code.  By refusing to
> implement a __MUSL__ macro, musl is helping to urge projects in the
> right direction.
> 
> khm

Alternatively, a better approach would be the detection of <execinfo.h>’s
existence by something like ./configure and defining a HAVE_EXECINFO_H macro
as a result that the file can use. That way you’re not cluttering the source
files with platform-specific information.

- Shiz

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Why there's no __MUSL__ macro question

[Rich Felker]

On Wed, Mar 23, 2016 at 03:17:58PM +0100, Shiz wrote:
> 
> > On 23 Mar 2016, at 14:28, Kurt H Maier <khm@sdf.org> wrote:
> > 
> > On Wed, Mar 23, 2016 at 01:08:16PM +0000, Sirgio Marques wrote:
> >> 
> >> How are we expected to solve this kind of problem if not by using the
> >> __MUSL__ macro?
> > 
> > The recommended solution is to fix the code to be portable, instead of
> > installing yet another special-case workaround.
> > 
> > In this case, wrapping the "#include <execinfo.h>" line in an
> > #ifdef __GLIBC__ would be more appropriate than special-casing for musl,
> > since musl is not the only environment that lacks execinfo.h.  I suspect
> > this code would also fail to build on cygwin, for instance.
> > 
> > If there existed a __MUSL__ macro, the maintainers of software like this
> > would just use it instead of writing portable code.  By refusing to
> > implement a __MUSL__ macro, musl is helping to urge projects in the
> > right direction.
> 
> Alternatively, a better approach would be the detection of <execinfo.h>’s
> existence by something like ./configure and defining a HAVE_EXECINFO_H macro
> as a result that the file can use. That way you’re not cluttering the source
> files with platform-specific information.

Indeed, hard-coding __GLIBC__ is not really a lot better. One of the
biggest problems with a hypothetical __MUSL__ is hard-coding
assumptions that "musl lacks X" (which can become false in the
future). A better approach is testing the the interface you want to
use. This can be done purely with makefile logic if you don't like
autotools.

Rich