#303: new ffmpeg includes layout
-------------------------+--------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
I don't know when it changed (btwn 07-12-3 and 08-08-15), but my Aug 15
2008 build of ffmpeg has rearranged the include layout. Instead of all
includes in $prefix/include/ffmpeg, they are now in separate subfolders by
library:
If they do: I'm not going to try to support multiple versions
simultaneously, so until the new interface becomes more common than the
old interface, anyone using the newer version will have to forego --with-
ffmpeg.
should work - that should catch both cases of include forms. I couldn't
fully test right now because I forgot to configure ffmpeg with libswscale,
but it did get as far as finding avcodec.h and avformat.h.
#303: new ffmpeg includes layout
------------------------+---------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
------------------------+---------------------------------------------------
Changes (by neteler):
* platform: Unspecified => All
* cpu: Unspecified => All
Comment:
Trying on Linux (new Mandriva 2009.0) the layout is again different:
{{{
rpm -qil lib64ffmpeg-devel-0.4.9-3.pre1.14161.1mdv2009.0
Name : lib64ffmpeg-devel Relocations: (not relocatable)
Version : 0.4.9 Vendor: Mandriva
Release : 3.pre1.14161.1mdv2009.0 Build Date: Fri 11 Jul 2008
07:47:08 AM CEST
Install Date: Tue 30 Dec 2008 10:29:49 AM CET Build Host:
klodia.mandriva.com
Group : Development/C Source RPM:
ffmpeg-0.4.9-3.pre1.14161.1mdv2009.0.src.rpm
Size : 223517 License: GPLv2+
Signature : DSA/SHA1, Fri 03 Oct 2008 01:29:04 AM CEST, Key ID
e7898ae070771ff3
Packager : Götz Waschk <waschk@mandriva.org>
URL : http://ffmpeg.sourceforge.net
Summary : Header files for the ffmpeg codec library
Description :
ffmpeg is a hyper fast realtime audio/video encoder, a streaming server
and a generic audio and video file converter.
It can grab from a standard Video4Linux video source and convert it into
several file formats based on DCT/motion compensation encoding. Sound is
compressed in MPEG audio layer 2 or using an AC3 compatible stream.
#303: new ffmpeg includes layout
------------------------+---------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
------------------------+---------------------------------------------------
Comment (by glynn):
Replying to [comment:4 neteler]:
> On Mandriva, use
>
{{{
./configure
...
--with-ffmpeg --with-ffmpeg-includes="/usr/include/libav*
/usr/include/libpostproc /usr/include/libswscale"
}}}
>
> Then it is detected.
FWIW, I don't need libpostproc on Gentoo; just the 3 libav* directories
and libswscale.
#303: new ffmpeg includes layout
------------------------+---------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
------------------------+---------------------------------------------------
Comment (by kyngchaos):
Ah, and even though the test succeeds without it (just like the test with
the older ffmpeg succedds without libz), the newer ffmpeg also needs
libbz2 during compilation.
#303: new ffmpeg includes layout
------------------------+---------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
------------------------+---------------------------------------------------
Comment (by kyngchaos):
Ugh, a nasty new wrinkle on the OSX side. Due to the -mdynamic-no-pic
flag now used in a default ffmpeg build on OSX, dynamic libraries that
link the ffmpeg static libs must use the "-read_only_relocs suppress"
flag. Programs don't need this flag (I don't know what would happen if
they did, but it looks like nviz only links the ogsf library and not
ffmpeg directly).
Even with this flag, ogsf spits out a zillion warnings about "codegen" in
the ffmpeg libs. But at least it links.
I kind of wonder if the ffmpeg developers intend ffmpeg libs to be linked
only to programs, and not to other libraries. From the gcc docs:
{{{
-mdynamic-no-pic
On Darwin and Mac OS X systems, compile code so that it is not
relocatable, but that its external references are relocatable. The
resulting code is suitable for applications, but not shared
libraries.
}}}
#303: new ffmpeg includes layout
------------------------+---------------------------------------------------
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Compiling | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
------------------------+---------------------------------------------------
Changes (by kyngchaos):
* priority: major => normal
* component: Raster => Compiling
* milestone: 6.4.0 => 6.5.0
Comment:
A couple followup notes:
- March 2009 a source package of ffmpeg was released, so the new layout
should be much more common now since system
packagers will more likely include a defined release. I think we should
support the new layout directly. Specifying ''all'' the lib* folders does
work, but it's annoying and not obvious to users who simply want to build
GRASS.
- For the static lib linking and configure test problems, the simple
solution is to use shared libraries. It works, though there's a little
more bundling to do in the packaging stage (though that's not a problem
for the average user).