[FFmpeg-devel] [PATCH] dct-test compile fix

Jacob Meuser jakemsr
Wed Jun 25 02:40:39 CEST 2008


On Wed, Jun 25, 2008 at 01:54:05AM +0200, Diego Biurrun wrote:
> On Tue, Jun 24, 2008 at 09:53:32PM +0000, Jacob Meuser wrote:
> > On Tue, Jun 24, 2008 at 10:20:56PM +0100, M?ns Rullg?rd wrote:
> > > "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> > > > On Tue, Jun 24, 2008 at 4:23 PM, Diego Biurrun <diego at biurrun.de> wrote:
> > > >> Are you still using your port of our build system to autoconf that
> > > >> manages to cram less features into more lines of code? ;-p
> > > >
> > > > As long as no proper make dist and distcheck replacements exist such
> > > > that it allows me to integrate it with 0 (zero) lines of (build) code
> > > > into any project that I base on ffmpeg: yes.
> > > >
> > > > (Actually, it's 2 lines of build code: I need
> > > > AC_CONFIG_SUBDIRS(ffmpeg) in my configure.ac and a SUBDIRS=ffmpeg in
> > > > the toplevel Makefile.am. Try beating that. :-).)
> > > 
> > > The fallacy here is in the use of autoconf at all.  If the outer
> > > package didn't use autoconf, interfacing to FFmpeg's configure would
> > > be trivial.
> > 
> > I had to hack ffmpeg's build process more than most autotools
> > using projects to get ffmpeg to build and work on OpenBSD ...
> > including removal of some of the explicit OpenBSD support in the
> > configure script which has bit-rotted to the breaking point
> > (hint: shared library names).
> 
> That hint is not enough, I need to be told what is wrong, I don't have
> access to an OpenBSD system for testing.  Patches are also welcome.

$OpenBSD: patch-configure,v 1.18 2008/01/26 01:56:02 jakemsr Exp $
--- configure.orig	Fri Jun 20 19:40:11 2008
+++ configure	Sat Jun 21 18:28:29 2008
@@ -1213,9 +1213,9 @@ case $target_os in
         disable need_memalign
         LIBOBJFLAGS='$(PIC)'
         SHFLAGS='-shared'
-        SLIBNAME='$(SLIBPREF)$(FULLNAME)$(SLIBSUF).$(LIBVERSION)'
-        SLIBNAME_WITH_VERSION='$(SLIBNAME)'
-        SLIBNAME_WITH_MAJOR='$(SLIBNAME)'
+        #SLIBNAME='$(SLIBPREF)$(FULLNAME)$(SLIBSUF).$(LIBVERSION)'
+        #SLIBNAME_WITH_VERSION='$(SLIBNAME)'
+        #SLIBNAME_WITH_MAJOR='$(SLIBNAME)'
         oss_demuxer_extralibs="-lossaudio"
         oss_muxer_extralibs="-lossaudio"
         ;;


without patching that out, make dies with something like:

can't find target for libpostproc.so.

I ended up just changing the default SLIBNAME* variables, which
worked.

@@ -1756,7 +1763,7 @@ fi
 
 texi2html -version > /dev/null 2>&1 && enable texi2html || disable texi2html
 
-check_type sys/socket.h socklen_t
+check_type sys/types.h socklen_t
 
 ##########################################
 # Network check

simply stated, socklen_t is defined in sys/types.h

@@ -1831,7 +1838,7 @@ enabled extra_warnings && check_cflags -Winline
 # add some linker flags
 check_ldflags -Wl,--warn-common
 check_ldflags $LDLATEFLAGS
-check_ldflags -Wl,-Bsymbolic
+# check_ldflags -Wl,-Bsymbolic
 
 if enabled small; then
     check_cflags -Os            # not all compilers support -Os


IIRC, that causes symbol conflicts or maybe missing symbols, I can't
recall which right now


@@ -2204,8 +2211,7 @@ Version: $version
 Requires: $(disabled shared && echo $requires)
 Requires.private: $(enabled shared && echo $requires)
 Conflicts:
-Libs: -L\${libdir} -l${shortname} $(disabled shared && echo $libs)
-Libs.private: $(enabled shared && echo $libs)
+Libs: -L\${libdir} -l${shortname} $libs
 Cflags: -I\${includedir}
 EOF
 cat <<EOF > $name/$name-uninstalled.pc
@@ -2224,17 +2230,17 @@ Cflags: -I\${includedir}
 EOF
 }
 
-pkgconfig_generate libavutil "FFmpeg utility library" "$LIBAVUTIL_VERSION"
-pkgconfig_generate libavcodec "FFmpeg codec library" "$LIBAVCODEC_VERSION" "$extralibs" "$pkg_requires libavutil = $LIBAVUTIL_VERSION"
-pkgconfig_generate libavformat "FFmpeg container format library" "$LIBAVFORMAT_VERSION" "$extralibs" "$pkg_requires libavcodec = $LIBAVCODEC_VERSION"
-pkgconfig_generate libavdevice "FFmpeg device handling library" "$LIBAVDEVICE_VERSION" "$extralibs" "$pkg_requires libavformat = $LIBAVFORMAT_VERSION"
+pkgconfig_generate libavutil "FFmpeg utility library" "$LIBAVUTIL_VERSION" "$LIBavutil_EXTRALIBS"
+pkgconfig_generate libavcodec "FFmpeg codec library" "$LIBAVCODEC_VERSION" "$LIBavcodec_EXTRALIBS" "libavutil"
+pkgconfig_generate libavformat "FFmpeg container format library" "$LIBAVFORMAT_VERSION" "$LIBavformat_EXTRALIBS" "libavutil libavcodec"
+pkgconfig_generate libavdevice "FFmpeg device handling library" "$LIBAVDEVICE_VERSION" "$LIBavdevice_EXTRALIBS" "libavutil libavformat"
 enabled avfilter &&
     pkgconfig_generate libavfilter "FFmpeg video filtering library" "$LIBAVFILTER_VERSION" "$extralibs" "$pkg_requires libavutil = $LIBAVUTIL_VERSION"
 enabled postproc &&
