Opened 14 years ago

Closed 10 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 by glynn, 14 years ago

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.

in reply to:  1 comment:2 by kyngchaos, 14 years ago

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 by neteler, 14 years ago

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 by neteler, 14 years ago

On Mandriva, use

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

Then it is detected.

in reply to:  4 comment:5 by glynn, 14 years ago

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 by neteler, 14 years ago

Can we close this?

comment:7 by kyngchaos, 14 years ago

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 by kyngchaos, 14 years ago

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 by kyngchaos, 14 years ago

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 by kyngchaos, 13 years ago

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 by hamish, 10 years ago

see also #1353 and #1423

comment:12 by hamish, 10 years ago

Keywords: ffmpeg added

comment:13 by hamish, 10 years ago

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.