Opened 13 years ago

Closed 9 years ago

#303 closed defect (fixed)

new ffmpeg includes layout

Reported by: kyngchaos Owned by: grass-dev@…
Priority: normal Milestone: 6.5.0
Component: Compiling Version: svn-develbranch6
Keywords: ffmpeg Cc:
CPU: All Platform: All


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:


This causes configure to fail to find ffmpeg, and will likely cause #include errors in compilation.

Change History (13)

comment:1 Changed 13 years ago by glynn

Do they use the directories as part of the header name, e.g. <libavutil/avutil.h>?

If they don't, you should just be able to use something like:

--with-ffmpeg-includes='/usr/include/ffmpeg /usr/include/libavcode /usr/include/libavformat /usr/include/libavutil'

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.

comment:2 in reply to:  1 Changed 13 years ago by kyngchaos

Looks like: # include "libavutil/avutil.h" (not <>) when crossing libraries, otherwise it's (ie from avformat.h) #include "avio.h".

This change appeared way back on Feb 25.

--with-ffmpeg-includes="/usr/local/include /usr/local/include/libavcodec /usr/local/include/libavformat /usr/local/include/libavutil /usr/local/include/libavdevice /usr/local/include/libswscale"

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.

comment:3 Changed 13 years ago by neteler

CPU: UnspecifiedAll
Platform: UnspecifiedAll

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

Install libffmpeg-devel if you want to compile apps with ffmpeg support.

So far I didn't manage to compile GRASS again with FFMPEG support.


comment:4 Changed 13 years ago by neteler

On Mandriva, use

  --with-ffmpeg --with-ffmpeg-includes="/usr/include/libav* /usr/include/libpostproc /usr/include/libswscale"

Then it is detected.

comment:5 in reply to:  4 Changed 13 years ago by glynn

Replying to neteler:

On Mandriva, use

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

comment:6 Changed 13 years ago by neteler

Can we close this?

comment:7 Changed 13 years ago by kyngchaos

Maybe it needs a different bug report, but now I get some symbols not found in the tests, when using a recent ffmpeg.

configure:11056: checking for avcodec_init in -lavcodec
configure:11073: gcc -o conftest -Os    -L/Users/Shared/unix/ffmpeg-leo/lib   conftest.c -lavcodec  -lavutil    1>&5
Undefined symbols:
  "_inflate", referenced from:
      _decode_frame in libavcodec.a(pngdec.o)
  "_inflateEnd", referenced from:
      _decode_frame in libavcodec.a(pngdec.o)
  "_inflateInit_", referenced from:
      _decode_frame in libavcodec.a(pngdec.o)
ld: symbol(s) not found

If I add -lz to the test, it works.

I don't know why the exact same test works without -lz when using an older ffmpeg build.

comment:8 Changed 13 years ago 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.

comment:9 Changed 13 years ago 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:

    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

comment:10 Changed 12 years ago by kyngchaos

Component: RasterCompiling
Priority: majornormal

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

comment:11 Changed 9 years ago by hamish

see also #1353 and #1423

comment:12 Changed 9 years ago by hamish

Keywords: ffmpeg added

comment:13 Changed 9 years ago by hamish

Resolution: fixed
Status: newclosed

no idea about the current state on MacOSX, but seems to be working on Linux in current devbr6 and trunk.

repopen if needed or continue in #1423.


Note: See TracTickets for help on using tickets.