From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6137 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?SsO2cmcgS3JhdXNl?= Newsgroups: gmane.linux.lib.musl.general Subject: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 13:00:09 +0200 Message-ID: <541180B9.5070604@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010402090502010405090901" X-Trace: ger.gmane.org 1410433217 7261 80.91.229.3 (11 Sep 2014 11:00:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 11:00:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6150-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 13:00:11 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS26h-0001BE-7e for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 13:00:07 +0200 Original-Received: (qmail 9876 invoked by uid 550); 11 Sep 2014 11:00:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9868 invoked from network); 11 Sep 2014 11:00:04 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 Xref: news.gmane.org gmane.linux.lib.musl.general:6137 Archived-At: This is a multi-part message in MIME format. --------------010402090502010405090901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I am trying to add support for the musl toolchain to FFmpeg. FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly. After this it checks for some combinations of hardware and the probed libc to set some more compile options, if necessary. I know that musl does not have a macro __MUSL__ and I have read the explanation. However, I don't understand what's meant by "[..] it's a bug to assume a certain implementation has particular properties rather than testing." and how does it affect the way FFmpeg probes for the libc. What could be a solution which supports musl? Many thanks! Jörg --------------010402090502010405090901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I am trying to add support for the musl toolchain to FFmpeg.

FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly.

After this it checks for some combinations of hardware and the probed libc to set some more compile options, if necessary.

I know that musl does not have a macro __MUSL__ and I have read the explanation. However, I don't understand what's meant by "[..] it's a bug to assume a certain implementation has particular properties rather than testing." and how does it affect the way FFmpeg probes for the libc.

What could be a solution which supports musl?

