[FFmpeg-devel] [PATCH] dct-test compile fix
Jacob Meuser
jakemsr
Wed Jun 25 05:01:26 CEST 2008
On Wed, Jun 25, 2008 at 02:50:19AM +0100, M?ns Rullg?rd wrote:
> 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?
--- configure.orig Fri Jun 20 19:40:11 2008
+++ configure Sat Jun 21 18:28:29 2008
@@ -965,7 +965,7 @@ SLIBPREF="lib"
SLIBSUF=".so"
SLIBNAME='$(SLIBPREF)$(FULLNAME)$(SLIBSUF)'
SLIBNAME_WITH_VERSION='$(SLIBNAME).$(LIBVERSION)'
-SLIBNAME_WITH_MAJOR='$(SLIBNAME).$(LIBMAJOR)'
+SLIBNAME_WITH_MAJOR='$(SLIBNAME).$(LIBVERSION)'
LIB_INSTALL_EXTRA_CMD='$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
# gcc stupidly only outputs the basename of targets with -MM
but I am also now overriding LIBVERSION. I made this change after
getting past the problem.
>
> > @@ -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
ok, so? this is what I meant by these changes are "hacks" that aren't
"correct". this one isn't a big deal anyway.
> > @@ -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.
maybe. but why is it needed in the first place?
> >> > 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.
the FFEXTRALIBS -> $(LIB$(NAME)_EXTRALIBS) change is to be more
precise about which ffmpeg libraries need which system libs to
resolve symbols. currently, all extralibs are linked to all
ffmpeg libraries. I define LIBfoo_EXTRTALIBS in the port build
system.
the $$^ -> $(sort $(OBJS)) change is needed for the situation
below
> > $ 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.
maybe, but why do you think so?
without the change, the link command ends up roughly like so, iirc:
$ cc -shared -o foo.shared -L/path/to/new/libbar foo-obj.o libbar/libbar.so
-lbar
which seems kinda odd to me, naming libbar twice.
> > @@ -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?
build linker (ld) uses highest major and minor. runtime (ld.so) uses
the version used at build link time. though ld.so may fall back to
the same major with higher minor if an exact match isn't found,
I think.
if you mean , how to distinguish between libfoo.so.4.0 and
libfoo.so.5.0 at build link (ld), then you store them in different
paths and -L and possibly -R or -rpath.
>
> --
> M?ns Rullg?rd
> mans at mansr.com
> _______________________________________________
> 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