[SCM] FFmpeg packaging branch, master, updated. debian/0.5+svn20090420-2-17-gc8d8dad

[Andres Mejia]

On Wednesday 13 May 2009 04:57:03 Reinhard Tartler wrote:
> Andres Mejia <mcitadel at gmail.com> writes:
> > On Wednesday 13 May 2009 01:35:05 Reinhard Tartler wrote:
> >> ceros-guest at users.alioth.debian.org writes:
> >> > The following commit has been merged in the master branch:
> >> > commit 4b453cb6e97f4c960433e2134228b266458ed2bd
> >> > Author: Andres Mejia <mcitadel at gmail.com>
> >> > Date:   Tue May 12 23:18:59 2009 -0400
> >> >
> >> >     Add new confflags for new build dependencies.
> >> >     Also add confflag for zlib.
> >> >     Add 'fix-fpic' DEB_BUILD_OPTIONS for resolving fpic issues.
> >>
> >> This commit breaks compilation of non-optimized builds that can be
> >> requested by setting DEB_BUILD_OPTIONS.
> >
> > That is unless they apply fpic-ftbfs-fix.patch. In any case, this is a
> > bug in gcc, from what I've read in ffmpeg-devel.
>
> Yes, but that patch has also its own problems.
>
> For us as ffmpeg maintainers, it doesn't matter if it is a bug in gcc or
> not, we won't be able to fix them in either case.
>
> > Also, I am going to remove that option but introduce some way to pass in
> > any cflags and other arguments to the configure script.
>
> I don't think this is the right approach. I think it would be much
> better to directly work inside the configure script. This would also be
> much easier to communicate and discuss with with upstream.

This is meant for a different reason, such as someone wants to work on fixing gcc 
warnings, so they'll pass -Werror. Someone is told to try different options to 
build package to debug a problem they're having, so they do so. And so on.

> >> As I told you several times, this is really a no-go. In fact, in etch we
> >> shipped an ffmpeg compiled this way but did stop that madness in
> >> lenny. So this is really a step backwards.
> >>
> >> Why the heck do you insist on that approach?
> >
> > ffmpeg is built with -fpic on other archs right? I'm going to check amd64
> > libs and if they have non-pic code, then I will insist on pursuing this
> > further. If not, very well.
>
> The configure script carefully select the right compiler flags depending
> on the architecture and the compilation unit. Passing compiler flags at
> configure time is too chunky for ffmpeg, there are too many hand
> optimisations, both for architectures and source files. That's why it's
> much better to work directly on the configure flags.

-- 
Regards,
Andres
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20090513/66b024e2/attachment.pgp>