Many thanks!
Jörg
 --------------010402090502010405090901-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6138 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 12:09:07 +0100 Message-ID: <541182D3.5010104@skarnet.org> References: <541180B9.5070604@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1410433741 13215 80.91.229.3 (11 Sep 2014 11:09:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 11:09:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6151-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 13:08:54 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS2FC-0007Gz-3r for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 13:08:54 +0200 Original-Received: (qmail 15432 invoked by uid 550); 11 Sep 2014 11:08:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15424 invoked from network); 11 Sep 2014 11:08:53 -0000 X-SourceIP: 80.111.163.198 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <541180B9.5070604@posteo.de> Xref: news.gmane.org gmane.linux.lib.musl.general:6138 Archived-At: > FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly. Why not set this macro unconditionally ? All standards-compliant libcs will make the correct symbols visible if you define _XOPEN_SOURCE to a certain value. This include glibc, uClibc, musl, and most other modern libcs. Some systems are notoriously broken (I'm thinking of FreeBSD, which makes a few standard symbols *not* visible when you define the correct macro), but they should be the ones with specialcasing if you need to support them. > What could be a solution which supports musl? My answer as a musl user, which may be different from answers from musl developers, is to use -D_XOPEN_SOURCE=600 without testing for the libc name, and only use system-specific macros to work around bugs in non-compliant systems. -- Laurent From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6139 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 13:17:21 +0200 Message-ID: <20140911111721.GG21835@port70.net> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410434259 19228 80.91.229.3 (11 Sep 2014 11:17:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 11:17:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6152-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 13:17:34 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS2Na-0004kp-0a for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 13:17:34 +0200 Original-Received: (qmail 20321 invoked by uid 550); 11 Sep 2014 11:17:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20313 invoked from network); 11 Sep 2014 11:17:33 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <541182D3.5010104@skarnet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6139 Archived-At: * Laurent Bercot [2014-09-11 12:09:07 +0100]: > >FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly. > > Why not set this macro unconditionally ? > All standards-compliant libcs will make the correct symbols visible > if you define _XOPEN_SOURCE to a certain value. This include glibc, this has to be the most frequently asked question http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F and yes, assuming standard conformance by default is the sane thing to do then _testing_ for conformance issues is the second try if the default fails and only if testing is somehow difficult/inappropriate should one fall back to hardcoding behaviour for particular non-conforming systems in case of musl conformance bugs are fixed so you should report them instead of trying to work them around From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6140 Path: news.gmane.org!not-for-mail From: Jens Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 13:17:25 +0200 (CEST) Message-ID: References: <541180B9.5070604@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-870865827-1410434246=:10045" X-Trace: ger.gmane.org 1410434267 19341 80.91.229.3 (11 Sep 2014 11:17:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 11:17:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6153-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 13:17:41 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS2Nf-0004oS-6b for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 13:17:39 +0200 Original-Received: (qmail 21562 invoked by uid 550); 11 Sep 2014 11:17:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21554 invoked from network); 11 Sep 2014 11:17:37 -0000 Received-SPF: none (smtp-gw11.han.skanova.net: domain jelaas.eu does not designate permitted sender hosts) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=90.229.179.137; envelope-from=jensl@jelaas.eu; helo=90-229-179-137-no217.tbcn.telia.com; In-Reply-To: <541180B9.5070604@posteo.de> User-Agent: Alpine 2.11 (LNX 23 2013-08-11) Xref: news.gmane.org gmane.linux.lib.musl.general:6140 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-870865827-1410434246=:10045 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 11 Sep 2014, Jörg Krause wrote: > Hi, > > I am trying to add support for the musl toolchain to FFmpeg. > > FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards > below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and > __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly. > > After this it checks for some combinations of hardware and the probed libc to set some more compile options, > if necessary. > > I know that musl does not have a macro __MUSL__ and I have read the explanation. However, I don't understand > what's meant by "[..] it's a bug to assume a certain implementation has particular properties rather than > testing." and how does it affect the way FFmpeg probes for the libc. Maybe the explanation in the FAQ could be a bit more verbose. But if you stop and think for a bit you'll realize that __MUSL__ would tell you next to nothing. musl and any other libc that is maintained will change with time. You cannot assume a specific functionality by checking for __MUSL__. Bugs will be fixed, functionality will be implemented etc. Even if you could check for a specific version of musl you will do most people a disservice since their libc/version wont be handled. If instead you check for a specific functionality, it will be independent of libc and version of libc. A somewhat limited build of ffmpeg, atleast, works fine with musl: OPTPREFIX=opt/av configure --prefix=/$OPTPREFIX \ --enable-gpl\ --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ --enable-libmp3lame\ --enable-libx264 \ --disable-network --cc=musl-gcc Thats my understanding, for what its worth. Regards, Jens > > What could be a solution which supports musl? > > Many thanks! > Jörg > > --0-870865827-1410434246=:10045-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6142 Path: news.gmane.org!not-for-mail From: =?windows-1252?Q?J=F6rg_Krause?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 14:02:59 +0200 Message-ID: <54118F73.2020807@posteo.de> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> <20140911111721.GG21835@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1410436982 21611 80.91.229.3 (11 Sep 2014 12:03:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 12:03:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6155-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 14:02:57 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS35T-0002Bp-Ue for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 14:02:56 +0200 Original-Received: (qmail 13653 invoked by uid 550); 11 Sep 2014 12:02:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13638 invoked from network); 11 Sep 2014 12:02:54 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 In-Reply-To: <20140911111721.GG21835@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:6142 Archived-At: On 09/11/2014 01:17 PM, Szabolcs Nagy wrote: > * Laurent Bercot [2014-09-11 12:09:07 +0100]: >>> FFmpeg needs support for library features defined in POSIX.1-2001 with XSI extension and the standards below. Currently configure probes the host and target libc by checking for defined macros like __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 properly. >> Why not set this macro unconditionally ? >> All standards-compliant libcs will make the correct symbols visible >> if you define _XOPEN_SOURCE to a certain value. This include glibc, > this has to be the most frequently asked question > > http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F > > and yes, assuming standard conformance by default is the > sane thing to do I see. So it should be safe to assume standard conformance of the libc and set _XOPEN_SOURCE properly. > > then _testing_ for conformance issues is the second try > if the default fails What do you mean with testing for concormance? From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6143 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?SsO2cmcgS3JhdXNl?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 14:24:21 +0200 Message-ID: <54119475.1090208@posteo.de> References: <541180B9.5070604@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410438264 7186 80.91.229.3 (11 Sep 2014 12:24:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 12:24:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6156-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 14:24:16 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS3Q8-0007qC-OE for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 14:24:16 +0200 Original-Received: (qmail 28240 invoked by uid 550); 11 Sep 2014 12:24:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28232 invoked from network); 11 Sep 2014 12:24:15 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:6143 Archived-At: On 09/11/2014 01:17 PM, Jens wrote: > > On Thu, 11 Sep 2014, Jörg Krause wrote: >> Hi, >> >> I am trying to add support for the musl toolchain to FFmpeg. >> >> FFmpeg needs support for library features defined in POSIX.1-2001 >> with XSI extension and the standards >> below. Currently configure probes the host and target libc by >> checking for defined macros like __GLIBC__ and >> __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 >> properly. >> >> After this it checks for some combinations of hardware and the probed >> libc to set some more compile options, >> if necessary. >> >> I know that musl does not have a macro __MUSL__ and I have read the >> explanation. However, I don't understand >> what's meant by "[..] it's a bug to assume a certain implementation >> has particular properties rather than >> testing." and how does it affect the way FFmpeg probes for the libc. > > Maybe the explanation in the FAQ could be a bit more verbose. Maybe that would help :-) > But if you stop and think for a bit you'll realize that __MUSL__ would > tell you next to nothing. musl and any other libc that is maintained > will change with time. You cannot assume a specific functionality by > checking for __MUSL__. Bugs will be fixed, functionality will be > implemented etc. I see. > > Even if you could check for a specific version of musl you will do > most people a disservice since their libc/version wont be handled. > If instead you check for a specific functionality, it will be > independent of libc and version of libc. I am not sure what you mean with "check for a specific functionality"? > > A somewhat limited build of ffmpeg, atleast, works fine with musl: > OPTPREFIX=opt/av > configure --prefix=/$OPTPREFIX \ > --enable-gpl\ > --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ > --enable-libmp3lame\ > --enable-libx264 \ > --disable-network --cc=musl-gcc I'm using a musl cross-compiling toolchain and the limited build even without mp3 and x264 fails for me: ./configure --enable-cross-compile\ --cross-prefix=/home/joerg/x86_64-linux-musl/bin/x86_64-linux-musl-\ --arch=x86_64 --target-os=linux\ --prefix=/home/joerg/test/ffmpeg\ --enable-gpl\ --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ --disable-network [...] make: *** [libavformat/segment.o] Error 1 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6145 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 14:38:01 +0200 Message-ID: <20140911123800.GI21835@port70.net> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> <20140911111721.GG21835@port70.net> <54118F73.2020807@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410439105 17860 80.91.229.3 (11 Sep 2014 12:38:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 12:38:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6158-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 14:38:19 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS3de-0008Kg-R4 for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 14:38:14 +0200 Original-Received: (qmail 5534 invoked by uid 550); 11 Sep 2014 12:38:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5526 invoked from network); 11 Sep 2014 12:38:12 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <54118F73.2020807@posteo.de> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6145 Archived-At: * J?rg Krause [2014-09-11 14:02:59 +0200]: > On 09/11/2014 01:17 PM, Szabolcs Nagy wrote: > >then _testing_ for conformance issues is the second try > >if the default fails > > What do you mean with testing for concormance? eg glibc scanf uses "%a" for its own extension by default and c99 behaviour is only provided with appropriate cflags if your project depends on %a scanf then you may need to test for this conformance issue (instead of ifdef __GLIBC__ because they may change the behaviour later or the cflag might not work on an older version etc) of course there are cases when you depend on behaviour that is not described by any standard in which case it is not "conformance testing" but you still need some kind of testing of the behaviour for portability From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6147 Path: news.gmane.org!not-for-mail From: =?windows-1252?Q?J=F6rg_Krause?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 15:33:16 +0200 Message-ID: <5411A49C.20808@posteo.de> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> <20140911111721.GG21835@port70.net> <54118F73.2020807@posteo.de> <20140911123800.GI21835@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1410442398 29958 80.91.229.3 (11 Sep 2014 13:33:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 13:33:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6160-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 15:33:10 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS4Uo-00029r-E0 for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 15:33:10 +0200 Original-Received: (qmail 16325 invoked by uid 550); 11 Sep 2014 13:33:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16317 invoked from network); 11 Sep 2014 13:33:09 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <20140911123800.GI21835@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:6147 Archived-At: On 09/11/2014 02:38 PM, Szabolcs Nagy wrote: > * J?rg Krause [2014-09-11 14:02:59 +0200]: >> On 09/11/2014 01:17 PM, Szabolcs Nagy wrote: >>> then _testing_ for conformance issues is the second try >>> if the default fails >> What do you mean with testing for concormance? > eg glibc scanf uses "%a" for its own extension by default > and c99 behaviour is only provided with appropriate cflags > > if your project depends on %a scanf then you may need to > test for this conformance issue (instead of ifdef __GLIBC__ > because they may change the behaviour later or the cflag > might not work on an older version etc) I see. But I can avoid the GNU specific bevahiour by undefining _GNU_SOURCE if I want POSIX-conformance. In this case I do not need to test, but can rely on the libc of being conformal. Do I have this right? eg, in FFmpeg/libavutils uses strerror_r which is implemented as a XSI-compliant and a GNU-specific version. If I want to be sure to get the XSI-compliant version, I unset _GNU_SOURCE and set _XOPEN_SOURCE=600. So I do not need any further testing here, right? From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6149 Path: news.gmane.org!not-for-mail From: Christian Neukirchen Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 16:30:57 +0200 Message-ID: <87d2b2fcv2.fsf@gmail.com> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410445880 12448 80.91.229.3 (11 Sep 2014 14:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 14:31:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6162-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 16:31:15 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS5Ox-0007cz-Nt for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 16:31:11 +0200 Original-Received: (qmail 31927 invoked by uid 550); 11 Sep 2014 14:31:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31916 invoked from network); 11 Sep 2014 14:31:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=vvzxG1F6tH90ut1IvxZMZACvKL1vGpEIvK8++xa+ijw=; b=HfslfafSPg3SJj/OGDBqq70SWlUxJsxRNktilqiTsbCERKjyH6QjMNIxzalx5tPmGO WxfoFM0r40Vf/fHdPEGGzspF9nKY6xIhIRsGJaZP+yjhKksO94IOV8141lhRFiDCkMCS JvmlJthf1owNLlahiTkfMctzQdwK1iVt5+xq+IgvEoJQFDJLBLewBBz8f01FkS8jXDjd hzz5axc43hzLeby04RgipFm6l8kbQtYQ1mlFL9V2klyLMKbu+aK2BOooP/jdTjkK1qy1 Va5EWIilQPZRlPpTKOQ/n5G/EN+eCd+3ch3/WX9RQcg92e7Wm+gSm/VZfQF/CLAWQoig iOPw== X-Received: by 10.152.204.231 with SMTP id lb7mr16501lac.44.1410445859063; Thu, 11 Sep 2014 07:30:59 -0700 (PDT) In-Reply-To: <541182D3.5010104@skarnet.org> (Laurent Bercot's message of "Thu, 11 Sep 2014 12:09:07 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Xref: news.gmane.org gmane.linux.lib.musl.general:6149 Archived-At: Laurent Bercot writes: >> FFmpeg needs support for library features defined in POSIX.1-2001 >> with XSI extension and the standards below. Currently configure >> probes the host and target libc by checking for defined macros like >> __GLIBC__ and __UCLIBC__. In case of glibc and uclibc it sets >> -D_XOPEN_SOURCE=600 properly. > > Why not set this macro unconditionally ? > All standards-compliant libcs will make the correct symbols visible > if you define _XOPEN_SOURCE to a certain value. This include glibc, > uClibc, musl, and most other modern libcs. Some systems are > notoriously broken (I'm thinking of FreeBSD, which makes a few > standard symbols *not* visible when you define the correct macro), > but they should be the ones with specialcasing if you need to > support them. OT, but when you report these to freebsd-standards, they'll be resolved quickly. That is at least my experience. -- Christian Neukirchen http://chneukirchen.org From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6150 Path: news.gmane.org!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 16:47:11 +0200 Message-ID: <20140911164711.248bf3d7@ncopa-desktop.alpinelinux.org> References: <541180B9.5070604@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410446871 26595 80.91.229.3 (11 Sep 2014 14:47:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 14:47:51 +0000 (UTC) Cc: musl@lists.openwall.com To: =?ISO-8859-1?B?SvZyZw==?= Krause Original-X-From: musl-return-6163-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 16:47:41 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS5ei-0001T0-6e for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 16:47:28 +0200 Original-Received: (qmail 16163 invoked by uid 550); 11 Sep 2014 14:47:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16148 invoked from network); 11 Sep 2014 14:47:27 -0000 In-Reply-To: <541180B9.5070604@posteo.de> X-Mailer: Claws Mail 3.10.1-156-gb29a92 (GTK+ 2.24.23; x86_64-unknown-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:6150 Archived-At: On Thu, 11 Sep 2014 13:00:09 +0200 J=F6rg Krause wrote: > Hi, >=20 > I am trying to add support for the musl toolchain to FFmpeg. >=20 > FFmpeg needs support for library features defined in POSIX.1-2001 with=20 > XSI extension and the standards below. Currently configure probes the=20 > host and target libc by checking for defined macros like __GLIBC__ and=20 > __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=3D600=20 > properly. >=20 > After this it checks for some combinations of hardware and the probed=20 > libc to set some more compile options, if necessary. >=20 > I know that musl does not have a macro __MUSL__ and I have read the=20 > explanation. However, I don't understand what's meant by "[..] it's a=20 > bug to assume a certain implementation has particular properties rather=20 > than testing." and how does it affect the way FFmpeg probes for the libc. >=20 > What could be a solution which supports musl? >=20 > Many thanks! > J=F6rg This is what we do on alpine linux: http://git.alpinelinux.org/cgit/aports/tree/main/ffmpeg/fix-defines.patch --- ffmpeg-1.2.2.orig/libavutil/error.c +++ ffmpeg-1.2.2/libavutil/error.c @@ -17,6 +17,7 @@ */ =20 #undef _GNU_SOURCE +#define _XOPEN_SOURCE 600 #include "avutil.h" #include "avstring.h" #include "common.h" From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6151 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 16:48:55 +0200 Message-ID: <20140911144855.GM21835@port70.net> References: <541180B9.5070604@posteo.de> <541182D3.5010104@skarnet.org> <20140911111721.GG21835@port70.net> <54118F73.2020807@posteo.de> <20140911123800.GI21835@port70.net> <5411A49C.20808@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410446955 28352 80.91.229.3 (11 Sep 2014 14:49:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 14:49:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6164-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 16:49:08 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS5gK-0002a6-5c for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 16:49:08 +0200 Original-Received: (qmail 18066 invoked by uid 550); 11 Sep 2014 14:49:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18058 invoked from network); 11 Sep 2014 14:49:07 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <5411A49C.20808@posteo.de> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6151 Archived-At: * J?rg Krause [2014-09-11 15:33:16 +0200]: > eg, in FFmpeg/libavutils uses strerror_r which is implemented as a > XSI-compliant and a GNU-specific version. If I want to be sure to get the > XSI-compliant version, I unset _GNU_SOURCE and set _XOPEN_SOURCE=600. So I > do not need any further testing here, right? yes, using feature test macros should work (unless you want to support some very old version of the libc) From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6152 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Thu, 11 Sep 2014 07:53:00 -0700 Message-ID: <20140911145259.GB1779@newbook> References: <541180B9.5070604@posteo.de> <54119475.1090208@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410447205 32450 80.91.229.3 (11 Sep 2014 14:53:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 14:53:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6165-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 11 16:53:17 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XS5kK-0005Lz-I6 for gllmg-musl@plane.gmane.org; Thu, 11 Sep 2014 16:53:16 +0200 Original-Received: (qmail 21818 invoked by uid 550); 11 Sep 2014 14:53:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21809 invoked from network); 11 Sep 2014 14:53:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=p9R4EH8TG1adj3SLUEuogpy05T7KM6jgZ/xHVBfqxVY=; b=dgqjQ/+I/fji8edXrz4d7PA9LwTbaWNUHCSrJUfs50uthUmqDYrUZlozTkHtpkkQFi sy4GZ/29yaPnjjgqYLvz++7d+WQRr3ernZqxuUgjGqE3Yc5zFXsdKZl9Z7Z8ot7kUb3q jPYgOF4Rarh3MaeWnyz1Ch8vo2JLtgZqDLM1bV0tiYckxLgdyBIuG+B2Jr9mw1g98KuE v9yo83iixPhmXYnFzcILfZkzQMzDYlN4VZkFCVXKDONKQjv1sAEMcwQa2dS1pW5ryaOi mcPZsePRNBOPq4s4eir6sDZIxw2WrW/rzAS4nExY1c0MicZFD5ZtX/XoL0HP2rQBbgTf QisQ== X-Received: by 10.70.131.70 with SMTP id ok6mr2201451pdb.133.1410447183672; Thu, 11 Sep 2014 07:53:03 -0700 (PDT) Content-Disposition: inline In-Reply-To: <54119475.1090208@posteo.de> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6152 Archived-At: On Thu, Sep 11, 2014 at 02:24:21PM +0200, Jörg Krause wrote: > > On 09/11/2014 01:17 PM, Jens wrote: > > > >A somewhat limited build of ffmpeg, atleast, works fine with musl: > >OPTPREFIX=opt/av > >configure --prefix=/$OPTPREFIX \ > > --enable-gpl\ > > --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ > > --enable-libmp3lame\ > > --enable-libx264 \ > > --disable-network --cc=musl-gcc > > I'm using a musl cross-compiling toolchain and the limited build even > without mp3 and x264 fails for me: > > ./configure --enable-cross-compile\ > --cross-prefix=/home/joerg/x86_64-linux-musl/bin/x86_64-linux-musl-\ > --arch=x86_64 --target-os=linux\ > --prefix=/home/joerg/test/ffmpeg\ > --enable-gpl\ > --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ > --disable-network > [...] > make: *** [libavformat/segment.o] Error 1 > It would be easier to see what's going on if you provided the command line for compiling that file, plus the rest of the error. If ffmpeg is showing the "CC ..." message rather than a massive command line, then run "make V=1". Thanks, Iaac Dunham From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6156 Path: news.gmane.org!not-for-mail From: =?windows-1252?Q?J=F6rg_Krause?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Fri, 12 Sep 2014 09:35:22 +0200 Message-ID: <5412A23A.6080503@posteo.de> References: <541180B9.5070604@posteo.de> <20140911164711.248bf3d7@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410507325 23453 80.91.229.3 (12 Sep 2014 07:35:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2014 07:35:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6169-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 12 09:35:20 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XSLO4-00069z-06 for gllmg-musl@plane.gmane.org; Fri, 12 Sep 2014 09:35:20 +0200 Original-Received: (qmail 17907 invoked by uid 550); 12 Sep 2014 07:35:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17899 invoked from network); 12 Sep 2014 07:35:17 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <20140911164711.248bf3d7@ncopa-desktop.alpinelinux.org> Xref: news.gmane.org gmane.linux.lib.musl.general:6156 Archived-At: On 09/11/2014 04:47 PM, Natanael Copa wrote: > On Thu, 11 Sep 2014 13:00:09 +0200 > Jörg Krause wrote: > >> Hi, >> >> I am trying to add support for the musl toolchain to FFmpeg. >> >> FFmpeg needs support for library features defined in POSIX.1-2001 with >> XSI extension and the standards below. Currently configure probes the >> host and target libc by checking for defined macros like __GLIBC__ and >> __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 >> properly. >> >> After this it checks for some combinations of hardware and the probed >> libc to set some more compile options, if necessary. >> >> I know that musl does not have a macro __MUSL__ and I have read the >> explanation. However, I don't understand what's meant by "[..] it's a >> bug to assume a certain implementation has particular properties rather >> than testing." and how does it affect the way FFmpeg probes for the libc. >> >> What could be a solution which supports musl? >> >> Many thanks! >> Jörg > This is what we do on alpine linux: > http://git.alpinelinux.org/cgit/aports/tree/main/ffmpeg/fix-defines.patch > > --- ffmpeg-1.2.2.orig/libavutil/error.c > +++ ffmpeg-1.2.2/libavutil/error.c > @@ -17,6 +17,7 @@ > */ > > #undef _GNU_SOURCE > +#define _XOPEN_SOURCE 600 > #include "avutil.h" > #include "avstring.h" > #include "common.h" > Hi Natanal, I had a look to alpine already. I submitted this patch to FFmpeg, but building FFmpeg with my configuration libavutils/error.c is not the only file which needs a feature test macro. The people of FFmpeg did not like the idea to have a lot of test macros in there source so I stopped with this solution and looked for a way to adopt the musl toolchain to their configure file. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6157 Path: news.gmane.org!not-for-mail From: =?windows-1252?Q?J=F6rg_Krause?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Fri, 12 Sep 2014 09:39:33 +0200 Message-ID: <5412A335.2020304@posteo.de> References: <541180B9.5070604@posteo.de> <54119475.1090208@posteo.de> <20140911145259.GB1779@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410507585 26478 80.91.229.3 (12 Sep 2014 07:39:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2014 07:39:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6170-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 12 09:39:38 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XSLSE-0008CJ-5h for gllmg-musl@plane.gmane.org; Fri, 12 Sep 2014 09:39:38 +0200 Original-Received: (qmail 23749 invoked by uid 550); 12 Sep 2014 07:39:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23732 invoked from network); 12 Sep 2014 07:39:37 -0000 X-Virus-Scanned: amavisd-new at posteo.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <20140911145259.GB1779@newbook> Xref: news.gmane.org gmane.linux.lib.musl.general:6157 Archived-At: On 09/11/2014 04:53 PM, Isaac Dunham wrote: > On Thu, Sep 11, 2014 at 02:24:21PM +0200, Jörg Krause wrote: >> On 09/11/2014 01:17 PM, Jens wrote: >>> A somewhat limited build of ffmpeg, atleast, works fine with musl: >>> OPTPREFIX=opt/av >>> configure --prefix=/$OPTPREFIX \ >>> --enable-gpl\ >>> --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ >>> --enable-libmp3lame\ >>> --enable-libx264 \ >>> --disable-network --cc=musl-gcc >> I'm using a musl cross-compiling toolchain and the limited build even >> without mp3 and x264 fails for me: >> >> ./configure --enable-cross-compile\ >> --cross-prefix=/home/joerg/x86_64-linux-musl/bin/x86_64-linux-musl-\ >> --arch=x86_64 --target-os=linux\ >> --prefix=/home/joerg/test/ffmpeg\ >> --enable-gpl\ >> --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\ >> --disable-network >> [...] >> make: *** [libavformat/segment.o] Error 1 >> > It would be easier to see what's going on if you provided the command line > for compiling that file, plus the rest of the error. > If ffmpeg is showing the "CC ..." message rather than a massive command > line, then run "make V=1". > > Thanks, > Iaac Dunham Hi Isaac, it was not my intention to report an error. I just wanted to reply that the configuration posted by Jens did not work for me. Btw, to fix the compilation with musl it's necessary to add the feature test macro _XOPEN_SOURCE=600. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6158 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: why is there no __MUSL__ macro? Date: Fri, 12 Sep 2014 11:37:32 -0400 Message-ID: <20140912153732.GQ23797@brightrain.aerifal.cx> References: <541180B9.5070604@posteo.de> <20140911164711.248bf3d7@ncopa-desktop.alpinelinux.org> <5412A23A.6080503@posteo.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410536401 16626 80.91.229.3 (12 Sep 2014 15:40:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2014 15:40:01 +0000 (UTC) Cc: musl@lists.openwall.com To: =?utf-8?B?SsO2cmc=?= Krause Original-X-From: musl-return-6171-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 12 17:39:56 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XSSx1-0004j3-1F for gllmg-musl@plane.gmane.org; Fri, 12 Sep 2014 17:39:55 +0200 Original-Received: (qmail 1992 invoked by uid 550); 12 Sep 2014 15:39:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1981 invoked from network); 12 Sep 2014 15:39:53 -0000 Content-Disposition: inline In-Reply-To: <5412A23A.6080503@posteo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6158 Archived-At: On Fri, Sep 12, 2014 at 09:35:22AM +0200, Jörg Krause wrote: > > On 09/11/2014 04:47 PM, Natanael Copa wrote: > >On Thu, 11 Sep 2014 13:00:09 +0200 > >Jörg Krause wrote: > > > >>Hi, > >> > >>I am trying to add support for the musl toolchain to FFmpeg. > >> > >>FFmpeg needs support for library features defined in POSIX.1-2001 with > >>XSI extension and the standards below. Currently configure probes the > >>host and target libc by checking for defined macros like __GLIBC__ and > >>__UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600 > >>properly. > >> > >>After this it checks for some combinations of hardware and the probed > >>libc to set some more compile options, if necessary. > >> > >>I know that musl does not have a macro __MUSL__ and I have read the > >>explanation. However, I don't understand what's meant by "[..] it's a > >>bug to assume a certain implementation has particular properties rather > >>than testing." and how does it affect the way FFmpeg probes for the libc. > >> > >>What could be a solution which supports musl? > >> > >>Many thanks! > >>Jörg > >This is what we do on alpine linux: > >http://git.alpinelinux.org/cgit/aports/tree/main/ffmpeg/fix-defines.patch > > > >--- ffmpeg-1.2.2.orig/libavutil/error.c > >+++ ffmpeg-1.2.2/libavutil/error.c > >@@ -17,6 +17,7 @@ > > */ > > #undef _GNU_SOURCE > >+#define _XOPEN_SOURCE 600 > > #include "avutil.h" > > #include "avstring.h" > > #include "common.h" > > > > Hi Natanal, > > I had a look to alpine already. I submitted this patch to FFmpeg, > but building FFmpeg with my configuration libavutils/error.c is not > the only file which needs a feature test macro. The people of FFmpeg > did not like the idea to have a lot of test macros in there source > so I stopped with this solution and looked for a way to adopt the > musl toolchain to their configure file. It might work to add -D_DEFAULT_SOURCE (note: not available until recent musl git) or -D_BSD_SOURCE to the global CFLAGS. What's happening, I think, is that because -std=c99 or similar is in the CFLAGS, default feature profile is getting suppressed, and _GNU_SOURCE is the only thing bringing back the usual features (in addition to lots of _GNU_SOURCE-only stuff, and strerror_r breakage). Having at least one more feature test macro defined globally would prevent this. Note also that modern glibc supports _DEFAULT_SOURCE, with the same semantics as musl: keeping the default stuff exposed even when a -std=* option would otherwise suppress it. Rich