Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato wrote: > --- > > Here an initial patch to support many yuva, apparently either I botched > adding them (since I did lots of cut and paste) or they manage the expose some > flaws in swscale. valgrind manages to spot something and might be nice if > other people try this and see if the values for the fate-lavfi change after > each round. If this is what I think it is, search for YUVA420P in swscale and replace it with a generic alpha check. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RFC] pixfmt: support more yuva formats
---
Here an initial patch to support many yuva, apparently either I botched
adding them (since I did lots of cut and paste) or they manage the expose some
flaws in swscale. valgrind manages to spot something and might be nice if
other people try this and see if the values for the fate-lavfi change after
each round.
libavcodec/raw.c| 19 +
libavformat/nut.c | 28 +++
libavutil/pixdesc.c | 234
libavutil/pixfmt.h | 28 +++
libswscale/utils.c | 18
5 files changed, 327 insertions(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 6f0c923..4ccc6cc 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -124,6 +124,25 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_YUVA420P,MKTAG('Y', '4', 11 , 8 ) },
{ AV_PIX_FMT_Y400A, MKTAG('Y', '2', 0 , 8 ) },
+{ AV_PIX_FMT_YUVA420P9LE, MKTAG('Y', '4', 11 , 9 ) },
+{ AV_PIX_FMT_YUVA420P9BE, MKTAG( 9 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P9LE, MKTAG('Y', '4', 10 , 9 ) },
+{ AV_PIX_FMT_YUVA422P9BE, MKTAG( 9 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P9LE, MKTAG('Y', '4', 0 , 9 ) },
+{ AV_PIX_FMT_YUVA444P9BE, MKTAG( 9 , 0 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA420P10LE, MKTAG('Y', '4', 11 , 10 ) },
+{ AV_PIX_FMT_YUVA420P10BE, MKTAG(10 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P10LE, MKTAG('Y', '4', 10 , 10 ) },
+{ AV_PIX_FMT_YUVA422P10BE, MKTAG(10 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P10LE, MKTAG('Y', '4', 0 , 10 ) },
+{ AV_PIX_FMT_YUVA444P10BE, MKTAG(10 , 0 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA420P16LE, MKTAG('Y', '4', 11 , 16 ) },
+{ AV_PIX_FMT_YUVA420P16BE, MKTAG(16 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P16LE, MKTAG('Y', '4', 10 , 16 ) },
+{ AV_PIX_FMT_YUVA422P16BE, MKTAG(16 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P16LE, MKTAG('Y', '4', 0 , 16 ) },
+{ AV_PIX_FMT_YUVA444P16BE, MKTAG(16 , 0 , '4', 'Y') },
+
/* quicktime */
{ AV_PIX_FMT_UYVY422, MKTAG('2', 'v', 'u', 'y') },
{ AV_PIX_FMT_UYVY422, MKTAG('2', 'V', 'u', 'y') },
diff --git a/libavformat/nut.c b/libavformat/nut.c
index e367d1c..e3129aa 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -87,6 +87,34 @@ const AVCodecTag ff_nut_video_tags[] = {
{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '3', 'Y') },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 8 ) },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '2', 0 , 8 ) },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 0 , '4', 'Y') },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 0 , '4', 'Y') },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '4', 'Y') },
+
{ AV_CODEC_ID_NONE, 0 }
};
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index b8cfabd..bc446b1 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -558,6 +558,240 @@ const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = PIX_FMT_PLANAR,
},
+[AV_PIX_FMT_YUVA420P9BE] = {
+.name = "yuva420p9be",
+.nb_components = 4,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 8 },/* Y */
+{ 1, 1, 1, 0, 8 },/* U */
+{ 2, 1, 1, 0, 8 },/* V */
+{ 3, 1, 1, 0, 8 },/* A */
+},
+.flags = PIX_FMT_BE | PIX_FMT_PLANAR,
+},
+[AV_PIX_FMT_YUVA420P9LE] = {
+.name = "yuva420p9le",
+.nb_components = 4,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 8 },/* Y */
+{ 1, 1, 1, 0, 8 },/* U */
+{ 2, 1, 1, 0, 8 },/* V */
+{ 3, 1, 1, 0, 8 },
[libav-devel] [PATCH] build: support asan and tsan toolchain shortcuts
--- configure | 10 ++ 1 file changed, 10 insertions(+) diff --git a/configure b/configure index 26cd7ea..b4a1f96 100755 --- a/configure +++ b/configure @@ -2053,6 +2053,16 @@ case "$toolchain" in nm_default="dumpbin -symbols" ar_default="lib" ;; +asan) +cc_default="clang" +add_cflags -faddress-sanitizer +add_ldflags -faddress-sanitizer +;; +tsan) +cc_default="clang" +add_cflags -fthread-sanitizer +add_ldflags -fthread-sanitizer +;; ?*) die "Unknown toolchain $toolchain" ;; -- 1.7.12 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] aacdec: use float planar sample format for output
---
I'm not 100% sure about 1 change. In output_configure() I moved the call
to sniff_channel_order() to above where the layout map and tags are
saved to ac->oc[1]. Otherwise the final layout map is never saved and
cannot be used to map the AVFrame channel pointers. I don't really know
the full consequences of this change though.
libavcodec/aac.h| 11 +---
libavcodec/aacdec.c | 140 ++
libavcodec/aacsbr.c |6 +--
3 files changed, 100 insertions(+), 57 deletions(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 32baf9d..18f674f 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -237,9 +237,10 @@ typedef struct SingleChannelElement {
uint8_t zeroes[128];///< band is not coded
(used by encoder)
DECLARE_ALIGNED(32, float, coeffs)[1024]; ///< coefficients for IMDCT
DECLARE_ALIGNED(32, float, saved)[1024]; ///< overlap
-DECLARE_ALIGNED(32, float, ret)[2048];///< PCM output
+DECLARE_ALIGNED(32, float, ret_buf)[2048];///< PCM output buffer
DECLARE_ALIGNED(16, float, ltp_state)[3072]; ///< time signal for LTP
PredictorState predictor_state[MAX_PREDICTORS];
+float *ret; ///< PCM output
} SingleChannelElement;
/**
@@ -263,6 +264,7 @@ typedef struct ChannelElement {
typedef struct AACContext {
AVCodecContext *avctx;
AVFrame frame;
+int got_frame_buffer;
int is_saved; ///< Set if elements have stored overlap
from previous frame.
DynamicRangeControl che_drc;
@@ -297,13 +299,6 @@ typedef struct AACContext {
int random_state;
/** @} */
-/**
- * @name Members used for output interleaving
- * @{
- */
-float *output_data[MAX_CHANNELS]; ///< Points to each
element's 'ret' buffer (PCM output).
-/** @} */
-
DECLARE_ALIGNED(32, float, temp)[128];
OutputConfiguration oc[2];
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 4a6d390..9d3c3b1 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -79,6 +79,7 @@
Parametric Stereo.
*/
+#include "libavutil/audioconvert.h"
#include "libavutil/float_dsp.h"
#include "avcodec.h"
#include "internal.h"
@@ -149,10 +150,10 @@ static av_cold int che_configure(AACContext *ac,
ff_aac_sbr_ctx_init(ac, &ac->che[type][id]->sbr);
}
if (type != TYPE_CCE) {
-ac->output_data[(*channels)++] = ac->che[type][id]->ch[0].ret;
+(*channels)++;
if (type == TYPE_CPE ||
(type == TYPE_SCE && ac->oc[1].m4ac.ps == 1)) {
-ac->output_data[(*channels)++] = ac->che[type][id]->ch[1].ret;
+(*channels)++;
}
}
} else {
@@ -163,6 +164,64 @@ static av_cold int che_configure(AACContext *ac,
return 0;
}
+static int frame_configure_elements(AVCodecContext *avctx, int is_init)
+{
+AACContext *ac = avctx->priv_data;
+ChannelElement *che;
+int ch, i, ret;
+int type, id, pos;
+
+/* set channel pointers to internal buffers by default */
+for (type = 0; type < 4; type++) {
+for (id = 0; id < MAX_ELEM_ID; id++) {
+che = ac->che[type][id];
+if (che) {
+che->ch[0].ret = che->ch[0].ret_buf;
+che->ch[1].ret = che->ch[1].ret_buf;
+}
+}
+}
+
+/* if this function was called during initialization, we do not need to
+ call get_buffer() or map output channel pointers */
+if (is_init)
+return 0;
+
+/* get output buffer */
+if (!ac->got_frame_buffer ||
+ac->oc[1].channel_layout != ac->frame.channel_layout) {
+ac->frame.nb_samples = 2048;
+if ((ret = avctx->get_buffer(avctx, &ac->frame)) < 0) {
+av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n");
+return ret;
+}
+ac->got_frame_buffer = 1;
+}
+
+/* map output channel pointers to AVFrame data */
+ch = 0;
+for (i = 0; i < ac->oc[1].layout_map_tags; i++) {
+type = ac->oc[1].layout_map[i][0];
+id = ac->oc[1].layout_map[i][1];
+pos = ac->oc[1].layout_map[i][2];
+
+che = ac->che[type][id];
+if (che && pos && type != TYPE_CCE) {
+if (ch >= avctx->channels)
+return AVERROR(EINVAL);
+che->ch[0].ret = (float *)ac->frame.extended_data[ch++];
+if (type == TYPE_CPE ||
+(type == TYPE_SCE && ac->oc[1].m4ac.ps == 1)) {
+if (ch >= avctx->channels)
+return AVERROR(EINVAL);
+che->ch[1].ret = (float *)ac->frame.extended_data[ch++];
+}
+}
+}
+
+return 0;
+}
+
struct elem_to_channel {
uint64_t av_position;
uint8_t syn_ele;
@@ -378,22 +437,24 @@ static void pop_output_configuration(AACContext *ac) {
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
Hi, On Sat, Oct 13, 2012 at 9:05 AM, Diego Biurrun wrote: > On Sat, Oct 13, 2012 at 10:04:50AM -0500, Daniel Kang wrote: >> +%macro op_avgh 3 >> +movh %3, %2 >> +pavgb %1, %3 >> +movh %2, %1 >> +%endmacro >> + >> +%macro op_avg 3 >> +pavgb %1, %2 >> +mova %2, %1 >> +%endmacro >> + >> +%macro op_puth 3 >> +movh %2, %1 >> +%endmacro >> + >> +%macro op_put 3 >> +mova %2, %1 >> +%endmacro > > All of these macros only take 2 parameters. op_avgh takes 3. >> +.loop: >> +movh m1, [r1-1] >> +movh m2, [r1+0] >> +movh m3, [r1+1] >> +movh m0, [r1+2] > > Spaces around operators would help readability IMO; more below... No spaces around operators in assembly dereferences please. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
Martin Storsjö writes: > On Sat, 13 Oct 2012, Måns Rullgård wrote: > >> Martin Storsjö writes: >> >>> @@ -2930,6 +2944,9 @@ build the shared libraries as well. To only build the >>> shared libraries specify >>> EOF >>> exit 1; >>> fi >>> +if enabled_all msvc static shared; then >>> +die "Cannot build shared and static libraries at the same time with >>> MSVC." >>> +fi >> >> Another idea is to simply disable static if shared is enabled. That way >> users can simply configure --enable-shared and save some pointless typing. > > Sounds sane, changed locally into: > > +if enabled_all msvc shared; then > +# Cannot build shared and static libraries at the same time with MSVC. > +disable static > +fi That can be condensed to "enabled_all msvc shared && disable static" Another way to do the same is by declaring static_deps_any="!msvc !shared" -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, 13 Oct 2012, Måns Rullgård wrote: Martin Storsjö writes: @@ -2930,6 +2944,9 @@ build the shared libraries as well. To only build the shared libraries specify EOF exit 1; fi +if enabled_all msvc static shared; then +die "Cannot build shared and static libraries at the same time with MSVC." +fi Another idea is to simply disable static if shared is enabled. That way users can simply configure --enable-shared and save some pointless typing. Sounds sane, changed locally into: +if enabled_all msvc shared; then +# Cannot build shared and static libraries at the same time with MSVC. +disable static +fi +#if CONFIG_SHARED && defined(_WIN32) && !defined(COMPILING_avcodec) +#define avcodec_exportdata __declspec(dllimport) +#else +#define avcodec_exportdata +#endif I want to think about this some more. Ok diff --git a/library.mak b/library.mak index b365935..56a4586 100644 --- a/library.mak +++ b/library.mak @@ -33,6 +33,7 @@ install-libs-$(CONFIG_STATIC): install-lib$(NAME)-static install-libs-$(CONFIG_SHARED): install-lib$(NAME)-shared define RULES +$(OBJS): CPPFLAGS += -DCOMPILING_$(NAME)=1 $(EXAMPLES) $(TOOLS): THISLIB = $(FULLNAME:%=$(LD_LIB)) $(TESTPROGS): THISLIB = $(SUBDIR)$(LIBNAME) This could use a blank line. Done locally. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
Martin Storsjö writes: > diff --git a/configure b/configure > index b30d69b..b70b1ec 100755 > --- a/configure > +++ b/configure > @@ -2794,6 +2794,20 @@ case $target_os in > add_cppflags -U__STRICT_ANSI__ > ;; > win32|win64) > +# Link to the import library instead of the normal static library for > +# shared libs. > +enabled shared && LD_LIB='%.lib' > +shlibdir_default="$bindir_default" > +SLIBPREF="" > +SLIBSUF=".dll" > + > SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' > +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' > +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > > $$(@:$(SLIBSUF)=.def)' > +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' > +SLIB_INSTALL_LINKS= > +SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' > +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' > +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) > -implib:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)' > objformat="win32" > ranlib=: > enable dos_paths This is looking reasonable. > @@ -2930,6 +2944,9 @@ build the shared libraries as well. To only build the > shared libraries specify > EOF > exit 1; > fi > +if enabled_all msvc static shared; then > +die "Cannot build shared and static libraries at the same time with > MSVC." > +fi Another idea is to simply disable static if shared is enabled. That way users can simply configure --enable-shared and save some pointless typing. > +#if CONFIG_SHARED && defined(_WIN32) && !defined(COMPILING_avcodec) > +#define avcodec_exportdata __declspec(dllimport) > +#else > +#define avcodec_exportdata > +#endif I want to think about this some more. > diff --git a/library.mak b/library.mak > index b365935..56a4586 100644 > --- a/library.mak > +++ b/library.mak > @@ -33,6 +33,7 @@ install-libs-$(CONFIG_STATIC): install-lib$(NAME)-static > install-libs-$(CONFIG_SHARED): install-lib$(NAME)-shared > > define RULES > +$(OBJS): CPPFLAGS += -DCOMPILING_$(NAME)=1 > $(EXAMPLES) $(TOOLS): THISLIB = $(FULLNAME:%=$(LD_LIB)) > $(TESTPROGS): THISLIB = $(SUBDIR)$(LIBNAME) This could use a blank line. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, 13 Oct 2012, Dave Yeo wrote: On 10/13/12 10:23 am, Martin Storsjö wrote: This requires the makedef perl script by Derek, which probably will go into the c99-to-c89 repo. That scripts produces a .def file, listing the symbols to be exported, based on the gcc version scripts and the built object files. Where is the makedef script currently? You can grab a copy of it from http://albin.abo.fi/~mstorsjo/makedef right now, I'll push it to the c99-to-c89 repo once the rest of this is settled. Perhaps it should be named makedef.pl? Hmm, not sure I agree - the fact that it's a perl script isn't of much significance, you could swap it out for anything else with the same syntax implemented in a different language if you'd want. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On 10/13/12 10:23 am, Martin Storsjö wrote: This requires the makedef perl script by Derek, which probably will go into the c99-to-c89 repo. That scripts produces a .def file, listing the symbols to be exported, based on the gcc version scripts and the built object files. Where is the makedef script currently? Perhaps it should be named makedef.pl? Dave ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
Martin Storsjö writes:
> The name mingw32 as target OS is both misleading, and very little
> of the target OS specific settings actually match.
>
> Since the target OS default is set based on uname, the default
> (which on MSYS is set to mingw) is overridden by --toolchain=msvc.
> ---
> configure | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index 0992ff7..b30d69b 100755
> --- a/configure
> +++ b/configure
> @@ -2033,8 +2033,6 @@ if enabled cross_compile; then
> die "Must specify target arch and OS when cross-compiling"
> fi
>
> -set_default arch target_os
> -
> ar_default="${cross_prefix}${ar_default}"
> cc_default="${cross_prefix}${cc_default}"
> nm_default="${cross_prefix}${nm_default}"
> @@ -2049,13 +2047,14 @@ case "$toolchain" in
> ld_default="c99wrap link"
> nm_default="dumpbin -symbols"
> ar_default="lib"
> +target_os_default="win32"
> ;;
> ?*)
> die "Unknown toolchain $toolchain"
> ;;
> esac
>
> -set_default cc pkg_config sysinclude
> +set_default arch cc pkg_config sysinclude target_os
> enabled cross_compile || host_cc_default=$cc
> set_default host_cc
>
> @@ -2066,7 +2065,7 @@ fi
>
> exesuf() {
> case $1 in
> -mingw32*|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo .exe ;;
> +mingw32*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian)
> echo .exe ;;
> esac
> }
>
> @@ -2794,6 +2793,11 @@ case $target_os in
> enable dos_paths
> add_cppflags -U__STRICT_ANSI__
> ;;
> +win32|win64)
> +objformat="win32"
> +ranlib=:
> +enable dos_paths
> +;;
> cygwin*)
> target_os=cygwin
> shlibdir_default="$bindir_default"
> --
Looks OK
--
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, 13 Oct 2012, Hendrik Leppkes wrote:
On Sat, Oct 13, 2012 at 9:43 PM, Martin Storsjö wrote:
The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.
Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
---
configure | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 0992ff7..b30d69b 100755
--- a/configure
+++ b/configure
@@ -2033,8 +2033,6 @@ if enabled cross_compile; then
die "Must specify target arch and OS when cross-compiling"
fi
-set_default arch target_os
-
ar_default="${cross_prefix}${ar_default}"
cc_default="${cross_prefix}${cc_default}"
nm_default="${cross_prefix}${nm_default}"
@@ -2049,13 +2047,14 @@ case "$toolchain" in
ld_default="c99wrap link"
nm_default="dumpbin -symbols"
ar_default="lib"
+target_os_default="win32"
If we want "win64" to be a thing, maybe it should differentiate here
and set the appropriate one?
Currently it doesn't matter at all which one of them you set, so it's not
really necessary here, but it might ease the mind of some caller who wants
to set --target-os=win64.
// Martin___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, Oct 13, 2012 at 9:43 PM, Martin Storsjö wrote:
> The name mingw32 as target OS is both misleading, and very little
> of the target OS specific settings actually match.
>
> Since the target OS default is set based on uname, the default
> (which on MSYS is set to mingw) is overridden by --toolchain=msvc.
> ---
> configure | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index 0992ff7..b30d69b 100755
> --- a/configure
> +++ b/configure
> @@ -2033,8 +2033,6 @@ if enabled cross_compile; then
> die "Must specify target arch and OS when cross-compiling"
> fi
>
> -set_default arch target_os
> -
> ar_default="${cross_prefix}${ar_default}"
> cc_default="${cross_prefix}${cc_default}"
> nm_default="${cross_prefix}${nm_default}"
> @@ -2049,13 +2047,14 @@ case "$toolchain" in
> ld_default="c99wrap link"
> nm_default="dumpbin -symbols"
> ar_default="lib"
> +target_os_default="win32"
If we want "win64" to be a thing, maybe it should differentiate here
and set the appropriate one?
- Hendrik
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 10:43:19PM +0300, Martin Storsjö wrote: > --- > configure | 17 + > libavcodec/ac3tab.h|3 ++- > libavcodec/dca.h |3 ++- > libavcodec/internal.h |7 +++ > libavcodec/mjpeg.h | 15 --- > libavcodec/mpeg12data.h|3 ++- > libavcodec/mpeg4audio.h|3 ++- > libavcodec/mpegaudiodata.h |6 -- > library.mak|1 + > 9 files changed, 45 insertions(+), 13 deletions(-) LGTM, but wait for more opinions. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, Oct 13, 2012 at 10:43:18PM +0300, Martin Storsjö wrote: > The name mingw32 as target OS is both misleading, and very little > of the target OS specific settings actually match. > > Since the target OS default is set based on uname, the default > (which on MSYS is set to mingw) is overridden by --toolchain=msvc. > --- > configure | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) LGTM, but wait for more opinions. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
From: "Ronald S. Bultje"
This requires the makedef perl script by Derek, from the c89-to-c99
repo. That scripts produces a .def file, listing the symbols to be
exported, based on the gcc version scripts and the built object files.
To properly load non-function symbols from DLL files, the data
symbol declarations need to have the attribute __declspec(dllimport)
when building the calling code. (On mingw, the linker can fix this
up automatically, which is why it has not been an issue so far.)
The __declspec(dllimport) attribute is added via a macro. Since
it has to be present when building code that refers to these symbols,
but not be present while building the library that exports the symbols
themselves, the Makefile is modified to add a define like
COMPILING_ while building each library. This is used in the
definition of the _exportdata macro - on non-MSVC compilers, it is
empty. On MSVC, it is __declspec(dllimport) for declarations in other
libraries than the object file currently compiled.
This also implies that code that is built to link to a certain
library as a DLL can't link to the same library as a static library.
Therefore, we only allow building either static or shared but not
both at the same time. (That is, static libraries as such can be,
and actually are, built - this is used for linking the test tools to
internal symbols in the libraries - but e.g. libavformat object files
built to link to libavcodec as a DLL cannot link statically to
libavcodec.)
Also, linking to DLLs is slightly different from linking to shared
libraries on other platforms. DLLs use a thing called import
libraries, which is basically a stub library allowing the linker
to know which symbols exist in the DLL and what name the DLL will
have at runtime.
In mingw/gcc, the import library is usually named libfoo.dll.a,
which goes next to a static library named libfoo.a. This allows gcc
to pick the dynamic one, if available, from the normal -lfoo switches,
just as it does for libfoo.a vs libfoo.so on Unix. On MSVC however,
you need to literally specify the name of the import library instead of
the static library.
---
configure | 17 +
libavcodec/ac3tab.h|3 ++-
libavcodec/dca.h |3 ++-
libavcodec/internal.h |7 +++
libavcodec/mjpeg.h | 15 ---
libavcodec/mpeg12data.h|3 ++-
libavcodec/mpeg4audio.h|3 ++-
libavcodec/mpegaudiodata.h |6 --
library.mak|1 +
9 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/configure b/configure
index b30d69b..b70b1ec 100755
--- a/configure
+++ b/configure
@@ -2794,6 +2794,20 @@ case $target_os in
add_cppflags -U__STRICT_ANSI__
;;
win32|win64)
+# Link to the import library instead of the normal static library for
+# shared libs.
+enabled shared && LD_LIB='%.lib'
+shlibdir_default="$bindir_default"
+SLIBPREF=""
+SLIBSUF=".dll"
+SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
+SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
+SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
$$(@:$(SLIBSUF)=.def)'
+SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
+SLIB_INSTALL_LINKS=
+SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
+SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
+SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
-implib:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
objformat="win32"
ranlib=:
enable dos_paths
@@ -2930,6 +2944,9 @@ build the shared libraries as well. To only build the
shared libraries specify
EOF
exit 1;
fi
+if enabled_all msvc static shared; then
+die "Cannot build shared and static libraries at the same time with MSVC."
+fi
die_license_disabled() {
enabled $1 || { enabled $2 && die "$2 is $1 and --enable-$1 is not
specified."; }
diff --git a/libavcodec/ac3tab.h b/libavcodec/ac3tab.h
index 8ed5052..5e11e58 100644
--- a/libavcodec/ac3tab.h
+++ b/libavcodec/ac3tab.h
@@ -24,6 +24,7 @@
#include "libavutil/common.h"
#include "ac3.h"
+#include "internal.h"
#if CONFIG_HARDCODED_TABLES
# define HCONST const
@@ -33,7 +34,7 @@
extern const uint16_t ff_ac3_frame_size_tab[38][3];
extern const uint8_t ff_ac3_channels_tab[8];
-extern const uint16_t avpriv_ac3_channel_layout_tab[8];
+extern avcodec_exportdata const uint16_t avpriv_ac3_channel_layout_tab[8];
extern const uint8_t ff_ac3_enc_channel_map[8][2][6];
extern const uint8_t ff_ac3_dec_channel_map[8][2][6];
extern const uint16_t ff_ac3_sample_rate_tab[3];
diff --git a/libavcodec/dca.h b/libavcodec/dca.h
index 1515270..ec2ffea 100644
--- a/libavcodec/dca.h
+++ b/libavcodec/dca.h
@@ -26,6 +26,7 @@
#define AVCODEC_DCA_H
#include
+#include "internal.h"
/** DCA syncwords, also used for bitstream type detection */
#define DCA_MARK
[libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.
Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
---
configure | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 0992ff7..b30d69b 100755
--- a/configure
+++ b/configure
@@ -2033,8 +2033,6 @@ if enabled cross_compile; then
die "Must specify target arch and OS when cross-compiling"
fi
-set_default arch target_os
-
ar_default="${cross_prefix}${ar_default}"
cc_default="${cross_prefix}${cc_default}"
nm_default="${cross_prefix}${nm_default}"
@@ -2049,13 +2047,14 @@ case "$toolchain" in
ld_default="c99wrap link"
nm_default="dumpbin -symbols"
ar_default="lib"
+target_os_default="win32"
;;
?*)
die "Unknown toolchain $toolchain"
;;
esac
-set_default cc pkg_config sysinclude
+set_default arch cc pkg_config sysinclude target_os
enabled cross_compile || host_cc_default=$cc
set_default host_cc
@@ -2066,7 +2065,7 @@ fi
exesuf() {
case $1 in
-mingw32*|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo .exe ;;
+mingw32*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
esac
}
@@ -2794,6 +2793,11 @@ case $target_os in
enable dos_paths
add_cppflags -U__STRICT_ANSI__
;;
+win32|win64)
+objformat="win32"
+ranlib=:
+enable dos_paths
+;;
cygwin*)
target_os=cygwin
shlibdir_default="$bindir_default"
--
1.7.9.5
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On 13/10/2012 3:29 PM, Hendrik Leppkes wrote: > ICL on windows mimics MSVCs behaviour rather strictly so it can be > used as a more-or-less drop-in replacement, fwiw. With the exception of supporting C99, which I think is being addressed in Adam's patch anyway. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 9:21 PM, Diego Biurrun wrote: > >> >>+#if CONFIG_SHARED && defined(_MSC_VER) && !defined(COMPILING_avcodec) >> > >> >This condition seems a bit too specific. There are other compilers. >> >> That might be good for consistency, even if mingw can do without it. >> So something like this then: >> >> #if CONFIG_SHARED && defined(_WIN32) && !defined(COMPILING_avcodec) > > Careful, we might soon get support for ICL, which might or might not > need this. _WIN32 seems too greedy to me. > ICL on windows mimics MSVCs behaviour rather strictly so it can be used as a more-or-less drop-in replacement, fwiw. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 09:50:59PM +0300, Martin Storsjö wrote: > On Sat, 13 Oct 2012, Måns Rullgård wrote: > >Martin Storsjö writes: > >>--- a/configure > >>+++ b/configure > >>@@ -2794,6 +2794,29 @@ case $target_os in > >> add_cppflags -U__STRICT_ANSI__ > >> ;; > >> msvc) > >>+if enabled shared; then > >>+# Link to the import library instead of the > >>+# normal static library. > >>+LD_LIB='%.lib' > >>+enabled static && > >>+die "Cannot build shared and static libraries at the same > >>time with MSVC." > >>+fi > > > >The static+shared error feels misplaced here. > > Yeah, it's a bit weird here. What section would be a better match? Maybe around line 2931 with the check that at least one library type is built. > >>--- /dev/null > >>+++ b/libavcodec/symbols.h > > > >As nondescriptive filenames go, this one ranks pretty darn high. > > Indeed. Since this doesn't need to be installed, perhaps we could > just put it into internal.h instead? Sounds like a good place to me, we have other attributes in there. > >>+#if CONFIG_SHARED && defined(_MSC_VER) && !defined(COMPILING_avcodec) > > > >This condition seems a bit too specific. There are other compilers. > > That might be good for consistency, even if mingw can do without it. > So something like this then: > > #if CONFIG_SHARED && defined(_WIN32) && !defined(COMPILING_avcodec) Careful, we might soon get support for ICL, which might or might not need this. _WIN32 seems too greedy to me. > >>--- a/library.mak > >>+++ b/library.mak > >>@@ -19,6 +19,7 @@ $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm > >>$(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) > >>$(YASM) $(YASMFLAGS) -I $( >> > >>+$(OBJS): CPPFLAGS := -DCOMPILING_$(NAME)=1 $(CPPFLAGS) > > > >This should use += > > Ok, will change. That line is mine and I think I initially used +=, but at that point in time it did not work for some reason. There have been changes to that area since, so it might well work now, but doublecheck to be sure. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
Martin Storsjö writes: > On Sat, 13 Oct 2012, Martin Storsjö wrote: > diff --git a/library.mak b/library.mak index b365935..318fe86 100644 --- a/library.mak +++ b/library.mak @@ -19,6 +19,7 @@ $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm $(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) $(YASM) $(YASMFLAGS) -I $(>>> +$(OBJS): CPPFLAGS := -DCOMPILING_$(NAME)=1 $(CPPFLAGS) >>> >>> This should use += >> >> Ok, will change. > > Actually, there seems to be some subtlety here I don't understand > off-hand - when I change this to use +=, it ends up defining > -DCOMPILING_avutil while building avcodec (probably while building all > of them). Ah, that's because evaluation of $(NAME) is deferred. If you stick that line inside the RULES macro it should work. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] nut: export codec_tag provided by rawvideo
Raw audio does not provide valid audio tags while rawvideo does.
The fate refs have to be updated because it undoes the previous tag
change.
---
I'm thinking about adding specific nut tests and move to -f rawvideo
for those.
libavformat/nutenc.c | 2 +-
tests/ref/lavfi/crop | 2 +-
tests/ref/lavfi/crop_scale | 2 +-
tests/ref/lavfi/crop_scale_vflip | 2 +-
tests/ref/lavfi/crop_vflip | 2 +-
tests/ref/lavfi/null | 2 +-
tests/ref/lavfi/pixdesc | 114 +++
tests/ref/lavfi/pixfmts_copy | 114 +++
tests/ref/lavfi/pixfmts_crop | 82 ++--
tests/ref/lavfi/pixfmts_hflip| 82 ++--
tests/ref/lavfi/pixfmts_null | 114 +++
tests/ref/lavfi/pixfmts_pad | 34 ++--
tests/ref/lavfi/pixfmts_scale| 114 +++
tests/ref/lavfi/pixfmts_vflip| 114 +++
tests/ref/lavfi/scale200 | 2 +-
tests/ref/lavfi/scale500 | 2 +-
tests/ref/lavfi/vflip| 2 +-
tests/ref/lavfi/vflip_crop | 2 +-
tests/ref/lavfi/vflip_vflip | 2 +-
19 files changed, 395 insertions(+), 395 deletions(-)
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 6338924..9985cd9 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -385,7 +385,7 @@ static int write_streamheader(AVFormatContext *avctx,
AVIOContext *bc, AVStream
}
ff_put_v(bc, 4);
-if (!codec_tag)
+if (!codec_tag || codec->codec_id == AV_CODEC_ID_RAWVIDEO)
codec_tag = codec->codec_tag;
if (codec_tag) {
diff --git a/tests/ref/lavfi/crop b/tests/ref/lavfi/crop
index 81ce4d1..32041c2 100644
--- a/tests/ref/lavfi/crop
+++ b/tests/ref/lavfi/crop
@@ -1 +1 @@
-crop64e8f986d4cc67ec6797f5adb486e43f
+crop3d163f156eaddf41d2be20736f973539
diff --git a/tests/ref/lavfi/crop_scale b/tests/ref/lavfi/crop_scale
index 4eb20c8..82e5394 100644
--- a/tests/ref/lavfi/crop_scale
+++ b/tests/ref/lavfi/crop_scale
@@ -1 +1 @@
-crop_scale 011cb96fad3d86823e4441e305814834
+crop_scale 0a3d45d58b805b8c47416b9239535f94
diff --git a/tests/ref/lavfi/crop_scale_vflip b/tests/ref/lavfi/crop_scale_vflip
index a89297a..07c729a 100644
--- a/tests/ref/lavfi/crop_scale_vflip
+++ b/tests/ref/lavfi/crop_scale_vflip
@@ -1 +1 @@
-crop_scale_vflipf2b3800ab986d147b8ed5ebae67152df
+crop_scale_vflipe88a4dfb960d0bb28ee875567bedde5d
diff --git a/tests/ref/lavfi/crop_vflip b/tests/ref/lavfi/crop_vflip
index 759d744..a3f8200 100644
--- a/tests/ref/lavfi/crop_vflip
+++ b/tests/ref/lavfi/crop_vflip
@@ -1 +1 @@
-crop_vflip f9a15b41ea4034a15d39a2b6f649f1c5
+crop_vflip 628542e17b6900ee79b1429183ae01b0
diff --git a/tests/ref/lavfi/null b/tests/ref/lavfi/null
index dcb6bdf..3c3b7b7 100644
--- a/tests/ref/lavfi/null
+++ b/tests/ref/lavfi/null
@@ -1 +1 @@
-null46235acb958138b6a77976601b7045ec
+nulleba2f135a08829387e2f698ff72a2939
diff --git a/tests/ref/lavfi/pixdesc b/tests/ref/lavfi/pixdesc
index c142ba2..dc1b857 100644
--- a/tests/ref/lavfi/pixdesc
+++ b/tests/ref/lavfi/pixdesc
@@ -1,66 +1,66 @@
-abgr73847fb78ab01d040bc65307aa2e772d
-argb68262dbda747e9552cf04a06632a7cee
-bgr24 e288c39c730970ee1056e858adc094a2
-bgr444bed15710f070a201afe2da5bd2fc1c5c76
-bgr444lefb261abd38568e10f8ebb0be52c207ce
-bgr48be 754a33cf60aed44a890d194eb571ec2c
-bgr48le 605447329b7242e41e6e4bcc36f87d06
-bgr4_byte 9028891b9beedf5e1e37f627980da330
-bgr555be9e49d38ab65413f382cafd46ac469640
-bgr555lefe4784e5d4f66130fa63dee552e4720d
-bgr565be90625bce942c002aa1b55e6d77d515e2
-bgr565led036946273d95741eb7a0593988a7090
-bgr82180b117a65abfd26a70458c535aa9b1
-bgra328a76e72c55508cdf04dc93a5b056fc
-gray847f04953fd848b8c86164d9ba93f54b
-gray16be56cb2303e2f5f2d3a9260db3d6de26ab
-gray16le56cb2303e2f5f2d3a9260db3d6de26ab
-monob 0bcbf98de0e633e6ccb62efeb9ab58ef
-monow 37c78ca41610436acf9adf5bca7faea7
-nv12d5e62031f9870c9d7ff5544475f6e590
-nv211f695aff75622765316c3dea6e3f2647
-rgb24 8008d64571c68fce43c083b83513eac3
-rgb444be40308261161f0c54c0b5a11ce1286d11
-rgb444leb7a68135e696901059751d6a55f40df6
-rgb48be 3044840d35ce6550f77942f8204ba13d
-rgb48le 8b57ae0801998fc463cfd601761d1686
-rgb4_byte 109b9756a6dc5fae6486af9aad150ead
-rgb555bee9a77d923399e647c8f588b3be4cc393
+abgr037bf9df6a765520ad6d490066bf4b89
+argbc442a8261c2265a07212ef0f72e35f5a
+bgr24 0d0cb38ab3fa0b2ec0
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, 13 Oct 2012, Martin Storsjö wrote: diff --git a/library.mak b/library.mak index b365935..318fe86 100644 --- a/library.mak +++ b/library.mak @@ -19,6 +19,7 @@ $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm $(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) $(YASM) $(YASMFLAGS) -I $( This should use += Ok, will change. Actually, there seems to be some subtlety here I don't understand off-hand - when I change this to use +=, it ends up defining -DCOMPILING_avutil while building avcodec (probably while building all of them). // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, 13 Oct 2012, Måns Rullgård wrote: Martin Storsjö writes: diff --git a/configure b/configure index 667089b..362f8d1 100755 --- a/configure +++ b/configure @@ -2794,6 +2794,29 @@ case $target_os in add_cppflags -U__STRICT_ANSI__ ;; msvc) +if enabled shared; then +# Link to the import library instead of the +# normal static library. +LD_LIB='%.lib' +enabled static && +die "Cannot build shared and static libraries at the same time with MSVC." +fi The static+shared error feels misplaced here. Yeah, it's a bit weird here. What section would be a better match? +LIBTARGET=i386 +if enabled x86_64; then +LIBTARGET=x64 +fi enabled x86_64 && LIBTARGET=i386 || LIBTARGET=x64 +shlibdir_default="$bindir_default" +SLIBPREF="" +SLIBSUF=".dll" +SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)' Is makedef a friend of c99wrap? Yeah, we'll put it into the same repo. +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET) -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)' +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' +SLIB_INSTALL_LINKS= +SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' Should the .lib file really end up in $bindir? That doesn't feel right at all. It's pretty weird, but this is the convention - we do it the same way for mingw. +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)' The mentino of .dll.a there is confusing. Can you please tell me which command produce/consume what files? I have the distinct feeling all this can be cleaned up considerably. Indeed, this turned out to have some duplication I missed before. link.exe creates one import library, then we created a separate one using lib.exe. I'll change this to not use lib.exe at all and make link.exe produce the .lib named import library straight away. After my local changes, link.exe produces e.g. avutil.lib, which is used by LD_LIB when linking the avcodec DLL and all other DLLs/executables. +extern AVCODEC_SYMBOL const uint16_t avpriv_ac3_channel_layout_tab[8]; If this annotation is really required, please do two things: 1. Call it something at least halfway descriptive. 2. Make it less of an eyesore (i.e. not uppercase). Right, like avcodec_exportdata or so? It needs to have the lib name included, since it should be enabled/disabled per library. diff --git a/libavcodec/symbols.h b/libavcodec/symbols.h new file mode 100644 index 000..3c98d46 --- /dev/null +++ b/libavcodec/symbols.h As nondescriptive filenames go, this one ranks pretty darn high. Indeed. Since this doesn't need to be installed, perhaps we could just put it into internal.h instead? [...] +#if CONFIG_SHARED && defined(_MSC_VER) && !defined(COMPILING_avcodec) This condition seems a bit too specific. There are other compilers. That might be good for consistency, even if mingw can do without it. So something like this then: #if CONFIG_SHARED && defined(_WIN32) && !defined(COMPILING_avcodec) +#define AVCODEC_SYMBOL __declspec(dllimport) +#else +#define AVCODEC_SYMBOL +#endif + +#endif /* AVCODEC_SYMBOLS_H */ diff --git a/library.mak b/library.mak index b365935..318fe86 100644 --- a/library.mak +++ b/library.mak @@ -19,6 +19,7 @@ $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm $(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) $(YASM) $(YASMFLAGS) -I $( This should use += Ok, will change. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
Martin Storsjö writes: > On Sat, 13 Oct 2012, Hendrik Leppkes wrote: > >> On Sat, Oct 13, 2012 at 8:14 PM, Måns Rullgård wrote: >>> Hendrik Leppkes writes: >>> On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis wrote: > On 13/10/2012 1:29 PM, Måns Rullgård wrote: >> I don't really like calling the OS msvc. That is the compiler. How >> about "windows"? > > By that logic, shouldn't we also call mingw32 "windows"? > Yeah, technically its the same OS, and the configuration how to create shared libraries doesn't belong in a OS section, but a toolchain section - but thats being done for like every OS, because in most cases there is an assumption that there is only one wide-spread compiler/linker for that target OS. >>> >>> The way (shared) libraries are built is usually dictated much more by >>> the OS than by the specific compiler. It is, after all, the OS that in >>> the end will be loading them. Windows is the odd one out here with at >>> least three totally different schemes in common use. >>> >>> If you look at the other ones, the settings are very much per OS and >>> hardly per compiler at all. Symbian is a prime example, building with >>> gcc yet needing a raft of special flags. >>> In any case, i would suggest going with something as simple as "windows" or "win32" to stick with microsofts short-form :p >>> >>> I'm fine with win32 as well. Is the 64-bit Windows also called win32? >>> >> >> Win64 is used sometimes when you want to stress the difference, but >> its the same OS in 64-bit, does it make sense to separate here? Maybe >> stick to "windows" and keep the 32/64 out of it to avoid confusion? > > Some of the target_os cases have * to match different settings, I can > set it to win*. That sounds a bit greedy. Matching win32|win64 should be safe. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, 13 Oct 2012, Hendrik Leppkes wrote: On Sat, Oct 13, 2012 at 8:14 PM, Måns Rullgård wrote: Hendrik Leppkes writes: On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis wrote: On 13/10/2012 1:29 PM, Måns Rullgård wrote: I don't really like calling the OS msvc. That is the compiler. How about "windows"? By that logic, shouldn't we also call mingw32 "windows"? Yeah, technically its the same OS, and the configuration how to create shared libraries doesn't belong in a OS section, but a toolchain section - but thats being done for like every OS, because in most cases there is an assumption that there is only one wide-spread compiler/linker for that target OS. The way (shared) libraries are built is usually dictated much more by the OS than by the specific compiler. It is, after all, the OS that in the end will be loading them. Windows is the odd one out here with at least three totally different schemes in common use. If you look at the other ones, the settings are very much per OS and hardly per compiler at all. Symbian is a prime example, building with gcc yet needing a raft of special flags. In any case, i would suggest going with something as simple as "windows" or "win32" to stick with microsofts short-form :p I'm fine with win32 as well. Is the 64-bit Windows also called win32? Win64 is used sometimes when you want to stress the difference, but its the same OS in 64-bit, does it make sense to separate here? Maybe stick to "windows" and keep the 32/64 out of it to avoid confusion? Some of the target_os cases have * to match different settings, I can set it to win*. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, Oct 13, 2012 at 8:14 PM, Måns Rullgård wrote: > Hendrik Leppkes writes: > >> On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis >> wrote: >>> On 13/10/2012 1:29 PM, Måns Rullgård wrote: I don't really like calling the OS msvc. That is the compiler. How about "windows"? >>> >>> By that logic, shouldn't we also call mingw32 "windows"? >>> >> >> Yeah, technically its the same OS, and the configuration how to create >> shared libraries doesn't belong in a OS section, but a toolchain >> section - but thats being done for like every OS, because in most >> cases there is an assumption that there is only one wide-spread >> compiler/linker for that target OS. > > The way (shared) libraries are built is usually dictated much more by > the OS than by the specific compiler. It is, after all, the OS that in > the end will be loading them. Windows is the odd one out here with at > least three totally different schemes in common use. > > If you look at the other ones, the settings are very much per OS and > hardly per compiler at all. Symbian is a prime example, building with > gcc yet needing a raft of special flags. > >> In any case, i would suggest going with something as simple as >> "windows" or "win32" to stick with microsofts short-form :p > > I'm fine with win32 as well. Is the 64-bit Windows also called win32? > Win64 is used sometimes when you want to stress the difference, but its the same OS in 64-bit, does it make sense to separate here? Maybe stick to "windows" and keep the 32/64 out of it to avoid confusion? ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Refactor CPPFLAGS settings for glibc
Diego Biurrun writes: > On Sat, Oct 13, 2012 at 06:27:57PM +0100, Måns Rullgård wrote: >> Diego Biurrun writes: >> > --- a/configure >> > +++ b/configure >> > @@ -2819,7 +2819,6 @@ case $target_os in >> > add_cppflags -U__STRICT_ANSI__ >> > ;; >> > linux) >> > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 >> > enable dv1394 >> > ;; >> > @@ -2850,10 +2849,9 @@ case $target_os in >> > enable dos_paths >> > ;; >> > gnu/kfreebsd) >> > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 >> > -D_BSD_SOURCE >> > +add_cppflags -D_BSD_SOURCE >> > ;; >> > gnu) >> > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 >> > ;; >> > qnx) >> > @@ -2890,6 +2888,7 @@ if check_cpp_condition features.h "defined >> > __UCLIBC__"; then >> > libc_type=uclibc >> > elif check_cpp_condition features.h "defined __GLIBC__"; then >> > libc_type=glibc >> > +add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 >> > elif check_header _mingw.h; then >> > libc_type=mingw >> > check_cpp_condition _mingw.h \ >> >> This might need adjusting for linux/uclibc to work. > > Do you have a system at hand to test? Or do you suggest just adding > the flags to the uclibc section as well? I have more than one. I'll test it and report back. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Refactor CPPFLAGS settings for glibc
On Sat, Oct 13, 2012 at 06:27:57PM +0100, Måns Rullgård wrote: > Diego Biurrun writes: > > --- a/configure > > +++ b/configure > > @@ -2819,7 +2819,6 @@ case $target_os in > > add_cppflags -U__STRICT_ANSI__ > > ;; > > linux) > > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > > enable dv1394 > > ;; > > @@ -2850,10 +2849,9 @@ case $target_os in > > enable dos_paths > > ;; > > gnu/kfreebsd) > > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > > -D_BSD_SOURCE > > +add_cppflags -D_BSD_SOURCE > > ;; > > gnu) > > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > > ;; > > qnx) > > @@ -2890,6 +2888,7 @@ if check_cpp_condition features.h "defined > > __UCLIBC__"; then > > libc_type=uclibc > > elif check_cpp_condition features.h "defined __GLIBC__"; then > > libc_type=glibc > > +add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > > elif check_header _mingw.h; then > > libc_type=mingw > > check_cpp_condition _mingw.h \ > > This might need adjusting for linux/uclibc to work. Do you have a system at hand to test? Or do you suggest just adding the flags to the uclibc section as well? Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
Hendrik Leppkes writes: > On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis > wrote: >> On 13/10/2012 1:29 PM, Måns Rullgård wrote: >>> I don't really like calling the OS msvc. That is the compiler. How >>> about "windows"? >> >> By that logic, shouldn't we also call mingw32 "windows"? >> > > Yeah, technically its the same OS, and the configuration how to create > shared libraries doesn't belong in a OS section, but a toolchain > section - but thats being done for like every OS, because in most > cases there is an assumption that there is only one wide-spread > compiler/linker for that target OS. The way (shared) libraries are built is usually dictated much more by the OS than by the specific compiler. It is, after all, the OS that in the end will be loading them. Windows is the odd one out here with at least three totally different schemes in common use. If you look at the other ones, the settings are very much per OS and hardly per compiler at all. Symbian is a prime example, building with gcc yet needing a raft of special flags. > In any case, i would suggest going with something as simple as > "windows" or "win32" to stick with microsofts short-form :p I'm fine with win32 as well. Is the 64-bit Windows also called win32? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
Martin Storsjö writes: > diff --git a/configure b/configure > index 667089b..362f8d1 100755 > --- a/configure > +++ b/configure > @@ -2794,6 +2794,29 @@ case $target_os in > add_cppflags -U__STRICT_ANSI__ > ;; > msvc) > +if enabled shared; then > +# Link to the import library instead of the > +# normal static library. > +LD_LIB='%.lib' > +enabled static && > +die "Cannot build shared and static libraries at the same > time with MSVC." > +fi The static+shared error feels misplaced here. > +LIBTARGET=i386 > +if enabled x86_64; then > +LIBTARGET=x64 > +fi enabled x86_64 && LIBTARGET=i386 || LIBTARGET=x64 > +shlibdir_default="$bindir_default" > +SLIBPREF="" > +SLIBSUF=".dll" > + > SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' > +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' > +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > > $$(@:$(SLIBSUF)=.def)' Is makedef a friend of c99wrap? > +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET) > -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)' > +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' > +SLIB_INSTALL_LINKS= > +SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' Should the .lib file really end up in $bindir? That doesn't feel right at all. > +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' > +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) > -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)' The mentino of .dll.a there is confusing. Can you please tell me which command produce/consume what files? I have the distinct feeling all this can be cleaned up considerably. > +extern AVCODEC_SYMBOL const uint16_t avpriv_ac3_channel_layout_tab[8]; If this annotation is really required, please do two things: 1. Call it something at least halfway descriptive. 2. Make it less of an eyesore (i.e. not uppercase). > diff --git a/libavcodec/symbols.h b/libavcodec/symbols.h > new file mode 100644 > index 000..3c98d46 > --- /dev/null > +++ b/libavcodec/symbols.h As nondescriptive filenames go, this one ranks pretty darn high. [...] > +#if CONFIG_SHARED && defined(_MSC_VER) && !defined(COMPILING_avcodec) This condition seems a bit too specific. There are other compilers. > +#define AVCODEC_SYMBOL __declspec(dllimport) > +#else > +#define AVCODEC_SYMBOL > +#endif > + > +#endif /* AVCODEC_SYMBOLS_H */ > diff --git a/library.mak b/library.mak > index b365935..318fe86 100644 > --- a/library.mak > +++ b/library.mak > @@ -19,6 +19,7 @@ $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm > $(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) > $(YASM) $(YASMFLAGS) -I $( > +$(OBJS): CPPFLAGS := -DCOMPILING_$(NAME)=1 $(CPPFLAGS) This should use += > $(OBJS) $(SUBDIR)%.h.o $(TESTOBJS): CPPFLAGS += -DHAVE_AV_CONFIG_H > $(TESTOBJS): CPPFLAGS += -DTEST -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, 13 Oct 2012, Hendrik Leppkes wrote: On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis wrote: On 13/10/2012 1:29 PM, Måns Rullgård wrote: I don't really like calling the OS msvc. That is the compiler. How about "windows"? By that logic, shouldn't we also call mingw32 "windows"? Yeah, technically its the same OS, and the configuration how to create shared libraries doesn't belong in a OS section, but a toolchain section - but thats being done for like every OS, because in most cases there is an assumption that there is only one wide-spread compiler/linker for that target OS. In any case, i would suggest going with something as simple as "windows" or "win32" to stick with microsofts short-form :p I'm ok with that, will update it accordingly. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] avutil: Give symbols used across libraries avpriv_ instead of ff_ prefixes
On Sat, Oct 13, 2012 at 06:18:07PM +0100, Måns Rullgård wrote: > Diego Biurrun writes: > > > --- > > libavcodec/bmpenc.c |2 +- > > libavcodec/rawdec.c |2 +- > > libavcodec/utils.c |2 +- > > libavutil/imgutils.c |4 ++-- > > libavutil/imgutils.h |2 +- > > 5 files changed, 6 insertions(+), 6 deletions(-) > > There seems to be only one such symbol so you could mention it in the > commit message. Locally amended to avutil: Rename ff_set_systematic_pal2() ---> avpriv_set_systematic_pal2() Functions used across libraries should have avpriv_ and not ff_ prefixes. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis wrote: > On 13/10/2012 1:29 PM, Måns Rullgård wrote: >> I don't really like calling the OS msvc. That is the compiler. How >> about "windows"? > > By that logic, shouldn't we also call mingw32 "windows"? > Yeah, technically its the same OS, and the configuration how to create shared libraries doesn't belong in a OS section, but a toolchain section - but thats being done for like every OS, because in most cases there is an assumption that there is only one wide-spread compiler/linker for that target OS. In any case, i would suggest going with something as simple as "windows" or "win32" to stick with microsofts short-form :p - Hendrik ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 08:23:26PM +0300, Martin Storsjö wrote: > From: "Ronald S. Bultje" > > This requires the makedef perl script by Derek, which probably will > go into the c99-to-c89 repo. That scripts produces a .def file, > listing the symbols to be exported, based on the gcc version > scripts and the built object files. This part of the commit message reads a bit ad-hoc. It describes the status of the development process at some point in time, but it does not really explain the commit itself. Not that this information would not be helpful, but it should instead be part of a documentation update that describes building shared libs with MSVC. > The __declspec(dllimport) attribute is added via a macro. Since > it has to be present when building code that refer to these symbols, referS > but not be present while building the library that exports the symbols > themselves, the makefile is modified to add a define like Makefile > Also, linking to DLLs is slightly different from linking to shared > libraries on other platforms. DLLs use a thing called import > libraries, which is basically a stub library allowing the linker > know which symbols exist in the DLL and what name the DLL will > have at runtime. to know > In mingw/gcc, the import library is usually named libfoo.dll.a, > which goes next to a static library named libfoo.a. This allows gcc > to pick the dynamic one, if available, from the normal -lfoo switches, > just as it does for libfoo.a vs libfoo.so on unix. On MSVC however, Unix > --- a/configure > +++ b/configure > @@ -2794,6 +2794,29 @@ case $target_os in > add_cppflags -U__STRICT_ANSI__ > ;; > msvc) > +if enabled shared; then > +# Link to the import library instead of the > +# normal static library. Merge those two lines, they are not too long. > +LD_LIB='%.lib' > +enabled static && > +die "Cannot build shared and static libraries at the same > time with MSVC." > +fi > +LIBTARGET=i386 > +if enabled x86_64; then > +LIBTARGET=x64 > +fi enabled x86_64 && In general this does LGTM, but wait for more voices; it sure made enormous progress since the initial version... Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
On 13/10/2012 1:29 PM, Måns Rullgård wrote: > I don't really like calling the OS msvc. That is the compiler. How > about "windows"? By that logic, shouldn't we also call mingw32 "windows"? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
Martin Storsjö writes: > The name mingw32 as target OS is both misleading, and very little > of the target OS specific settings actually match. > > Since the target OS default is set based on uname, the default > (which on MSYS is set to mingw) is overridden by --toolchain=msvc. > --- > configure | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) [...] > +msvc) > +objformat="win32" > +ranlib=: > +enable dos_paths > +;; I don't really like calling the OS msvc. That is the compiler. How about "windows"? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Refactor CPPFLAGS settings for glibc
Diego Biurrun writes: > --- > configure |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/configure b/configure > index 534c80d..dda752d 100755 > --- a/configure > +++ b/configure > @@ -2819,7 +2819,6 @@ case $target_os in > add_cppflags -U__STRICT_ANSI__ > ;; > linux) > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > enable dv1394 > ;; > irix*) > @@ -2850,10 +2849,9 @@ case $target_os in > enable dos_paths > ;; > gnu/kfreebsd) > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > -D_BSD_SOURCE > +add_cppflags -D_BSD_SOURCE > ;; > gnu) > -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > ;; > qnx) > add_cppflags -D_QNX_SOURCE > @@ -2890,6 +2888,7 @@ if check_cpp_condition features.h "defined __UCLIBC__"; > then > libc_type=uclibc > elif check_cpp_condition features.h "defined __GLIBC__"; then > libc_type=glibc > +add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 > elif check_header _mingw.h; then > libc_type=mingw > check_cpp_condition _mingw.h \ > -- This might need adjusting for linux/uclibc to work. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] Add support for building shared libraries with MSVC
From: "Ronald S. Bultje" This requires the makedef perl script by Derek, which probably will go into the c99-to-c89 repo. That scripts produces a .def file, listing the symbols to be exported, based on the gcc version scripts and the built object files. To properly load non-function symbols from DLL files, the data symbol declarations need to have the attribute __declspec(dllimport) when building the calling code. (On mingw, the linker can fix this up automatically, which is why it has not been an issue so far.) The __declspec(dllimport) attribute is added via a macro. Since it has to be present when building code that refer to these symbols, but not be present while building the library that exports the symbols themselves, the makefile is modified to add a define like COMPILING_ while building each library. This is used in the definition of the AV_SYMBOL macro - on non-MSVC compilers, it is empty. On MSVC, it is __declspec(dllimport) for declarations in other libraries than the object file currently compiled. This also implies that code that is built to link to a certain library as a DLL can't link to the same library as a static library. Therefore, we only allow building either static or shared but not both at the same time. (That is, static libraries as such can be, and actually are, built - this is used for linking the test tools to internal symbols in the libraries - but e.g. libavformat object files built to link to libavcodec as a DLL cannot link statically to libavcodec.) Also, linking to DLLs is slightly different from linking to shared libraries on other platforms. DLLs use a thing called import libraries, which is basically a stub library allowing the linker know which symbols exist in the DLL and what name the DLL will have at runtime. In mingw/gcc, the import library is usually named libfoo.dll.a, which goes next to a static library named libfoo.a. This allows gcc to pick the dynamic one, if available, from the normal -lfoo switches, just as it does for libfoo.a vs libfoo.so on unix. On MSVC however, you need to literally specify the name of the import library instead of the static library. --- configure | 23 +++ libavcodec/ac3tab.h|3 ++- libavcodec/dca.h |3 ++- libavcodec/mjpeg.h | 15 --- libavcodec/mpeg12data.h|3 ++- libavcodec/mpeg4audio.h|3 ++- libavcodec/mpegaudiodata.h |6 -- libavcodec/symbols.h | 32 library.mak|1 + 9 files changed, 76 insertions(+), 13 deletions(-) create mode 100644 libavcodec/symbols.h diff --git a/configure b/configure index 667089b..362f8d1 100755 --- a/configure +++ b/configure @@ -2794,6 +2794,29 @@ case $target_os in add_cppflags -U__STRICT_ANSI__ ;; msvc) +if enabled shared; then +# Link to the import library instead of the +# normal static library. +LD_LIB='%.lib' +enabled static && +die "Cannot build shared and static libraries at the same time with MSVC." +fi +LIBTARGET=i386 +if enabled x86_64; then +LIBTARGET=x64 +fi +shlibdir_default="$bindir_default" +SLIBPREF="" +SLIBSUF=".dll" +SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)' +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET) -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)' +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' +SLIB_INSTALL_LINKS= +SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)' objformat="win32" ranlib=: enable dos_paths diff --git a/libavcodec/ac3tab.h b/libavcodec/ac3tab.h index 8ed5052..2e20b4f 100644 --- a/libavcodec/ac3tab.h +++ b/libavcodec/ac3tab.h @@ -24,6 +24,7 @@ #include "libavutil/common.h" #include "ac3.h" +#include "symbols.h" #if CONFIG_HARDCODED_TABLES # define HCONST const @@ -33,7 +34,7 @@ extern const uint16_t ff_ac3_frame_size_tab[38][3]; extern const uint8_t ff_ac3_channels_tab[8]; -extern const uint16_t avpriv_ac3_channel_layout_tab[8]; +extern AVCODEC_SYMBOL const uint16_t avpriv_ac3_channel_layout_tab[8]; extern const uint8_t ff_ac3_enc_channel_map[8][2][6]; extern const uint8_t ff_ac3_dec_channel_map[8][2][6]; extern const uint16_t ff_ac3_sample_rate_tab[3]; diff --git a/libavcodec/dca.h b/libavcodec/dca.h index 1515270..13eb790 100644 --- a/libavcodec/dca.h +++ b/libavcodec/dca.h @@ -26,6 +26,7 @@ #define AVCODEC_DCA_H #include +#include "symbol
[libav-devel] [PATCH 1/2] configure: Split out msvc as a separate target OS
The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.
Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
---
configure | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 0992ff7..667089b 100755
--- a/configure
+++ b/configure
@@ -2033,8 +2033,6 @@ if enabled cross_compile; then
die "Must specify target arch and OS when cross-compiling"
fi
-set_default arch target_os
-
ar_default="${cross_prefix}${ar_default}"
cc_default="${cross_prefix}${cc_default}"
nm_default="${cross_prefix}${nm_default}"
@@ -2049,13 +2047,14 @@ case "$toolchain" in
ld_default="c99wrap link"
nm_default="dumpbin -symbols"
ar_default="lib"
+target_os_default="msvc"
;;
?*)
die "Unknown toolchain $toolchain"
;;
esac
-set_default cc pkg_config sysinclude
+set_default arch cc pkg_config sysinclude target_os
enabled cross_compile || host_cc_default=$cc
set_default host_cc
@@ -2066,7 +2065,7 @@ fi
exesuf() {
case $1 in
-mingw32*|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo .exe ;;
+mingw32*|msvc|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo .exe ;;
esac
}
@@ -2794,6 +2793,11 @@ case $target_os in
enable dos_paths
add_cppflags -U__STRICT_ANSI__
;;
+msvc)
+objformat="win32"
+ranlib=:
+enable dos_paths
+;;
cygwin*)
target_os=cygwin
shlibdir_default="$bindir_default"
--
1.7.9.5
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] swscale: try to use mmap only if available
On Sat, 13 Oct 2012, Mans Rullgard wrote:
Some systems, e.g. Minix, have sys/mman.h defining MAP_ANONYMOUS without
providing (working) mmap and friends. The mmx filter generation code
checks only for MAP_ANONYMOUS, not for availability of mmap itself which
leads to build errors on aforementioned systems.
This changes the conditional compilation to use mmap only if all the
required functions are available.
Signed-off-by: Mans Rullgard
---
libswscale/utils.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 4001606..a40dfe7 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1018,6 +1018,8 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
}
}
+#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
+
/* precalculate horizontal scaler filter coefficients */
{
#if HAVE_MMXEXT_INLINE
@@ -1028,7 +1030,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
c->chrMmx2FilterCodeSize = initMMX2HScaler(c->chrDstW, c->chrXInc,
NULL, NULL, NULL, 4);
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
c->lumMmx2FilterCode = mmap(NULL, c->lumMmx2FilterCodeSize,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
c->chrMmx2FilterCode = mmap(NULL, c->chrMmx2FilterCodeSize,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
#elif HAVE_VIRTUALALLOC
@@ -1051,7 +1053,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
initMMX2HScaler(c->chrDstW, c->chrXInc, c->chrMmx2FilterCode,
c->hChrFilter, c->hChrFilterPos, 4);
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
mprotect(c->lumMmx2FilterCode, c->lumMmx2FilterCodeSize, PROT_EXEC
| PROT_READ);
mprotect(c->chrMmx2FilterCode, c->chrMmx2FilterCodeSize, PROT_EXEC
| PROT_READ);
#endif
@@ -1630,7 +1632,7 @@ void sws_freeContext(SwsContext *c)
av_freep(&c->hChrFilterPos);
#if HAVE_MMX_INLINE
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
if (c->lumMmx2FilterCode)
munmap(c->lumMmx2FilterCode, c->lumMmx2FilterCodeSize);
if (c->chrMmx2FilterCode)
--
1.7.12.3
Ok
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: check for mprotect
On Sat, 13 Oct 2012, Mans Rullgard wrote:
Signed-off-by: Mans Rullgard
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 7be62fe..700e99d 100755
--- a/configure
+++ b/configure
@@ -1198,6 +1198,7 @@ HAVE_LIST="
mkstemp
mm_empty
mmap
+mprotect
msvcrt
nanosleep
poll_h
@@ -3212,6 +3213,7 @@ check_func localtime_r
check_func ${malloc_prefix}memalign&& enable memalign
check_func mkstemp
check_func mmap
+check_func mprotect
check_func ${malloc_prefix}posix_memalign && enable posix_memalign
check_func_headers malloc.h _aligned_malloc && enable aligned_malloc
check_func setrlimit
--
1.7.12.3
Ok
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] configure: Refactor CPPFLAGS settings for glibc
--- configure |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/configure b/configure index 534c80d..dda752d 100755 --- a/configure +++ b/configure @@ -2819,7 +2819,6 @@ case $target_os in add_cppflags -U__STRICT_ANSI__ ;; linux) -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 enable dv1394 ;; irix*) @@ -2850,10 +2849,9 @@ case $target_os in enable dos_paths ;; gnu/kfreebsd) -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE +add_cppflags -D_BSD_SOURCE ;; gnu) -add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 ;; qnx) add_cppflags -D_QNX_SOURCE @@ -2890,6 +2888,7 @@ if check_cpp_condition features.h "defined __UCLIBC__"; then libc_type=uclibc elif check_cpp_condition features.h "defined __GLIBC__"; then libc_type=glibc +add_cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 elif check_header _mingw.h; then libc_type=mingw check_cpp_condition _mingw.h \ -- 1.7.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] swscale: try to use mmap only if available
Some systems, e.g. Minix, have sys/mman.h defining MAP_ANONYMOUS without
providing (working) mmap and friends. The mmx filter generation code
checks only for MAP_ANONYMOUS, not for availability of mmap itself which
leads to build errors on aforementioned systems.
This changes the conditional compilation to use mmap only if all the
required functions are available.
Signed-off-by: Mans Rullgard
---
libswscale/utils.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 4001606..a40dfe7 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1018,6 +1018,8 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
}
}
+#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
+
/* precalculate horizontal scaler filter coefficients */
{
#if HAVE_MMXEXT_INLINE
@@ -1028,7 +1030,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
c->chrMmx2FilterCodeSize = initMMX2HScaler(c->chrDstW, c->chrXInc,
NULL, NULL, NULL, 4);
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
c->lumMmx2FilterCode = mmap(NULL, c->lumMmx2FilterCodeSize,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
c->chrMmx2FilterCode = mmap(NULL, c->chrMmx2FilterCodeSize,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
#elif HAVE_VIRTUALALLOC
@@ -1051,7 +1053,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
initMMX2HScaler(c->chrDstW, c->chrXInc, c->chrMmx2FilterCode,
c->hChrFilter, c->hChrFilterPos, 4);
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
mprotect(c->lumMmx2FilterCode, c->lumMmx2FilterCodeSize, PROT_EXEC
| PROT_READ);
mprotect(c->chrMmx2FilterCode, c->chrMmx2FilterCodeSize, PROT_EXEC
| PROT_READ);
#endif
@@ -1630,7 +1632,7 @@ void sws_freeContext(SwsContext *c)
av_freep(&c->hChrFilterPos);
#if HAVE_MMX_INLINE
-#ifdef MAP_ANONYMOUS
+#if USE_MMAP
if (c->lumMmx2FilterCode)
munmap(c->lumMmx2FilterCode, c->lumMmx2FilterCodeSize);
if (c->chrMmx2FilterCode)
--
1.7.12.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] configure: check for mprotect
Signed-off-by: Mans Rullgard
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 7be62fe..700e99d 100755
--- a/configure
+++ b/configure
@@ -1198,6 +1198,7 @@ HAVE_LIST="
mkstemp
mm_empty
mmap
+mprotect
msvcrt
nanosleep
poll_h
@@ -3212,6 +3213,7 @@ check_func localtime_r
check_func ${malloc_prefix}memalign&& enable memalign
check_func mkstemp
check_func mmap
+check_func mprotect
check_func ${malloc_prefix}posix_memalign && enable posix_memalign
check_func_headers malloc.h _aligned_malloc && enable aligned_malloc
check_func setrlimit
--
1.7.12.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] avutil: Give symbols used across libraries avpriv_ instead of ff_ prefixes
Diego Biurrun writes: > --- > libavcodec/bmpenc.c |2 +- > libavcodec/rawdec.c |2 +- > libavcodec/utils.c |2 +- > libavutil/imgutils.c |4 ++-- > libavutil/imgutils.h |2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) There seems to be only one such symbol so you could mention it in the commit message. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] avutil: Do not make ff_ symbols globally visible.
On Thu, 4 Oct 2012, Diego Biurrun wrote:
---
libavutil/libavutil.v |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v
index eb16ae1..e9f04cb 100644
--- a/libavutil/libavutil.v
+++ b/libavutil/libavutil.v
@@ -1,4 +1,4 @@
LIBAVUTIL_$MAJOR {
-global: av*; ff_*;
+global: av*;
local: *;
};
--
1.7.1
Yes please, LGTM \o/
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] avutil: Give symbols used across libraries avpriv_ instead of ff_ prefixes
On Thu, 4 Oct 2012, Diego Biurrun wrote: --- libavcodec/bmpenc.c |2 +- libavcodec/rawdec.c |2 +- libavcodec/utils.c |2 +- libavutil/imgutils.c |4 ++-- libavutil/imgutils.h |2 +- 5 files changed, 6 insertions(+), 6 deletions(-) Ok with me, this at least makes the current stuff properly namespaced. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
On Sat, 13 Oct 2012, Diego Biurrun wrote:
On Sat, Oct 13, 2012 at 01:46:38PM +0300, Martin Storsjö wrote:
--- a/configure
+++ b/configure
@@ -2778,14 +2778,33 @@ case $target_os in
shlibdir_default="$bindir_default"
SLIBPREF=""
SLIBSUF=".dll"
+if enabled_all msvc shared; then
+# Link to the import library instead of the
+# normal static library.
+LD_LIB='%.lib'
+fi
SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
-SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def)
-l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'
+if enabled msvc; then
+# The libtarget names for lib.exe differ from the ones for dlltool
+if enabled x86_64; then
+LIBTARGET=x64
+fi
+SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
$$(@:$(SLIBSUF)=.def)'
+SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
-def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
+else
+SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
$$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
$(SLIBNAME_WITH_MAJOR)'
+fi
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS=
SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
-SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
-SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
-Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
-Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
+if enabled msvc; then
+SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
+SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
-implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
+else
+SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
+SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
-Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
-Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
+fi
objformat="win32"
dlltool="${cross_prefix}dlltool"
ranlib=:
I suggest to separate the MinGW and MSVC sections completely. That would
be both more readable and more maintainable. I fear that otherwise
changes for one system will break the other.
@@ -3521,6 +3540,8 @@ elif enabled pathscale; then
add_cflags -fstrict-overflow -OPT:wrap_around_unsafe_opt=OFF
elif enabled msvc; then
enabled x86_32 && disable aligned_stack
+enabled_all shared static &&
+die "Cannot build shared and static libraries at the same time with
MSVC"
End in a period.
--- a/libavcodec/ac3tab.h
+++ b/libavcodec/ac3tab.h
@@ -24,6 +24,7 @@
#include "libavutil/common.h"
#include "ac3.h"
+#include "symbols.h"
@@ -33,7 +34,7 @@
extern const uint8_t ff_ac3_channels_tab[8];
-extern const uint16_t avpriv_ac3_channel_layout_tab[8];
+extern AVCODEC_SYMBOL const uint16_t avpriv_ac3_channel_layout_tab[8];
extern const uint8_t ff_ac3_enc_channel_map[8][2][6];
What's the verdict wrt cross-library (data) symbols. What shall we do
about them?
About this, the only ones left now are private ones, so the current
solution doesn't have to be permanent, since it's not visible in the
public installed headers (in previous iterations, a flag for whether the
build is shared had to be added to the installed avconfig.h).
// Martin___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] nut: export codec_tag provided by rawvideo
Raw audio does not provide valid audio tags while rawvideo does.
---
libavformat/nutenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 6338924..9985cd9 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -385,7 +385,7 @@ static int write_streamheader(AVFormatContext *avctx,
AVIOContext *bc, AVStream
}
ff_put_v(bc, 4);
-if (!codec_tag)
+if (!codec_tag || codec->codec_id == AV_CODEC_ID_RAWVIDEO)
codec_tag = codec->codec_tag;
if (codec_tag) {
--
1.7.12
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] announce plain 9 beta 1 release
Am 13.10.2012 10:25 schrieb "Luca Barbato" : > > On 10/13/2012 04:18 PM, Reinhard Tartler wrote: > > The ffmpeg transcoding tool, > > +kept for compatibility in 0.8, has also been dropped. > > I'd mention avconv there. the rest looks fine. In that case we should also update that part in the release notes in master as I've copied most of the text from there. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
On Sat, Oct 13, 2012 at 10:04:50AM -0500, Daniel Kang wrote: > > --- a/libavcodec/x86/Makefile > +++ b/libavcodec/x86/Makefile > @@ -51,7 +51,9 @@ YASM-OBJS-$(CONFIG_H264DSP)+= > x86/h264_deblock.o\ >x86/h264_weight_10bit.o > YASM-OBJS-$(CONFIG_H264PRED) += x86/h264_intrapred.o \ >x86/h264_intrapred_10bit.o > -YASM-OBJS-$(CONFIG_H264QPEL) += x86/h264_qpel_10bit.o > +YASM-OBJS-$(CONFIG_H264QPEL) += x86/h264_qpel.o \ > + x86/h264_qpel_8bit.o \ > + x86/h264_qpel_10bit.o h264_qpel.c is directly #included from dsputil_mmx.c, but you also compile it. This is the reason for all those unused function warnings. It does not fail to link by sheer good luck; bad luck rather, as it makes the problem less obvious. FATE still fails with that fixed. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
On Sat, Oct 13, 2012 at 10:04:50AM -0500, Daniel Kang wrote: > --- > libavcodec/x86/Makefile |4 +- > libavcodec/x86/dsputil.asm| 222 +++ > libavcodec/x86/dsputil_avg_template.c | 136 +--- > libavcodec/x86/dsputil_mmx.c | 105 +-- > libavcodec/x86/h264_qpel.c| 1138 > + > libavcodec/x86/h264_qpel_8bit.asm | 833 > 6 files changed, 1239 insertions(+), 1199 deletions(-) > create mode 100644 libavcodec/x86/h264_qpel_8bit.asm This patch breaks FATE, please reread http://www.libav.org/developer.html#Submitting-patches Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
On Sat, Oct 13, 2012 at 10:04:50AM -0500, Daniel Kang wrote:
>
> --- a/libavcodec/x86/dsputil_avg_template.c
> +++ b/libavcodec/x86/dsputil_avg_template.c
> @@ -227,59 +176,6 @@ static void DEF(put_no_rnd_pixels8_l2)(uint8_t *dst,
> uint8_t *src1, uint8_t *src
>
> @@ -334,6 +230,7 @@ static void DEF(avg_pixels8_l2)(uint8_t *dst, uint8_t
> *src1, uint8_t *src2, int
> :"r"(src1Stride), "r"(dstStride)
> :"memory");*/
> }
> +#endif
>
> @@ -375,6 +272,7 @@ static void DEF(put_pixels16_x2)(uint8_t *block, const
> uint8_t *pixels, int line
> :"%"REG_a, "memory");
> }
>
> +#ifndef SKIP_FOR_3DNOW
> static void DEF(put_pixels16_l2)(uint8_t *dst, uint8_t *src1, uint8_t *src2,
> int dstStride, int src1Stride, int h)
> {
> __asm__ volatile(
> @@ -549,6 +447,7 @@ static void DEF(put_no_rnd_pixels16_l2)(uint8_t *dst,
> uint8_t *src1, uint8_t *sr
> :"r"(src1Stride), "r"(dstStride)
> :"memory");*/
> }
> +#endif
>
> @@ -972,6 +844,7 @@ static void DEF(OPNAME ## 2tap_qpel8_l3)(uint8_t *dst,
> uint8_t *src, int stride,
>
> +#ifndef SKIP_FOR_3DNOW
> #define STORE_OP(a,b) PAVGB" "#a","#b" \n\t"
> QPEL_2TAP_L3(avg_)
> #undef STORE_OP
> @@ -979,3 +852,4 @@ QPEL_2TAP_L3(avg_)
> QPEL_2TAP_L3(put_)
> #undef STORE_OP
> #undef QPEL_2TAP_L3
> +#endif
This patchset appears to be incorrectly split: The SKIP_FOR_3DNOW checks
should be part of the other patch. I already mentioned this during the
last review round.
> --- a/libavcodec/x86/dsputil_mmx.c
> +++ b/libavcodec/x86/dsputil_mmx.c
> @@ -2631,10 +2543,10 @@ static void dsputil_init_sse2(DSPContext *c,
> AVCodecContext *avctx,
> static void dsputil_init_ssse3(DSPContext *c, AVCodecContext *avctx,
> int mm_flags)
> {
> -const int high_bit_depth = avctx->bits_per_raw_sample > 8;
> const int bit_depth = avctx->bits_per_raw_sample;
> +const int high_bit_depth = bit_depth > 8;
unrelated stray change
> --- a/libavcodec/x86/h264_qpel.c
> +++ b/libavcodec/x86/h264_qpel.c
> @@ -18,1020 +18,225 @@
> * License along with Libav; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
> -
> +#include "libavutil/cpu.h"
> +#include "libavutil/x86/asm.h"
> +#include "libavcodec/dsputil.h"
> +#include "libavcodec/mpegvideo.h"
> #include "dsputil_mmx.h"
That empty line was there on purpose.
> +#if HAVE_YASM
Is there still inline assembly left in this file? Given that you compile
it only if YASM is available, there should not be. In that case, the
#ifdef is unnecessary.
> +static void ff_put_pixels16_mmx2(uint8_t *block, const uint8_t *pixels, int
> line_size, int h) {
> +ff_put_pixels8_mmx2(block , pixels , line_size, h);
> +ff_put_pixels8_mmx2(block+8, pixels+8, line_size, h);
> +}
> +static void ff_avg_pixels16_mmx2(uint8_t *block, const uint8_t *pixels, int
> line_size, int h) {
> +ff_avg_pixels8_mmx2(block , pixels , line_size, h);
> +ff_avg_pixels8_mmx2(block+8, pixels+8, line_size, h);
> +}
I know that the file is a big mess, but new code should be K&R style.
Move the { to the next line and add spaces around operators.
> @@ -1171,25 +376,18 @@ QPEL_H264_V_XMM(put_, PUT_OP, sse2)
> QPEL_H264_V_XMM(avg_, AVG_MMX2_OP, sse2)
> QPEL_H264_HV_XMM(put_, PUT_OP, sse2)
> QPEL_H264_HV_XMM(avg_, AVG_MMX2_OP, sse2)
> -#if HAVE_SSSE3_INLINE
> QPEL_H264_H_XMM(put_, PUT_OP, ssse3)
> QPEL_H264_H_XMM(avg_, AVG_MMX2_OP, ssse3)
> -QPEL_H264_HV2_XMM(put_, PUT_OP, ssse3)
> -QPEL_H264_HV2_XMM(avg_, AVG_MMX2_OP, ssse3)
Are you removing these two lines on purpose?
> --- /dev/null
> +++ b/libavcodec/x86/h264_qpel_8bit.asm
> @@ -0,0 +1,833 @@
> +;*
> +;* MMX/SSE2/SSSE3-optimized H.264 qpel code
nit: QPEL
> +%macro op_avgh 3
> +movh %3, %2
> +pavgb %1, %3
> +movh %2, %1
> +%endmacro
> +
> +%macro op_avg 3
> +pavgb %1, %2
> +mova %2, %1
> +%endmacro
> +
> +%macro op_puth 3
> +movh %2, %1
> +%endmacro
> +
> +%macro op_put 3
> +mova %2, %1
> +%endmacro
All of these macros only take 2 parameters.
> +.loop:
> +movh m1, [r1-1]
> +movh m2, [r1+0]
> +movh m3, [r1+1]
> +movh m0, [r1+2]
Spaces around operators would help readability IMO; more below...
> +punpcklbw m1, m7
> +punpcklbw m2, m7
> +punpcklbw m3, m7
> +punpcklbw m0, m7
> +paddw m1, m0
> +paddw m2, m3
> +movh m0, [r1-2]
> +movh m3, [r1+3]
> +punpcklbw m0, m7
> +punpcklbw m3, m7
> +paddw m0, m3
> +psllw m2, 2
> +psubw m2, m1
> +pmullwm2, m4
> +paddw m0, m5
> +paddw m0, m2
> +psraw m0, 5
> +packuswb m0, m0
> +op_%1hm0, [r0], m6
> +add r0, r2
> +add r1, r3
> +dec r4d
> +jg .loop
> +REP_RET
I wonder why you
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
Daniel Kang writes: > On Sat, Oct 13, 2012 at 11:31 AM, Måns Rullgård wrote: >> Daniel Kang writes: >> >>> On Sat, Oct 13, 2012 at 11:04 AM, Daniel Kang >>> wrote: --- libavcodec/x86/Makefile |4 +- libavcodec/x86/dsputil.asm| 222 +++ libavcodec/x86/dsputil_avg_template.c | 136 +--- libavcodec/x86/dsputil_mmx.c | 105 +-- libavcodec/x86/h264_qpel.c| 1138 + libavcodec/x86/h264_qpel_8bit.asm | 833 6 files changed, 1239 insertions(+), 1199 deletions(-) create mode 100644 libavcodec/x86/h264_qpel_8bit.asm >>> >>> This introduces many unused function warnings, but the functions are >>> being called... >> >> Obviously they are not. GCC does not simply make things like that up. > > If I add an exit in the appropriate places, it exits. You're really not making it easy for people to help you. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libavcodec/pcm-mpeg.c: Correct bitrate calculation and debug units
On 10/13/2012 04:27 PM, Luca Barbato wrote:
> On 10/13/2012 03:45 PM, Christian Schmidt wrote:
>> ---
>> libavcodec/pcm-mpeg.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/pcm-mpeg.c b/libavcodec/pcm-mpeg.c
>> index 4a38648..602abab 100644
>> --- a/libavcodec/pcm-mpeg.c
>> +++ b/libavcodec/pcm-mpeg.c
>> @@ -109,12 +109,12 @@ static int pcm_bluray_parse_header(AVCodecContext
>> *avctx,
>> return -1;
>> }
>>
>> -avctx->bit_rate = avctx->channels * avctx->sample_rate *
>> +avctx->bit_rate = FFALIGN(avctx->channels,2) * avctx->sample_rate *
>>avctx->bits_per_coded_sample;
>
> Why channels must be a multiple of 2? Would be nice mentioning it in the
> commit message.
It's already in the current code:
/*
* get the channel number (and mapping). Not all values are used.
* It must be noted that the number of channels in the MPEG stream can
* differ from the actual meaningful number, e.g. mono audio still
has two
* channels, one being empty.
*/
avctx->channel_layout = channel_layouts[channel_layout];
avctx->channels=channels[channel_layout];
if (!avctx->channels) {
av_log(avctx, AV_LOG_ERROR, "reserved channel configuration (%d)\n",
channel_layout);
return -1;
}
avctx->bit_rate = FFALIGN(avctx->channels, 2) * avctx->sample_rate *
avctx->bits_per_coded_sample;
Later on, in the decoding function
/* There's always an even number of channels in the source */
num_source_channels = FFALIGN(avctx->channels, 2);
etc.
>> if (avctx->debug & FF_DEBUG_PICT_INFO)
>> av_dlog(avctx,
>> -"pcm_bluray_parse_header: %d channels, %d bits per sample,
>> %d kHz, %d kbit\n",
>> +"pcm_bluray_parse_header: %d channels, %d bits per sample,
>> %d Hz, %d bit/s\n",
>> avctx->channels, avctx->bits_per_coded_sample,
>> avctx->sample_rate, avctx->bit_rate);
>> return 0;
>
> This is obviously correct.
>
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
>
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
On Sat, Oct 13, 2012 at 11:31 AM, Måns Rullgård wrote: > Daniel Kang writes: > >> On Sat, Oct 13, 2012 at 11:04 AM, Daniel Kang >> wrote: >>> --- >>> libavcodec/x86/Makefile |4 +- >>> libavcodec/x86/dsputil.asm| 222 +++ >>> libavcodec/x86/dsputil_avg_template.c | 136 +--- >>> libavcodec/x86/dsputil_mmx.c | 105 +-- >>> libavcodec/x86/h264_qpel.c| 1138 >>> + >>> libavcodec/x86/h264_qpel_8bit.asm | 833 >>> 6 files changed, 1239 insertions(+), 1199 deletions(-) >>> create mode 100644 libavcodec/x86/h264_qpel_8bit.asm >> >> This introduces many unused function warnings, but the functions are >> being called... > > Obviously they are not. GCC does not simply make things like that up. If I add an exit in the appropriate places, it exits. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
Daniel Kang writes: > On Sat, Oct 13, 2012 at 11:04 AM, Daniel Kang wrote: >> --- >> libavcodec/x86/Makefile |4 +- >> libavcodec/x86/dsputil.asm| 222 +++ >> libavcodec/x86/dsputil_avg_template.c | 136 +--- >> libavcodec/x86/dsputil_mmx.c | 105 +-- >> libavcodec/x86/h264_qpel.c| 1138 >> + >> libavcodec/x86/h264_qpel_8bit.asm | 833 >> 6 files changed, 1239 insertions(+), 1199 deletions(-) >> create mode 100644 libavcodec/x86/h264_qpel_8bit.asm > > This introduces many unused function warnings, but the functions are > being called... Obviously they are not. GCC does not simply make things like that up. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/3] fate: Add timefilter test
On Fri, Oct 05, 2012 at 09:08:40PM +0200, Diego Biurrun wrote: > --- > tests/Makefile |2 ++ > tests/fate/libavdevice.mak |5 + > tests/ref/fate/timefilter |6 ++ > 3 files changed, 13 insertions(+), 0 deletions(-) > create mode 100644 tests/fate/libavdevice.mak > create mode 100644 tests/ref/fate/timefilter ping Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] H264: Remove 3dnow qpel code.
Daniel Kang writes: > Moreover, AMD has deprecated 3dnow. It's use deprecated on _new_ CPUs. If you're stuck with an old CPU, there's precious little you can do about it. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] H.264: Convert 8-bit qpel inlined assembly to yasm
On Sat, Oct 13, 2012 at 11:04 AM, Daniel Kang wrote: > --- > libavcodec/x86/Makefile |4 +- > libavcodec/x86/dsputil.asm| 222 +++ > libavcodec/x86/dsputil_avg_template.c | 136 +--- > libavcodec/x86/dsputil_mmx.c | 105 +-- > libavcodec/x86/h264_qpel.c| 1138 > + > libavcodec/x86/h264_qpel_8bit.asm | 833 > 6 files changed, 1239 insertions(+), 1199 deletions(-) > create mode 100644 libavcodec/x86/h264_qpel_8bit.asm This introduces many unused function warnings, but the functions are being called... ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] H264: Remove 3dnow qpel code.
The only CPUs that have 3dnow and don't have mmxext are 12 years old.
Moreover, AMD has deprecated 3dnow.
---
libavcodec/x86/dsputil_avg_template.c |8 +-
libavcodec/x86/dsputil_mmx.c | 142 +
libavcodec/x86/h264_qpel.c|4 -
3 files changed, 8 insertions(+), 146 deletions(-)
diff --git a/libavcodec/x86/dsputil_avg_template.c
b/libavcodec/x86/dsputil_avg_template.c
index 8b116b7..b514746 100644
--- a/libavcodec/x86/dsputil_avg_template.c
+++ b/libavcodec/x86/dsputil_avg_template.c
@@ -55,6 +55,7 @@ static void DEF(put_pixels8_x2)(uint8_t *block, const uint8_t
*pixels, int line_
:"%"REG_a, "memory");
}
+#ifndef SKIP_FOR_3DNOW
static void DEF(put_pixels4_l2)(uint8_t *dst, uint8_t *src1, uint8_t *src2,
int dstStride, int src1Stride, int h)
{
__asm__ volatile(
@@ -104,7 +105,7 @@ static void DEF(put_pixels4_l2)(uint8_t *dst, uint8_t
*src1, uint8_t *src2, int
:"S"((x86_reg)src1Stride), "D"((x86_reg)dstStride)
:"memory");
}
-
+#endif
static void DEF(put_pixels8_l2)(uint8_t *dst, uint8_t *src1, uint8_t *src2,
int dstStride, int src1Stride, int h)
{
@@ -226,6 +227,7 @@ static void DEF(put_no_rnd_pixels8_l2)(uint8_t *dst,
uint8_t *src1, uint8_t *src
:"memory");*/
}
+#ifndef SKIP_FOR_3DNOW
static void DEF(avg_pixels4_l2)(uint8_t *dst, uint8_t *src1, uint8_t *src2,
int dstStride, int src1Stride, int h)
{
__asm__ volatile(
@@ -276,7 +278,7 @@ static void DEF(avg_pixels4_l2)(uint8_t *dst, uint8_t
*src1, uint8_t *src2, int
:"S"((x86_reg)src1Stride), "D"((x86_reg)dstStride)
:"memory");
}
-
+#endif
static void DEF(avg_pixels8_l2)(uint8_t *dst, uint8_t *src1, uint8_t *src2,
int dstStride, int src1Stride, int h)
{
@@ -872,6 +874,7 @@ static void DEF(avg_pixels8_xy2)(uint8_t *block, const
uint8_t *pixels, int line
:"%"REG_a, "memory");
}
+#ifndef SKIP_FOR_3DNOW
static void DEF(avg_pixels4)(uint8_t *block, const uint8_t *pixels, int
line_size, int h)
{
do {
@@ -896,6 +899,7 @@ static void DEF(avg_pixels4)(uint8_t *block, const uint8_t
*pixels, int line_siz
h -= 4;
} while(h > 0);
}
+#endif
//FIXME the following could be optimized too ...
static void DEF(put_no_rnd_pixels16_x2)(uint8_t *block, const uint8_t *pixels,
int line_size, int h){
diff --git a/libavcodec/x86/dsputil_mmx.c b/libavcodec/x86/dsputil_mmx.c
index 86a08cb..a0231b7 100644
--- a/libavcodec/x86/dsputil_mmx.c
+++ b/libavcodec/x86/dsputil_mmx.c
@@ -197,12 +197,14 @@ DECLARE_ALIGNED(16, const double, ff_pd_2)[2] = { 2.0,
2.0 };
#define DEF(x) x ## _3dnow
#define PAVGB "pavgusb"
#define OP_AVG PAVGB
+#define SKIP_FOR_3DNOW
#include "dsputil_avg_template.c"
#undef DEF
#undef PAVGB
#undef OP_AVG
+#undef SKIP_FOR_3DNOW
/***/
/* MMX2 specific */
@@ -1051,73 +1053,6 @@ static void OPNAME ##
mpeg4_qpel16_h_lowpass_mmx2(uint8_t *dst, \
);\
} \
\
-static void OPNAME ## mpeg4_qpel16_h_lowpass_3dnow(uint8_t *dst, \
- uint8_t *src, \
- int dstStride, \
- int srcStride, \
- int h) \
-{ \
-int i;\
-int16_t temp[16]; \
-/* quick HACK, XXX FIXME MUST be optimized */ \
-for (i = 0; i < h; i++) { \
-temp[ 0] = (src[ 0] + src[ 1]) * 20 - (src[ 0] + src[ 2]) * 6 + \
- (src[ 1] + src[ 3]) * 3 - (src[ 2] + src[ 4]);\
-temp[ 1] = (src[ 1] + src[ 2]) * 20 - (src[ 0] + src[ 3]) * 6 + \
- (src[ 0] + src[ 4]) * 3 - (src[ 1] + src[ 5]);\
-temp[ 2] = (src[ 2] + src[ 3]) * 20 - (src[ 1] + src[ 4]) * 6 + \
- (src[ 0] + src[ 5]) * 3 - (src[ 0] + src[ 6]);\
-temp[ 3] = (src[ 3] + src[ 4]) * 20 - (src[ 2] + src[ 5]) * 6 + \
- (src[ 1] + src[ 6]) * 3 - (src[ 0] + src[ 7]);\
-temp[ 4] = (src[ 4] + src[ 5]) * 20 - (src[ 3] + src[ 6]) * 6 + \
- (src[ 2] + src[ 7]) * 3 - (src[ 1] + src[ 8]);\
-temp[ 5] = (src[ 5] + src[ 6]) * 20 - (src[ 4] + src[ 7]) * 6 + \
- (src[ 3] + src[ 8]) * 3 - (src[ 2] + src[ 9]);\
-temp[ 6] = (src[ 6] + src[ 7]) * 20 - (src[ 5] + src[ 8]) * 6 + \
-
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 01:46:38PM +0300, Martin Storsjö wrote:
>
> --- a/configure
> +++ b/configure
> @@ -2778,14 +2778,33 @@ case $target_os in
> shlibdir_default="$bindir_default"
> SLIBPREF=""
> SLIBSUF=".dll"
> +if enabled_all msvc shared; then
> +# Link to the import library instead of the
> +# normal static library.
> +LD_LIB='%.lib'
> +fi
>
> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
> SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
> -SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def)
> -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'
> +if enabled msvc; then
> +# The libtarget names for lib.exe differ from the ones for
> dlltool
> +if enabled x86_64; then
> +LIBTARGET=x64
> +fi
> +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
> $$(@:$(SLIBSUF)=.def)'
> +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
> -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
> +else
> +SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
> $(SLIBNAME_WITH_MAJOR)'
> +fi
> SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
> SLIB_INSTALL_LINKS=
> SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
> -SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> -SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
> +if enabled msvc; then
> +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
> -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
> +else
> +SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> +SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
> +fi
> objformat="win32"
> dlltool="${cross_prefix}dlltool"
> ranlib=:
I suggest to separate the MinGW and MSVC sections completely. That would
be both more readable and more maintainable. I fear that otherwise
changes for one system will break the other.
> @@ -3521,6 +3540,8 @@ elif enabled pathscale; then
> add_cflags -fstrict-overflow -OPT:wrap_around_unsafe_opt=OFF
> elif enabled msvc; then
> enabled x86_32 && disable aligned_stack
> +enabled_all shared static &&
> +die "Cannot build shared and static libraries at the same time with
> MSVC"
End in a period.
> --- a/libavcodec/ac3tab.h
> +++ b/libavcodec/ac3tab.h
> @@ -24,6 +24,7 @@
>
> #include "libavutil/common.h"
> #include "ac3.h"
> +#include "symbols.h"
>
> @@ -33,7 +34,7 @@
>
> extern const uint8_t ff_ac3_channels_tab[8];
> -extern const uint16_t avpriv_ac3_channel_layout_tab[8];
> +extern AVCODEC_SYMBOL const uint16_t avpriv_ac3_channel_layout_tab[8];
> extern const uint8_t ff_ac3_enc_channel_map[8][2][6];
What's the verdict wrt cross-library (data) symbols. What shall we do
about them?
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] avfilter: fix graphparser memleaks on error paths
On 10/09/2012 10:15 PM, Janne Grunau wrote: > Fixes CID700635, CID700636 and CID732274. > --- > libavfilter/graphparser.c | 24 +++- > 1 file changed, 15 insertions(+), 9 deletions(-) Ok. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libavcodec/pcm-mpeg.c: Correct bitrate calculation and debug units
On 10/13/2012 03:45 PM, Christian Schmidt wrote: > --- > libavcodec/pcm-mpeg.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/pcm-mpeg.c b/libavcodec/pcm-mpeg.c > index 4a38648..602abab 100644 > --- a/libavcodec/pcm-mpeg.c > +++ b/libavcodec/pcm-mpeg.c > @@ -109,12 +109,12 @@ static int pcm_bluray_parse_header(AVCodecContext > *avctx, > return -1; > } > > -avctx->bit_rate = avctx->channels * avctx->sample_rate * > +avctx->bit_rate = FFALIGN(avctx->channels,2) * avctx->sample_rate * >avctx->bits_per_coded_sample; Why channels must be a multiple of 2? Would be nice mentioning it in the commit message. > if (avctx->debug & FF_DEBUG_PICT_INFO) > av_dlog(avctx, > -"pcm_bluray_parse_header: %d channels, %d bits per sample, > %d kHz, %d kbit\n", > +"pcm_bluray_parse_header: %d channels, %d bits per sample, > %d Hz, %d bit/s\n", > avctx->channels, avctx->bits_per_coded_sample, > avctx->sample_rate, avctx->bit_rate); > return 0; This is obviously correct. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] announce plain 9 beta 1 release
On 10/13/2012 04:18 PM, Reinhard Tartler wrote: > The ffmpeg transcoding tool, > +kept for compatibility in 0.8, has also been dropped. I'd mention avconv there. the rest looks fine. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] announce plain 9 beta 1 release
--- src/download | 22 src/news | 82 ++ 2 files changed, 104 insertions(+) This is my first shot at the news site entry. Please revise and push at your will. Reinhard diff --git a/src/download b/src/download index 0e88eaa..9039cbd 100644 --- a/src/download +++ b/src/download @@ -203,6 +203,28 @@ selected changes from the development branch, which therefore receives much more and much faster bug fixes such as additional features and security patches. +Libav 9 "plain 9" + +While 9 is not released yet, we already provide you with a +preview beta release. Please accept this opportunity to test and provide +us with feedback about your impressions with this release and use our +new Bugzilla for filing bugs: +https://bugzilla.libav.org";>https://bugzilla.libav.org/ + + + +Download bzip2 tarball +MD5 +SHA1 +PGP signature +Download gzip tarball +MD5 +SHA1 +PGP signature +Changelog +Release Notes + + Libav 0.8.3 "Forbidden Fruit" 0.8.3 was released on 2012-06-09. It is the latest point release from diff --git a/src/news b/src/news index 673672a..e532057 100644 --- a/src/news +++ b/src/news @@ -1,5 +1,87 @@ News +October 11, 2012 + +With the next upcoming release, we change our versioning scheme to +follow our workflow better. This means that major releases will update +the major component of the version number, stable releases the minor +component. With this in mind, we are happy to provide a first preview of +our next release version 9. + + + +A new library arrived in Libav during this development cycle -- its name is +libavresample and it handles audio conversion and mixing. All +users are encouraged to use it instead of the old, now deprecated, audio +conversion API in libavcodec. + + + +The libpostproc library now resides in a separate tree. It was fully +independent of the other Libav libraries, not used by any of the tools +and saw very little development. For these reasons we decided that it +has no place in Libav. A standalone Git tree is available +at http://git.videolan.org/?p=libpostproc.git";>videolan for +people wishing to use libpostproc. + + + +The major versions of the libavcodec, libavformat +and libavfilter libraries have been bumped, so they are not API +or ABI compatible with the 0.8 release. The ffmpeg transcoding tool, +kept for compatibility in 0.8, has also been dropped. + + + +This release brings a number of significant changes in +the libavfilter library. Firstly, all the API dealing with +filter internals is no longer public. The result is that creating +user-side filters will not be supported until libavfilter is more +mature. Secondly, full audio filtering support is now available along +with a set of basic audio filters. We hope that their number will soon +grow significantly. The avconv transcoding tool has of course been +extended to handle audio filtering as well. There were a number of +other API changes, most importantly the addition of the buffer sink +public API. + + + +In the libavcodec library, one of the most notable changes is +added support for planar audio (i.e. not interleaved). Many decoders and +encoders, that previously did inefficient (de)interleaving internally, +now only work with planar audio formats. Libavresample can be used for +optimized conversion between interleaved and planar formats. + + + +As usual, this release also contains support for some new formats, many +smaller new features and countless bug fixes. We can highlight Opus +decoding / encoding through libopus, encoders for Apple ProRes and Ut +Video, WMA Lossless and RealAudio Lossless decoders, fragmented MOV/MP4 +and ISMV (Smooth Streaming) muxers, a large number of RTMP improvements +and support for cover art in ID3v2, WMA, MP4 and FLAC. + + + +See +the http://git.libav.org/?p=libav.git;a=blob_plain;f=Changelog;h=b4b5294755d7f67f0bf3b091112f688ae8df886d;hb=e578f8f4680f7ad290de64270dc152fb1adb6e6a";>Changelog +file for a list of significant changes. + + + +Please note that our policy on bug reports has not changed. We still +only accept bug reports against HEAD of the Libav trunk +repository. If you are experiencing issues with any formally released +version of Libav, please try a current version of the development code +to check if the issue still exists. If it does, make your report against +the development code following the usual bug reporting guidelines. + + + +You can download the new release, as usual, +from our download page + + October 05, 2012 The libavresample library is now declared stable. There will be no more -- 1.7.9.5 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] libavcodec/pcm-mpeg.c: Correct bitrate calculation and debug units
--- libavcodec/pcm-mpeg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/pcm-mpeg.c b/libavcodec/pcm-mpeg.c index 4a38648..602abab 100644 --- a/libavcodec/pcm-mpeg.c +++ b/libavcodec/pcm-mpeg.c @@ -109,12 +109,12 @@ static int pcm_bluray_parse_header(AVCodecContext *avctx, return -1; } -avctx->bit_rate = avctx->channels * avctx->sample_rate * +avctx->bit_rate = FFALIGN(avctx->channels,2) * avctx->sample_rate * avctx->bits_per_coded_sample; if (avctx->debug & FF_DEBUG_PICT_INFO) av_dlog(avctx, -"pcm_bluray_parse_header: %d channels, %d bits per sample, %d kHz, %d kbit\n", +"pcm_bluray_parse_header: %d channels, %d bits per sample, %d Hz, %d bit/s\n", avctx->channels, avctx->bits_per_coded_sample, avctx->sample_rate, avctx->bit_rate); return 0; -- 1.7.12 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] avfilter: fix graphparser memleaks on error paths
On 2012-10-09 22:15:44 +0200, Janne Grunau wrote:
> Fixes CID700635, CID700636 and CID732274.
> ---
> libavfilter/graphparser.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
> index 3921189..04339c8 100644
> --- a/libavfilter/graphparser.c
> +++ b/libavfilter/graphparser.c
> @@ -238,10 +238,11 @@ static int link_filter_inouts(AVFilterContext *filt_ctx,
> return AVERROR(ENOMEM);
>
> if (p->filter_ctx) {
> -if ((ret = link_filter(p->filter_ctx, p->pad_idx, filt_ctx, pad,
> log_ctx)) < 0)
> -return ret;
> +ret = link_filter(p->filter_ctx, p->pad_idx, filt_ctx, pad,
> log_ctx);
> av_free(p->name);
> av_free(p);
> +if (ret < 0)
> +return ret;
> } else {
> p->filter_ctx = filt_ctx;
> p->pad_idx = pad;
> @@ -289,8 +290,10 @@ static int parse_inputs(const char **buf, AVFilterInOut
> **curr_inputs,
> av_free(name);
> } else {
> /* Not in the list, so add it as an input */
> -if (!(match = av_mallocz(sizeof(AVFilterInOut
> +if (!(match = av_mallocz(sizeof(AVFilterInOut {
> +av_free(name);
> return AVERROR(ENOMEM);
> +}
> match->name= name;
> match->pad_idx = pad;
> }
> @@ -318,24 +321,27 @@ static int parse_outputs(const char **buf,
> AVFilterInOut **curr_inputs,
> AVFilterInOut *match;
>
> AVFilterInOut *input = *curr_inputs;
> +
> +if (!name)
> +return AVERROR(EINVAL);
> +
> if (!input) {
> av_log(log_ctx, AV_LOG_ERROR,
> - "No output pad can be associated to link label '%s'.\n",
> - name);
> + "No output pad can be associated to link label '%s'.\n",
> name);
> +av_free(name);
> return AVERROR(EINVAL);
> }
> *curr_inputs = (*curr_inputs)->next;
>
> -if (!name)
> -return AVERROR(EINVAL);
> -
> /* First check if the label is not in the open_inputs list */
> match = extract_inout(name, open_inputs);
>
> if (match) {
> if ((ret = link_filter(input->filter_ctx, input->pad_idx,
> - match->filter_ctx, match->pad_idx,
> log_ctx)) < 0)
> + match->filter_ctx, match->pad_idx,
> log_ctx)) < 0) {
> +av_free(name);
> return ret;
> +}
> av_free(match->name);
> av_free(name);
> av_free(match);
ping
Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
Hendrik Leppkes writes:
> On Sat, Oct 13, 2012 at 12:55 PM, Måns Rullgård wrote:
>> Martin Storsjö writes:
>>
>>> diff --git a/configure b/configure
>>> index 99830d8..5480ce0 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2778,14 +2778,33 @@ case $target_os in
>>> shlibdir_default="$bindir_default"
>>> SLIBPREF=""
>>> SLIBSUF=".dll"
>>> +if enabled_all msvc shared; then
>>> +# Link to the import library instead of the
>>> +# normal static library.
>>> +LD_LIB='%.lib'
>>> +fi
>>>
>>> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
>>> SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
>>> -SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
>>> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
>>> $(SLIBNAME_WITH_MAJOR)'
>>> +if enabled msvc; then
>>> +# The libtarget names for lib.exe differ from the ones for
>>> dlltool
>>> +if enabled x86_64; then
>>> +LIBTARGET=x64
>>> +fi
>>> +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
>>> $$(@:$(SLIBSUF)=.def)'
>>> +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
>>> -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
>>> +else
>>> +SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
>>> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
>>> $(SLIBNAME_WITH_MAJOR)'
>>> +fi
>>> SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
>>> SLIB_INSTALL_LINKS=
>>> SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
>>> -SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>>> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>>> -SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
>>> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>>> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
>>> +if enabled msvc; then
>>> +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>>> +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
>>> -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
>>> +else
>>> +SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>>> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>>> +SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
>>> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>>> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
>>> +fi
>>> objformat="win32"
>>> dlltool="${cross_prefix}dlltool"
>>> ranlib=:
>>
>> This is insane. MSVC should not be using mingw32 as target-os.
>>
>
> I agree that it would be great to seperate this, however
> auto-detection uses uname, which sadly reports mingw32.
> Another rule to auto-detect it properly? Require specifying
> --target-os for such builds?
We could make --toolchain=msvc change the default. I imagine most
people building it will be using that option.
--
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
On Sat, Oct 13, 2012 at 12:55 PM, Måns Rullgård wrote:
> Martin Storsjö writes:
>
>> diff --git a/configure b/configure
>> index 99830d8..5480ce0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2778,14 +2778,33 @@ case $target_os in
>> shlibdir_default="$bindir_default"
>> SLIBPREF=""
>> SLIBSUF=".dll"
>> +if enabled_all msvc shared; then
>> +# Link to the import library instead of the
>> +# normal static library.
>> +LD_LIB='%.lib'
>> +fi
>>
>> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
>> SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
>> -SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
>> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
>> $(SLIBNAME_WITH_MAJOR)'
>> +if enabled msvc; then
>> +# The libtarget names for lib.exe differ from the ones for
>> dlltool
>> +if enabled x86_64; then
>> +LIBTARGET=x64
>> +fi
>> +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
>> $$(@:$(SLIBSUF)=.def)'
>> +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
>> -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
>> +else
>> +SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
>> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
>> $(SLIBNAME_WITH_MAJOR)'
>> +fi
>> SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
>> SLIB_INSTALL_LINKS=
>> SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
>> -SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>> -SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
>> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
>> +if enabled msvc; then
>> +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>> +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
>> -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
>> +else
>> +SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
>> +SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
>> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
>> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
>> +fi
>> objformat="win32"
>> dlltool="${cross_prefix}dlltool"
>> ranlib=:
>
> This is insane. MSVC should not be using mingw32 as target-os.
>
I agree that it would be great to seperate this, however
auto-detection uses uname, which sadly reports mingw32.
Another rule to auto-detect it properly? Require specifying
--target-os for such builds?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] build: add rule to generate preprocessed source files
This is useful for debugging. Dependencies for these files are not generated due to limitations in many compilers. Signed-off-by: Mans Rullgard --- Makefile| 3 +++ configure | 1 + library.mak | 8 ++-- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1cbf2aa..9abb835 100644 --- a/Makefile +++ b/Makefile @@ -45,6 +45,9 @@ COMPILE_S = $(call COMPILE,AS) %.o: %.S $(COMPILE_S) +%.i: %.c + $(CC) $(CCFLAGS) $(CC_E) $< + %.h.c: $(Q)echo '#include "$*.h"' >$@ diff --git a/configure b/configure index 26cd7ea..2759aef 100755 --- a/configure +++ b/configure @@ -3689,6 +3689,7 @@ ASFLAGS=$ASFLAGS AS_C=$AS_C AS_O=$AS_O CC_C=$CC_C +CC_E=$CC_E CC_O=$CC_O LD_O=$LD_O LD_LIB=$LD_LIB diff --git a/library.mak b/library.mak index b365935..d4308c8 100644 --- a/library.mak +++ b/library.mak @@ -15,12 +15,16 @@ $(SUBDIR)%-test.o: $(SUBDIR)%-test.c $(SUBDIR)%-test.o: $(SUBDIR)%.c $(COMPILE_C) +$(SUBDIR)%-test.i: $(SUBDIR)%.c + $(CC) $(CCFLAGS) $(CC_E) $< + $(SUBDIR)x86/%.o: $(SUBDIR)x86/%.asm $(DEPYASM) $(YASMFLAGS) -I $( $(@:.o=.d) $(YASM) $(YASMFLAGS) -I $(https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
On 10/13/2012 12:46 PM, Martin Storsjö wrote: > From: "Ronald S. Bultje" > > This requires the makedef perl script by Derek, which probably will > go into the c99-to-c89 repo. That scripts produces a .def file, > listing the symbols to be exported, based on the gcc version > scripts and the built object files. > > To properly load non-function symbols from DLL files, the data > symbol declarations need to have the attribute __declspec(dllimport) > when building the calling code. (On mingw, the linker can fix this > up automatically, which is why it has not been an issue so far.) > > The __declspec(dllimport) attribute is added via a macro. Since > it has to be present when building code that refer to these symbols, > but not be present while building the library that exports the symbols > themselves, the makefile is modified to add a define like > COMPILING_ while building each library. This is used in the > definition of the AV_SYMBOL macro - on non-MSVC compilers, it is > empty. On MSVC, it is __declspec(dllimport) for declarations in other > libraries than the object file currently compiled. > > This also implies that code that is built to link to a certain > library as a DLL can't link to the same library as a static library. > Therefore, we only allow building either static or shared but not > both at the same time. > > Also, linking to DLLs is slightly different from linking to shared > libraries on other platforms. DLLs use a thing called import > libraries, which is basically a stub library allowing the linker > know which symbols exist in the DLL and what name the DLL will > have at runtime. > > In mingw/gcc, the import library is usually named libfoo.dll.a, > which goes next to a static library named libfoo.a. This allows gcc > to pick the dynamic one, if available, from the normal -lfoo switches, > just as it does for libfoo.a vs libfoo.so on unix. On MSVC however, > you need to literally specify the name of the import library instead of > the static library. > --- > configure | 27 --- > libavcodec/ac3tab.h|3 ++- > libavcodec/dca.h |3 ++- > libavcodec/mjpeg.h | 15 --- > libavcodec/mpeg12data.h|3 ++- > libavcodec/mpeg4audio.h|3 ++- > libavcodec/mpegaudiodata.h |6 -- > libavcodec/symbols.h | 32 > library.mak|1 + > 9 files changed, 77 insertions(+), 16 deletions(-) > create mode 100644 libavcodec/symbols.h > > diff --git a/configure b/configure > index 99830d8..5480ce0 100755 > --- a/configure > +++ b/configure > @@ -2778,14 +2778,33 @@ case $target_os in > shlibdir_default="$bindir_default" > SLIBPREF="" > SLIBSUF=".dll" > +if enabled_all msvc shared; then > +# Link to the import library instead of the > +# normal static library. > +LD_LIB='%.lib' > +fi > > SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' > SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' > -SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def) > -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)' > +if enabled msvc; then > +# The libtarget names for lib.exe differ from the ones for > dlltool > +if enabled x86_64; then > +LIBTARGET=x64 > +fi > +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > > $$(@:$(SLIBSUF)=.def)' > +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET) > -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)' > +else > +SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d > $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D > $(SLIBNAME_WITH_MAJOR)' > +fi > SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' > SLIB_INSTALL_LINKS= > SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' > -SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a) > $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' > -SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def) > -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) > -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base' > +if enabled msvc; then > +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' > +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def) > -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)' > +else > +SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a) > $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)' > +SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def) > -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) > -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base' > +fi > objformat="win32" > dl
Re: [libav-devel] [PATCH] Add support for building shared libraries with MSVC
Martin Storsjö writes:
> diff --git a/configure b/configure
> index 99830d8..5480ce0 100755
> --- a/configure
> +++ b/configure
> @@ -2778,14 +2778,33 @@ case $target_os in
> shlibdir_default="$bindir_default"
> SLIBPREF=""
> SLIBSUF=".dll"
> +if enabled_all msvc shared; then
> +# Link to the import library instead of the
> +# normal static library.
> +LD_LIB='%.lib'
> +fi
>
> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
> SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
> -SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def)
> -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'
> +if enabled msvc; then
> +# The libtarget names for lib.exe differ from the ones for
> dlltool
> +if enabled x86_64; then
> +LIBTARGET=x64
> +fi
> +SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
> $$(@:$(SLIBSUF)=.def)'
> +SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
> -def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
> +else
> +SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
> $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
> $(SLIBNAME_WITH_MAJOR)'
> +fi
> SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
> SLIB_INSTALL_LINKS=
> SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
> -SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> -SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
> +if enabled msvc; then
> +SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> +SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
> -implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
> +else
> +SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
> +SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
> -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
> -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
> +fi
> objformat="win32"
> dlltool="${cross_prefix}dlltool"
> ranlib=:
This is insane. MSVC should not be using mingw32 as target-os.
--
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: separate option-arguments from options to POSIX commands
On Sat, 13 Oct 2012, Måns Rullgård wrote: Martin Storsjö writes: On Sat, 13 Oct 2012, Mans Rullgard wrote: POSIX says this about option syntax: If the SYNOPSIS of a standard utility shows an option with a mandatory option-argument, a conforming application shall use separate arguments for that option and its option-argument. However, a conforming implementation shall also permit applications to specify the option and option-argument in the same argument string without intervening characters. Do I interpret this correctly if I read it as the tools should support both versions of parameter passing, so one that only supports either version is incorrect? It says tools should allow both, but scripts should always separate them. Ok then, the patch is ok with minix mentioned in the commit message. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] Add support for building shared libraries with MSVC
From: "Ronald S. Bultje"
This requires the makedef perl script by Derek, which probably will
go into the c99-to-c89 repo. That scripts produces a .def file,
listing the symbols to be exported, based on the gcc version
scripts and the built object files.
To properly load non-function symbols from DLL files, the data
symbol declarations need to have the attribute __declspec(dllimport)
when building the calling code. (On mingw, the linker can fix this
up automatically, which is why it has not been an issue so far.)
The __declspec(dllimport) attribute is added via a macro. Since
it has to be present when building code that refer to these symbols,
but not be present while building the library that exports the symbols
themselves, the makefile is modified to add a define like
COMPILING_ while building each library. This is used in the
definition of the AV_SYMBOL macro - on non-MSVC compilers, it is
empty. On MSVC, it is __declspec(dllimport) for declarations in other
libraries than the object file currently compiled.
This also implies that code that is built to link to a certain
library as a DLL can't link to the same library as a static library.
Therefore, we only allow building either static or shared but not
both at the same time.
Also, linking to DLLs is slightly different from linking to shared
libraries on other platforms. DLLs use a thing called import
libraries, which is basically a stub library allowing the linker
know which symbols exist in the DLL and what name the DLL will
have at runtime.
In mingw/gcc, the import library is usually named libfoo.dll.a,
which goes next to a static library named libfoo.a. This allows gcc
to pick the dynamic one, if available, from the normal -lfoo switches,
just as it does for libfoo.a vs libfoo.so on unix. On MSVC however,
you need to literally specify the name of the import library instead of
the static library.
---
configure | 27 ---
libavcodec/ac3tab.h|3 ++-
libavcodec/dca.h |3 ++-
libavcodec/mjpeg.h | 15 ---
libavcodec/mpeg12data.h|3 ++-
libavcodec/mpeg4audio.h|3 ++-
libavcodec/mpegaudiodata.h |6 --
libavcodec/symbols.h | 32
library.mak|1 +
9 files changed, 77 insertions(+), 16 deletions(-)
create mode 100644 libavcodec/symbols.h
diff --git a/configure b/configure
index 99830d8..5480ce0 100755
--- a/configure
+++ b/configure
@@ -2778,14 +2778,33 @@ case $target_os in
shlibdir_default="$bindir_default"
SLIBPREF=""
SLIBSUF=".dll"
+if enabled_all msvc shared; then
+# Link to the import library instead of the
+# normal static library.
+LD_LIB='%.lib'
+fi
SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
-SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def)
-l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'
+if enabled msvc; then
+# The libtarget names for lib.exe differ from the ones for dlltool
+if enabled x86_64; then
+LIBTARGET=x64
+fi
+SLIB_CREATE_DEF_CMD='makedef $(SUBDIR)lib$(NAME).ver $(OBJS) >
$$(@:$(SLIBSUF)=.def)'
+SLIB_EXTRA_CMD='-lib.exe -machine:$(LIBTARGET)
-def:$$(@:$(SLIBSUF)=.def) -out:$(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib)'
+else
+SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d
$$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D
$(SLIBNAME_WITH_MAJOR)'
+fi
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS=
SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)'
-SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
-SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
-Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
-Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
+if enabled msvc; then
+SLIB_INSTALL_EXTRA_LIB='$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
+SHFLAGS='-dll -def:$$(@:$(SLIBSUF)=.def)
-implib:$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)'
+else
+SLIB_INSTALL_EXTRA_LIB='lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
$(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.def)'
+SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def)
-Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a)
-Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
+fi
objformat="win32"
dlltool="${cross_prefix}dlltool"
ranlib=:
@@ -3521,6 +3540,8 @@ elif enabled pathscale; then
add_cflags -fstrict-overflow -OPT:wrap_around_unsafe_opt=OFF
elif enabled msvc; then
enabled x86_32 && disable aligned_stack
+enabled_all share
Re: [libav-devel] [PATCH] configure: separate option-arguments from options to POSIX commands
Martin Storsjö writes: > On Sat, 13 Oct 2012, Mans Rullgard wrote: > >> POSIX says this about option syntax: >> >> If the SYNOPSIS of a standard utility shows an option with a >> mandatory option-argument, a conforming application shall use >> separate arguments for that option and its option-argument. >> However, a conforming implementation shall also permit applications >> to specify the option and option-argument in the same argument >> string without intervening characters. > > Do I interpret this correctly if I read it as the tools should support > both versions of parameter passing, so one that only supports either > version is incorrect? It says tools should allow both, but scripts should always separate them. > I'd appreciate if you'd amend the commit message to specify which > actual systems this fixes. Minix. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] configure: recognise Minix as OS
On 2012-10-13 03:34:08 +0100, Måns Rullgård wrote: > No special setup is required for Minix. > > Signed-off-by: Mans Rullgard > --- > configure | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configure b/configure > index b076945..66806bf 100755 > --- a/configure > +++ b/configure > @@ -2877,6 +2877,8 @@ case $target_os in > add_cppflags -D_OSF_SOURCE -D_POSIX_PII -D_REENTRANT > AVSERVERLDFLAGS= > ;; > +minix) > +;; > none) > ;; > *) ok Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] configure: recognise Minix as OS
On Sat, 13 Oct 2012, Mans Rullgard wrote: No special setup is required for Minix. Signed-off-by: Mans Rullgard --- configure | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure b/configure index b076945..66806bf 100755 --- a/configure +++ b/configure @@ -2877,6 +2877,8 @@ case $target_os in add_cppflags -D_OSF_SOURCE -D_POSIX_PII -D_REENTRANT AVSERVERLDFLAGS= ;; +minix) +;; none) ;; *) -- 1.7.12.3 Ok // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: work around bug in ash shell
On Sat, 13 Oct 2012, Mans Rullgard wrote:
The ash 'test' builtin misbehaves if the first operand of a binary
operator looks like a unary operator.
Signed-off-by: Mans Rullgard
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index bc3a218..b076945 100755
--- a/configure
+++ b/configure
@@ -592,7 +592,7 @@ print_config(){
}
print_enabled(){
-test "$1" = -n && end=" " && shift || end="\n"
+test x"$1" = x-n && end=" " && shift || end="\n"
suf=$1
shift
for v; do
--
1.7.12.3
Ok.
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: separate option-arguments from options to POSIX commands
On Sat, 13 Oct 2012, Mans Rullgard wrote: POSIX says this about option syntax: If the SYNOPSIS of a standard utility shows an option with a mandatory option-argument, a conforming application shall use separate arguments for that option and its option-argument. However, a conforming implementation shall also permit applications to specify the option and option-argument in the same argument string without intervening characters. Do I interpret this correctly if I read it as the tools should support both versions of parameter passing, so one that only supports either version is incorrect? I'd appreciate if you'd amend the commit message to specify which actual systems this fixes. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] build: tms470: work around glibc math.h problems
On Sat, 13 Oct 2012, Mans Rullgard wrote:
The glibc definitions of INFINITY and NAN do not work with the
tms470 compiler, nor do our usual fallbacks.
Signed-off-by: Mans Rullgard
---
compat/tms470/math.h | 7 +++
configure| 1 +
2 files changed, 8 insertions(+)
create mode 100644 compat/tms470/math.h
diff --git a/compat/tms470/math.h b/compat/tms470/math.h
new file mode 100644
index 000..1104d74
--- /dev/null
+++ b/compat/tms470/math.h
@@ -0,0 +1,7 @@
+#include_next
+
+#undef INFINITY
+#undef NAN
+
+#define INFINITY (*(const float*)((const unsigned []){ 0x7f80 }))
+#define NAN (*(const float*)((const unsigned []){ 0x7fc0 }))
diff --git a/configure b/configure
index 5c03c02..7a6d8b6 100755
--- a/configure
+++ b/configure
@@ -2919,6 +2919,7 @@ test -n "$libc_type" && enable $libc_type
# hacks for compiler/libc/os combinations
if enabled_all tms470 glibc; then
+CPPFLAGS="-I${source_path}/compat/tms470 ${CPPFLAGS}"
add_cppflags -D__USER_LABEL_PREFIX__=
add_cppflags -D__builtin_memset=memset
add_cppflags -D__gnuc_va_list=va_list -D_VA_LIST_DEFINED
--
1.7.12.3
Ok
FWIW, these definitions also seem to work with MSVC.
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] build: tms470: work around glibc math.h problems
On 2012-10-13 03:31:29 +0100, Måns Rullgård wrote:
> The glibc definitions of INFINITY and NAN do not work with the
> tms470 compiler, nor do our usual fallbacks.
>
> Signed-off-by: Mans Rullgard
> ---
> compat/tms470/math.h | 7 +++
> configure| 1 +
> 2 files changed, 8 insertions(+)
> create mode 100644 compat/tms470/math.h
>
> diff --git a/compat/tms470/math.h b/compat/tms470/math.h
> new file mode 100644
> index 000..1104d74
> --- /dev/null
> +++ b/compat/tms470/math.h
> @@ -0,0 +1,7 @@
> +#include_next
> +
> +#undef INFINITY
> +#undef NAN
> +
> +#define INFINITY (*(const float*)((const unsigned []){ 0x7f80 }))
> +#define NAN (*(const float*)((const unsigned []){ 0x7fc0 }))
> diff --git a/configure b/configure
> index 5c03c02..7a6d8b6 100755
> --- a/configure
> +++ b/configure
> @@ -2919,6 +2919,7 @@ test -n "$libc_type" && enable $libc_type
> # hacks for compiler/libc/os combinations
>
> if enabled_all tms470 glibc; then
> +CPPFLAGS="-I${source_path}/compat/tms470 ${CPPFLAGS}"
> add_cppflags -D__USER_LABEL_PREFIX__=
> add_cppflags -D__builtin_memset=memset
> add_cppflags -D__gnuc_va_list=va_list -D_VA_LIST_DEFINED
ok
Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/3] configure: improve tms470 compiler usage with glibc
On Sat, 13 Oct 2012, Mans Rullgard wrote: Apply flags to work around glibc quirks only if glibc is detected, and add a few more such flags. Do not mess with as/ld settings in probe_cc. This is not the proper place. Signed-off-by: Mans Rullgard --- configure | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) Ok // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] configure: tms470: add mapping for -mfpu=vfpv3-d16 flag
On Sat, 13 Oct 2012, Mans Rullgard wrote:
Signed-off-by: Mans Rullgard
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 2890ab2..f770ca7 100755
--- a/configure
+++ b/configure
@@ -2219,6 +2219,7 @@ tms470_flags(){
-mfpu=neon) echo --float_support=vfpv3 --neon ;;
-mfpu=vfp) echo --float_support=vfpv2;;
-mfpu=vfpv3)echo --float_support=vfpv3;;
+-mfpu=vfpv3-d16) echo --float_support=vfpv3d16;;
-msoft-float) echo --float_support=vfplib ;;
-O[0-3]|-mf=*) echo $flag;;
-g) echo -g -mn ;;
--
1.7.12.3
Ok
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