-    pkgconfig_generate libpostproc "FFmpeg post processing library" "$LIBPOSTPROC_VERSION"
+    pkgconfig_generate libpostproc "FFmpeg post processing library" "$LIBPOSTPROC_VERSION" "$LIBpostproc_EXTRALIBS" "libavutil"
 if enabled swscale; then
-    pkgconfig_generate libswscale "FFmpeg image rescaling library" "$LIBSWSCALE_VERSION" "" "libavutil = $LIBAVUTIL_VERSION"
+    pkgconfig_generate libswscale "FFmpeg image rescaling library" "$LIBSWSCALE_VERSION" "$LIBswscale_EXTRALIBS" "libavutil"
 else
-    pkgconfig_generate libswscale "FFmpeg image rescaling library" "$LIBSWSCALE_VERSION" "" "$pkg_requires libavcodec = $LIBAVCODEC_VERSION"
+    pkgconfig_generate libswscale "FFmpeg image rescaling library" "$LIBSWSCALE_VERSION" "$LIBswscale_EXTRALIBS"
     apply libswscale/libswscale.pc sed s/^Libs:.*$/Libs:/
 fi


this is mostly because we want strict (and correct!) interlibrary
dependencies.  LIBfoo_EXTRALIBS is set in the environment by the
ports build process.


> > well, at least you're only (ab)using GNU make as opposed to
> > say scons (shudder).
> 
> GNU Make is available everywhere (even on OpenBSD) and it is much better
> than traditional Unix Make.  This is not something that can be said
> about all GNU software...
> 
> > and no, I'm not going to send my patches back to you because
> > they are not "acceptable" and are purely "hacks" that most likely
> > break other platforms.  I don't have time to "correctly" fix the
> > problems, or argue what is or isn't "correct".
> 
> This is precisely the experience I have been having with BSD people here
> and in MPlayer: Lots of complaints about portability issues, but no
> solutions that are portable even between BSD flavors.  All you seem
> to do is collect hacks in your ports trees...

here is an example of a non-portable assumption burried deep in gnu
make-ism:

$OpenBSD$
--- subdir.mak.orig	Fri Jun 20 19:40:11 2008
+++ subdir.mak	Sat Jun 21 10:06:50 2008
@@ -29,7 +29,7 @@ $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR)
 
 $(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS)
 	$(SLIB_CREATE_DEF_CMD)
-	$(CC) $(SHFLAGS) $(FFLDFLAGS) -o $$@ $$^ $(FFEXTRALIBS) $(EXTRAOBJS)
+	$(CC) $(SHFLAGS) $(FFLDFLAGS) -o $$@ $(sort $(OBJS)) $(LIB$(NAME)_EXTRALIBS) $(EXTRAOBJS)
 	$(SLIB_EXTRA_CMD)
 
 ifdef SUBDIR

without that change, dependant FFLIBS end up linked in twice, e.g.

$ objdump -p libavcodec.so.12.0 | grep avutil
  NEEDED	libavutil/libavutil.so
  NEEDED	libavutil.so.6.0

obviously, ibavutil/libavutil.so does not exist after 'make install',
as libavutil.so.6.0 is installed in /usr/local/lib.


@@ -39,12 +39,8 @@ endif
 
 install-lib$(NAME)-shared: $(SUBDIR)$(SLIBNAME)
 	install -d "$(SHLIBDIR)"
-	install -m 755 $(SUBDIR)$(SLIBNAME) "$(SHLIBDIR)/$(SLIBNAME_WITH_VERSION)"
+	install -m 755 $(SUBDIR)$(SLIBNAME_WITH_VERSION) "$(SHLIBDIR)"
 	$(STRIP) "$(SHLIBDIR)/$(SLIBNAME_WITH_VERSION)"
-	cd "$(SHLIBDIR)" && \
-		$(LN_S) $(SLIBNAME_WITH_VERSION) $(SLIBNAME_WITH_MAJOR)
-	cd "$(SHLIBDIR)" && \
-		$(LN_S) $(SLIBNAME_WITH_VERSION) $(SLIBNAME)
 	$(SLIB_INSTALL_EXTRA_CMD)
 
 install-lib$(NAME)-static: $(SUBDIR)$(LIBNAME)


OpenBSD has a policy against multiple copies/links of the same
library.  libraries should use the form libfoo.so.major.minor.
also, we wish to keep control of library versions, incase changes
to the toolchain or system headers would necessitate bumping library
versions.


> > but if you're interested, they will (most likely) show up at
> > http://www.openbsd.org/cgi-bin/cvsweb/ports/graphics/ffmpeg/patches/
> > within the next week.
> 
> Let me know when they show up.

will do.

> Diego
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

-- 
jakemsr at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org




More information about the ffmpeg-devel mailing list