Project

General

Profile

Actions

Feature #53

open

Modified Makefile (INCLUDES and LIBS) for FFMPEG

Added by mnival almost 16 years ago. Updated almost 16 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
01/07/2009
Due date:
% Done:

0%

Estimated time:

Description

FFMPEG is not necessarily stored in /usr/local/include/ffmpeg/ next if we compile FFMPEG or when using the package of the distribution.

The amendment uses pkg-config.

If pkg-config is not present then the path remains FFMDIR stated at the beginning of the Makefile.


Files

Actions #1

Updated by SPAM almost 16 years ago

  • Assignee set to SPAM

The patch removes -L$(FFMDIR)/libavcodec from LIBS when pkg-config does not provide something useful. I guess that's not intentional?

Actions #2

Updated by mnival almost 16 years ago

The libs are not in stores usr/local/include/ffmpeg/ ?

The file ld.so.conf that must be filled in correctly and libvdr-dxr3.so should be constructed ?

Actions #3

Updated by SPAM almost 16 years ago

Hmm, the defaults are not in a very good shape indeed. I think we should just clean them up to unconditionally use pkg-config.

I don't understand what you mean by "and libvdr-dxr3.so should be constructed"? Is this related to the addition of -L. in the patch? I don't see why that would be needed.

Actions #4

Updated by mnival almost 16 years ago

Sorry, I was not very clear.

Why not use pkg-config, he is there to prevent changes to the Makefile by the user ?

The addition of -L. is a mistake that I forgot to delete.

I fixed the patch because it did not work if pkg-config was not found. I also added FFMLIB for to have the option -L$(FFMLIB) -libavcodec to the compile.

Is it better ?

Actions #5

Updated by SPAM almost 16 years ago

  • Status changed from New to Resolved

I have nothing against pkg-config, on the contrary. The updated patch looks better but quite complicated for my taste, I committed a simplified version that always uses pkg-config by default: http://projects.vdr-developer.org/repositories/diff/plg-dxr3?rev=692099302d01b1b41884dcaed355601b45017691

Actions #6

Updated by mnival almost 16 years ago

The command pkg-config -cflags-only-I libavcodec returned under Debian :
-I/usr/include/ffmpeg

Content of /usr/include/ffmpeg/
ls /usr/include/ffmpeg/
adler32.h avstring.h base64.h crc.h fifo.h log.h mathematics.h mem.h random.h sha1.h
avcodec.h avutil.h common.h dsputil.h intfloat_readwrite.h lzo.h md5.h opt.h rational.h

It does not find : #include <libavcodec/avcodec.h>

A new patch to try to respond positively to different distributions Linux without too complicated.

Actions #7

Updated by SPAM almost 16 years ago

It seems that Debian is shipping an old version of FFmpeg. Your patch would break with current FFmpeg versions, where for example avcodec.h has '#include "libavutil/avutil.h"' which means if only /usr(/local)/include/ffmpeg/libavcodec is in the include path, the build will break. It would also fail if "pkg-config --cflags-only-I libavcodec" returns more than one -I option. Patches should be constructed so that they work without special cases with current FFmpeg versions, and support for older ones is added by adding some special cases if necessary - your patch does the opposite (tries to make current FFmpeg versions an exception). I'm afraid users of old FFmpeg versions will just need to upgrade their FFmpeg or change Makefile and dxr3ffmpeg.h.

For reference, here's what my ffmpeg-0.4.9-0.48.20080908.fc9.x86_64 (Fedora/RPM Fusion) has (and I suppose current versions as well):

$ pkg-config --cflags-only-I libavcodec
-I/usr/include/ffmpeg

$ find /usr/include/ffmpeg
/usr/include/ffmpeg                                   
/usr/include/ffmpeg/libavcodec
/usr/include/ffmpeg/libavcodec/opt.h
/usr/include/ffmpeg/libavcodec/avcodec.h
/usr/include/ffmpeg/libavdevice
/usr/include/ffmpeg/libavdevice/avdevice.h
/usr/include/ffmpeg/libavutil
/usr/include/ffmpeg/libavutil/avutil.h
/usr/include/ffmpeg/libavutil/base64.h
/usr/include/ffmpeg/libavutil/adler32.h
/usr/include/ffmpeg/libavutil/random.h
/usr/include/ffmpeg/libavutil/log.h
/usr/include/ffmpeg/libavutil/common.h
/usr/include/ffmpeg/libavutil/sha1.h
/usr/include/ffmpeg/libavutil/mem.h
/usr/include/ffmpeg/libavutil/crc.h
/usr/include/ffmpeg/libavutil/intfloat_readwrite.h
/usr/include/ffmpeg/libavutil/mathematics.h
/usr/include/ffmpeg/libavutil/lzo.h
/usr/include/ffmpeg/libavutil/avstring.h
/usr/include/ffmpeg/libavutil/fifo.h
/usr/include/ffmpeg/libavutil/rational.h
/usr/include/ffmpeg/libavutil/md5.h
/usr/include/ffmpeg/libavfilter
/usr/include/ffmpeg/libavfilter/avfilter.h
/usr/include/ffmpeg/libavformat
/usr/include/ffmpeg/libavformat/avio.h
/usr/include/ffmpeg/libavformat/rtsp.h
/usr/include/ffmpeg/libavformat/avformat.h
/usr/include/ffmpeg/libavformat/rtspcodes.h
/usr/include/ffmpeg/libpostproc
/usr/include/ffmpeg/libpostproc/postprocess.h
/usr/include/ffmpeg/libswscale
/usr/include/ffmpeg/libswscale/swscale.h
/usr/include/ffmpeg/libswscale/rgb2rgb.h

$ grep '#include' /usr/include/ffmpeg/libavcodec/avcodec.h
#include "libavutil/avutil.h" 
Actions #8

Updated by mnival almost 16 years ago

Sorry, my assessment was not correct.

Your approach is better and in most distributions.

Thanks

Actions #9

Updated by SPAM almost 16 years ago

No problem, thanks for raising the issue and the feedback.

Actions

Also available in: Atom PDF