Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On 09/02/2014 11:49 PM, Reimar Döffinger wrote: On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote: The maintainers of the musl C library states that looking for __GLIBC__ or __UCLIBC__ and making assumptions about the implemented feature set is not the best way. Instead should be inspected for the specification of the feature test macros. Here are links to a discussion on the musl mailing list: I don't know for sure, but I suspect features.h won't help you one bit for the things that configure check was supposed to solve, like the fact that some specific POSIX compliance flag on some platforms will hide a specific feature with no way to get it back again, yet you need the POSIX features enabled by that flag. Unless you propose to test all 100s of combinations of flags until we find one that looks like it works, which I'd object to on the reason that configure is already too slow. If I check the defined feature test macros in I get the following results for the musl toolchain and the GNU C toolchain with glibc: x86_64-linux-musl-gcc: _XOPEN_SOURCE defined: 700 _BSD_SOURCE defined gcc (glibc 2.19): _POSIX_SOURCE defined _POSIX_C_SOURCE defined: 200809L _BSD_SOURCE defined _SVID_SOURCE defined _ATFILE_SOURCE defined So configure can ascertain these values and set CPPFLAGS accordingly without to distinguish which (POSIX compliant) C library is used. Maybe the values will differ for different platforms but this is not a problem for configure. Just take the values and pass them to the preprocessor/compiler. Nothing else is done in the current configure, except that configure ascertains the libc type and then assings the feature test macros. E.g. if configure found glibc then it says you are _POSIX_C_SOURCE=200112 and _XOPEN_SOURCE=600. Which is not even true for the latter case as you can see above for my gcc. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On 09/02/2014 06:03 PM, wm4 wrote: On Tue, 2 Sep 2014 12:33:26 +0200 Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). Signed-off-by: Jörg Krause --- libavutil/error.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/error.c b/libavutil/error.c index bd66354..d326584 100644 --- a/libavutil/error.c +++ b/libavutil/error.c @@ -17,6 +17,7 @@ */ #undef _GNU_SOURCE +#define _XCODE_SOURCE 600 #include "avutil.h" #include "avstring.h" #include "common.h" This looks good to me, though in the meantime I heard that others compile FFmpeg on musl without issues and without having to patch anything. I'm not sure why it's breaking in your case; maybe random CFLAGS were leaking from pkg-config or other configure checks, which makes this work for others. I checked this with a prebuild x86_64 cross compilation musl toolchain from http://musl.codu.org/ and it fails for me (without the patches). Do you have some more information about the the successful builds you heard of? configure does not ascertain the musl libc and so does not set the correct -D feature test macros. Maybe if they added the needed macros to the CPPFLAGS on command line? Also, you probably have to adjust the configure test for HAVE_STRERROR_R? HAVE_STRERROR_R is found and defined to 1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On 2014-09-03 02:13, Michael Niedermayer wrote: > On Tue, Sep 02, 2014 at 11:49:47PM +0200, Reimar Döffinger wrote: > [...] > >> reason that configure is already too slow. > > ccache + --tempprefix + dash instead of bash should help a bit Tell that to Windows! Okay trying dash did reduce the 103 seconds to only 61. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 11:49:47PM +0200, Reimar Döffinger wrote: [...] > reason that configure is already too slow. ccache + --tempprefix + dash instead of bash should help a bit [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote: > The maintainers of the musl C library states that looking for __GLIBC__ or > __UCLIBC__ and making assumptions about the implemented feature set is not > the best way. Instead should be inspected for the specification > of the feature test macros. Here are links to a discussion on the musl > mailing list: I don't know for sure, but I suspect features.h won't help you one bit for the things that configure check was supposed to solve, like the fact that some specific POSIX compliance flag on some platforms will hide a specific feature with no way to get it back again, yet you need the POSIX features enabled by that flag. Unless you propose to test all 100s of combinations of flags until we find one that looks like it works, which I'd object to on the reason that configure is already too slow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On 09/02/2014 07:41 PM, Reimar Döffinger wrote: On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote: On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: Am 02.09.2014 12:40 schrieb Michael Niedermayer: On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? [...] I followed the recommendation from the GNU C Library Reference Manual, ch. 1.3.4 Feature Test Macro: You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file. It is best to make them the very first thing in the file, preceded only by comments. You could also use the ‘-D’ option to GCC, but it's better if you make the source files indicate their own meaning in a self-contained way. Do you prefer to define the macro in configure? i prefer that all libcs are handled the same way And to be honest the configure check seems backwards to me, why isn't -D_XOPEN_SOURCE=600 used by default? Do all of klibc, bionic, mingw32, mingw64, cygwin/newlib, msvcrt break if you add it? There are two possibilities for the usage of the feature test macros: 1. at source level 2. via -D options passed as arguments to the preprocessor or compiler FFmpeg use both of them: Defining via -D in configure and undefine at source level (e.g. #undef _GNU_SOURCE). As written before the GNU C Library Reference Manual suggests the usage at the source level. The maintainers of the musl C library states that looking for __GLIBC__ or __UCLIBC__ and making assumptions about the implemented feature set is not the best way. Instead should be inspected for the specification of the feature test macros. Here are links to a discussion on the musl mailing list: http://www.openwall.com/lists/musl/2013/03/29/13 http://www.openwall.com/lists/musl/2013/03/30/2 + http://www.openwall.com/lists/musl/2013/03/30/4 So we should decide which possibility we prefer for FFmpeg. If we do set the macros at source level we do not need to set them in configure (in case of a GNU C compliant library). If we want to set them in configure we can inspect and ascertain the effects of the features test macros. What do you think? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 07:41:40PM +0200, Reimar Döffinger wrote: > On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote: > > On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: > > > > > > > > > Am 02.09.2014 12:40 schrieb Michael Niedermayer: > > > >On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: > > > >>Add the feature test macro which is required for building with the > > > >>musl toolchain. > > > >> > > > >>The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant > > > >>version of strerror_r(). > > > > > > > >is there a reason why you dont set it from configure ? > > > >similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? > > > > > > > >[...] > > > > > > I followed the recommendation from the GNU C Library Reference > > > Manual, ch. 1.3.4 Feature Test Macro: > > > > > > You should define these macros by using ‘#define’ preprocessor > > > directives at the top of your source code files. These directives > > > must come before any #include of a system header file. It is best to > > > make them the very first thing in the file, preceded only by > > > comments. You could also use the ‘-D’ option to GCC, but it's better > > > if you make the source files indicate their own meaning in a > > > self-contained way. > > > > > > Do you prefer to define the macro in configure? > > > > i prefer that all libcs are handled the same way > > And to be honest the configure check seems backwards to me, why isn't > -D_XOPEN_SOURCE=600 used by default? no idea > Do all of klibc, bionic, mingw32, mingw64, cygwin/newlib, msvcrt break > if you add it? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote: > On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: > > > > > > Am 02.09.2014 12:40 schrieb Michael Niedermayer: > > >On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: > > >>Add the feature test macro which is required for building with the > > >>musl toolchain. > > >> > > >>The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant > > >>version of strerror_r(). > > > > > >is there a reason why you dont set it from configure ? > > >similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? > > > > > >[...] > > > > I followed the recommendation from the GNU C Library Reference > > Manual, ch. 1.3.4 Feature Test Macro: > > > > You should define these macros by using ‘#define’ preprocessor > > directives at the top of your source code files. These directives > > must come before any #include of a system header file. It is best to > > make them the very first thing in the file, preceded only by > > comments. You could also use the ‘-D’ option to GCC, but it's better > > if you make the source files indicate their own meaning in a > > self-contained way. > > > > Do you prefer to define the macro in configure? > > i prefer that all libcs are handled the same way And to be honest the configure check seems backwards to me, why isn't -D_XOPEN_SOURCE=600 used by default? Do all of klibc, bionic, mingw32, mingw64, cygwin/newlib, msvcrt break if you add it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, 2 Sep 2014 12:33:26 +0200 Jörg Krause wrote: > Add the feature test macro which is required for building with the > musl toolchain. > > The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant > version of strerror_r(). > > Signed-off-by: Jörg Krause > --- > libavutil/error.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavutil/error.c b/libavutil/error.c > index bd66354..d326584 100644 > --- a/libavutil/error.c > +++ b/libavutil/error.c > @@ -17,6 +17,7 @@ > */ > > #undef _GNU_SOURCE > +#define _XCODE_SOURCE 600 > #include "avutil.h" > #include "avstring.h" > #include "common.h" This looks good to me, though in the meantime I heard that others compile FFmpeg on musl without issues and without having to patch anything. I'm not sure why it's breaking in your case; maybe random CFLAGS were leaking from pkg-config or other configure checks, which makes this work for others. Also, you probably have to adjust the configure test for HAVE_STRERROR_R? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: > > > Am 02.09.2014 12:40 schrieb Michael Niedermayer: > >On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: > >>Add the feature test macro which is required for building with the > >>musl toolchain. > >> > >>The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant > >>version of strerror_r(). > > > >is there a reason why you dont set it from configure ? > >similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? > > > >[...] > > I followed the recommendation from the GNU C Library Reference > Manual, ch. 1.3.4 Feature Test Macro: > > You should define these macros by using ‘#define’ preprocessor > directives at the top of your source code files. These directives > must come before any #include of a system header file. It is best to > make them the very first thing in the file, preceded only by > comments. You could also use the ‘-D’ option to GCC, but it's better > if you make the source files indicate their own meaning in a > self-contained way. > > Do you prefer to define the macro in configure? i prefer that all libcs are handled the same way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
Am 02.09.2014 12:40 schrieb Michael Niedermayer: On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? [...] I followed the recommendation from the GNU C Library Reference Manual, ch. 1.3.4 Feature Test Macro: You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file. It is best to make them the very first thing in the file, preceded only by comments. You could also use the ‘-D’ option to GCC, but it's better if you make the source files indicate their own meaning in a self-contained way. Do you prefer to define the macro in configure? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: > Add the feature test macro which is required for building with the > musl toolchain. > > The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant > version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing "-D_XOPEN_SOURCE=600" code in configure ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). Signed-off-by: Jörg Krause --- libavutil/error.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/error.c b/libavutil/error.c index bd66354..d326584 100644 --- a/libavutil/error.c +++ b/libavutil/error.c @@ -17,6 +17,7 @@ */ #undef _GNU_SOURCE +#define _XCODE_SOURCE 600 #include "avutil.h" #include "avstring.h" #include "common.h" -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
