* Why there's no __MUSL__ macro question
@ 2016-03-23 13:08 Sérgio Marques
2016-03-23 13:28 ` Kurt H Maier
0 siblings, 1 reply; 4+ messages in thread
From: Sérgio Marques @ 2016-03-23 13:08 UTC (permalink / raw)
To: musl
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why there's no __MUSL__ macro question
2016-03-23 13:08 Why there's no __MUSL__ macro question Sérgio Marques
@ 2016-03-23 13:28 ` Kurt H Maier
2016-03-23 14:17 ` Shiz
0 siblings, 1 reply; 4+ messages in thread
From: Kurt H Maier @ 2016-03-23 13:28 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why there's no __MUSL__ macro question
2016-03-23 13:28 ` Kurt H Maier
@ 2016-03-23 14:17 ` Shiz
2016-03-23 15:05 ` Rich Felker
0 siblings, 1 reply; 4+ messages in thread
From: Shiz @ 2016-03-23 14:17 UTC (permalink / raw)
To: musl
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Why there's no __MUSL__ macro question
2016-03-23 14:17 ` Shiz
@ 2016-03-23 15:05 ` Rich Felker
0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2016-03-23 15:05 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-03-23 15:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-23 13:08 Why there's no __MUSL__ macro question Sérgio Marques
2016-03-23 13:28 ` Kurt H Maier
2016-03-23 14:17 ` Shiz
2016-03-23 15:05 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).