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--