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

Måns Rullgård mans
Wed Jun 25 03:50:19 CEST 2008


Jacob Meuser <jakemsr at sdf.lonestar.org> writes:

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

Well, what values did you assign them?

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

POSIX disagrees:

  The <sys/socket.h> header shall define the type socklen_t

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

Broken linker.  If the flag doesn't work, it shouldn't accept it.

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

That is two unrelated changes.  Please explain them separately.

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

Smells like broken linker.

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

With that convention, how does the linker know which version to use?


-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list