Bugzilla Bug 124995

Updated the ebuild with the patch in.

Created an attachment (id=81329) [details]
libdc1394-2.0.0_pre5-r2.ebuild

Created an attachment (id=81330) [details]
clk_tck_to_clocks_per_sec_grab_partial_image.c.patch

You're probably gonna say something like Marcelo Goes did - just to make sure
please read http://bugs.gentoo.org/show_bug.cgi?id=124991 post 3 and 4.

This patch works with versions as old as libdc1394-1.0.0 (just had to regress
for ffmpeg).

Created an attachment (id=81341) [details]
libdc1394-1.0.0-r1.ebuild

The patch needs to detect if CLK_TCK is present if not use CLOCKS_PER_SEC in
order to be backwards compatible - this is beyond my c/c++ knowledge - flame
passing moment!

*** Bug 126040 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> The patch needs to detect if CLK_TCK is present if not use CLOCKS_PER_SEC in
> order to be backwards compatible - this is beyond my c/c++ knowledge - flame
> passing moment!
> 

No. You don't need to detect if CLK_TCK is present in C++, just use the
'has_version' function in the ebuild. I think it would look something like
this, so correct me if I am wrong:
if has_version ">=sys-libs/glibc-2.4"; then
        epatch some-patch-name.patch
fi

I only know a little bit about has_version, but I think that is correct. All I
can say is test it. ;)

*** Bug 126598 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> No. You don't need to detect if CLK_TCK is present in C++, just use the
> 'has_version' function in the ebuild. I think it would look something like
> this, so correct me if I am wrong:
> if has_version ">=sys-libs/glibc-2.4"; then
>         epatch some-patch-name.patch
> fi
> 
> I only know a little bit about has_version, but I think that is correct. All I
> can say is test it. ;)
> 

I confirm that it works

    if has_version ">=sys-libs/glibc-2.4"; then
        epatch ${FILESDIR}/clk_tck_to_clocks_per_sec.patch
    fi

if has_version ">=sys-libs/glibc-2.3.9"; then
        epatch ${FILESDIR}/clk_tck_to_clocks_per_sec.patch
fi

Would be better.

hi all, sorry for the late reply. 

I had submitted a patch against 2.0.0pre6 upstream about the CLK_TCK issue.  I
don't like the patch in its current form, as I'd rather have a solution that'll
work throughout (and consequently, one we can simply push upstream).

vapier, your thoughts?

The bug is present in libdc1394-1.2.1 as well (cannot compile the example
subdirectory. Couldn't that be disabled?).

media-video/ffmpeg-0.4.9_p20060302 requires libdc1394-1.0.1 but "emerge -u"
tries the version 2.0.0_pre6 series which does not have the problem. So I
modified the ffmpegs's ebuild not to require the version libdc1394-1* anymore.

So, should 1.2.1 be provided along with the patch or shall we try rather the
version 2 series on ~x86?

Portage 2.1_pre7-r4 (default-linux/x86/2005.0, gcc-3.4.6, glibc-2.4-r1,
2.6.16-rc5 i686)
=================================================================
System uname: 2.6.16-rc5 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.3.4-r1, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config
/usr/spool/PBS /var/bind /var/qmail/alias /var/qmail/control /var/spool/PBS"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 FFmpeg X Xaw3d a52 aac aalib acpi alsa amr apache2 apm arts ati avi
berkdb bitmap-fonts bonobo caca cdparanoia cdr cpudetection crypt cscope ctype
cups dba dga directfb divx divx5 divx5linux dri dts dv dvb dvd dvdr dvdread eds
emacs emacs-w3 emboss encode esd ethereal evo f77 faad faad2 fam fame fbcon
ffmpeg flash foomaticdb fortran fvwm fvwm2 gb gd gdbm ggi gif gphoto2 gpm
gstreamer gtk gtk2 gtkhtml i8x0 icc iconv ieee1394 ifc imagemagick imlib imlib2
inifile innodb ipv6 isdnlog ithreads java jpeg lcms leim libcaca libg++ libwww
lirc live lzo mad matroska mcal mesa mhash mikmod ming mmx mmx2 mmxext motif
mozilla mp3 mpeg mule musepack mysql ncurses network nls nptl nptlonly ogg
oggvorbis opengl oss pam pcre pda pdflib perl plotutils plugin png ppds pppd
pthread pthreads python qt qtx quicktime readline rtc samba scanner scp sdl
server session slp spell sse sse2 ssl stroke tcltk tcpd tetex theora thread
threads tiff truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vorbis
win32 win32codecs winvidix wmf x264 xanim xml xml2 xmms xosd xv xvid xvmc zeo
zlib elibc_glibc kernel_linux userland_GNU video_cards_ati"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS, MAKEOPTS

*** Bug 130110 has been marked as a duplicate of this bug. ***

ok, the fix here is really quite simple:
#ifndef CLOCKS_PER_SEC
# define CLOCKS_PER_SEC CLK_TCK
#endif
elapsed_time = (float)(times(&tms_buf) - start_time) / CLOCKS_PER_SEC;

CLK_TCK is the obsolete name so everything should be using CLOCKS_PER_SEC

Created an attachment (id=85310) [details]
SpanKY's CLK_TCK patch

This is still broken, and ffmpeg won't build against the newer libdc1394 (at
least not easily).  Since SpanKY's CLK_TCK patch fixes the current stable
(which is broken, at least for some) why not just apply it?

The `dsniff` ebuild has something like this in it:

if has_version '>=sys-libs/glibc-2.4' ; then
    append-flags -DCLK_TCK=CLOCKS_PER_SEC
fi

Maybe it's a better solution.

I am adding that to my make.conf to avoid such errors in future - as this is
now a month and a half on since the original bug thread was posted I expect
such fixes not to appear in Gentoo for some time...

wow, I'm ashamed of myself for sleeping on the job on this.  Beech, you have
every reason to be frustrated with me.  I can only humbly apologise for my
delay.  I'll fix the CLK_TCK issue immediately in all the libdc's.

What I am stuck on, is that I can not slot libdc1394 without hacking everything
that depends on libdc1394-1 or -2 exclusively.  I'm open to suggestions on
that.

As a favour, please e-me if you make a comment (yes, I'm supposed to get bugz
mail but it gets lost in the shuffle these days).  I honestly didn't even check
this report until a user emailed me last night with a nudge.  Wrong behaviour
on my part, though, I do realise that.


Anyway, plan of action:

1. Immediate term, apply the CLK_TCK fix to all libdc1394 ebuilds in the tree
2. Figure out a solution for things which depend on specific major releases of
the library

Oh yes, the reason thqat I can not slot it is that both libraries install the
same headers and libs into the same locations. So, assuming we install into
/usr/include/libdc1394-1 and append something to .a .la and .so files to
indicate the -1ness, we then have to go back to things which depend on
libdc1394-1 and inform them of the new header file locations and library names.
 If this is what will fix everything then I'm willing to do it, but I'll need
y'all's help to figure out what those things are.

Beech, are you on IRC at all?  If so please come chat with me on freenode (I'm
seemant on there).

this change is in 1.0.0-r1, 1.2.1 and 2.0.0_pre6-r2.  Other versions of the
ebuild are gone entirely, for reasons in bug #117201