Hi All,
Here is release 0.3.8: http://people.atrpms.net/~hdegoede/libv4l-0.3.8.tar.gz
This release has the following changes (some small tweaks left and right for more to the spec behavior, none of this fixes any known bugs).
libv4l-0.3.8 ------------ * work around wrong REQUEST_BUFFERS ioctl return code from certain drivers * add pkg-config (.pc) files for easier detection if libv4l is available * check capabilities for streaming, if the driver cannot do streaming don't insert ourselves between the application and the driver * intercept get capabilites and report read capability (which we always offer) * query buffer: indicate the mapping state of our (fake) buffer in the flags
Regards,
Hans
Hi,
On Wed, Jul 30, 2008 at 12:01:04AM +0200, Hans de Goede wrote:
Here is release 0.3.8:
During Debian packaging I've created four patches. Maybe you want to apply them to your sources:
add_pkgconfig_requires.diff:
Linking statically requires to specify all dependent libs. This patch writes the Required: field into the pc files.
build_static_lib.diff
Sometimes it is useful to build a static lib. With this patch you can type (after a make clean) make LINKTYPE=static to get a static lib build.
I wanted the patch be as less intrusive as possible. The downside of that approach are the 'shared' object file names for PIC and non-PIC code. So you need always a 'clean' between two different lib types.
Using libtool would be an alternative, or maybe storing the non-PIC objects somewhere else or renaming them ...
sanitize_includes.diff
The Debian packaging environment sometimes specifies CPPFLAGS at the command line. This overrides the ../include and the build fails.
The linux includepath seems to be useless for the majority of the lib users.
remove_hardcoded_gcc.diff -p0
I think there is no need to (semi)hardcode gcc as the compiler/linker. The system defaults should be working fine.
Cheers, Gregor
PS: My current packaging progress is attached to http://bugs.debian.org/488117
On 23:49 Fri 01 Aug 2008, Gregor Jasny wrote:
Hi,
On Wed, Jul 30, 2008 at 12:01:04AM +0200, Hans de Goede wrote:
Here is release 0.3.8:
During Debian packaging I've created four patches. Maybe you want to apply them to your sources:
PS: My current packaging progress is attached to http://bugs.debian.org/488117
Thanks for doing this work.
Hans and I are keeping track of progress of libv4l acceptance upstream and in distros via a Wiki page. If you fix up any applications please note your progress here to avoid duplicating work:
http://linuxtv.org/v4lwiki/index.php/Libv4l_Progress
Cheers,
Brandon
Gregor Jasny wrote:
Hi,
On Wed, Jul 30, 2008 at 12:01:04AM +0200, Hans de Goede wrote:
Here is release 0.3.8:
During Debian packaging I've created four patches. Maybe you want to apply them to your sources:
add_pkgconfig_requires.diff:
Linking statically requires to specify all dependent libs. This patch writes the Required: field into the pc files.
Applied to my tree.
build_static_lib.diff
Sometimes it is useful to build a static lib. With this patch you can type (after a make clean) make LINKTYPE=static to get a static lib build.
Applied to my tree.
I wanted the patch be as less intrusive as possible. The downside of that approach are the 'shared' object file names for PIC and non-PIC code. So you need always a 'clean' between two different lib types.
I think that limitation is fine (static libs should all die).
Using libtool would be an alternative, or maybe storing the non-PIC objects somewhere else or renaming them ...
No libtool please since this lib is Linux only, it really is not worth the pain.
sanitize_includes.diff
The Debian packaging environment sometimes specifies CPPFLAGS at the command line. This overrides the ../include and the build fails.
Nack,
With your patch if you override CPPFLAGS, as you say you do, -fPIC no longer gets passed as when CPPFLAGS is overridden the += also will not touch it.
The linux includepath seems to be useless for the majority of the lib users.
True, but libv4l is part of the v4l-dvb mercurial tree and there it usefull, so please keep it.
I'll gladly accept a patch which allows you to override CPPFLAGS, while keeping the include path and -fPIC intact.
remove_hardcoded_gcc.diff -p0
I think there is no need to (semi)hardcode gcc as the compiler/linker. The system defaults should be working fine.
Applied.
Regards,
Hans
-
Brandon Philips -
Gregor Jasny -
Hans de Goede