Bugzilla Bug 124991

New ebuild and patch to resolve the issue.

Created an attachment (id=81324) [edit]
scanlogd-2.2.5-r1.ebuild

Created an attachment (id=81325) [edit]
clk_tck_to_clocks_per_sec_params.h.patch

Hi,

I am not familiar with this issue, can you point out why this modification is
necessary? It does compile for me as it is with gcc-4.1.

I also recommend sending this patch to upstream so that they can check it out.

Cheers,
Marcelo

From the forum link:

metalshark wrote:
Just for the record - the issues I get for the official ebuild when compiling
programs all mention CLK_TCK - for instance:

Code:
grab_partial_image.c: In function 

From the forum link:

metalshark wrote:
Just for the record - the issues I get for the official ebuild when compiling
programs all mention CLK_TCK - for instance:

Code:
grab_partial_image.c: In function ‘main’:
grab_partial_image.c:239: error: ‘CLK_TCK’ undeclared (first use in this
function)
grab_partial_image.c:239: error: (Each undeclared identifier is reported only
once
grab_partial_image.c:239: error: for each function it appears in.)
make[2]: *** [grab_partial_image.o] Error 1

media-libs/libdc1394-2.0.0_pre5-r1


I use ntp-client so the clock is correct (even phoned 123 - the talking clock -
just to check), have no idea what on earth it's on about though, CLK_TCK?!?


You need to edit the file that CLK_TCK is in and change that to CLOCKS_PER_SEC

Then do: FEATUERS="keepwork" emerge {packagename}
or write a patch for it. CLK_TCK has been obsoleted by the C++ specifications,
so even on M$, you need to change that. :P Just for reference.

-------------------------------------------------------------------------------

The params.h in scanlogd uses CLK_TCK - I've just edited it to use
ClOCKS_PER_SEC

I cannot find ANYWHERE on www.openwall.com to submit this patch...

I just emerged both scanlogd and libdc1394 with gcc-4.1 and the same problem
did not crop up for me. :-(

From scanlogd.spec:
You may want to contact Solar Designer <solar at owl dot openwall dot com>
(entry is from mid-2004, so I don't know if upstream is alive, but it doesn't
hurt to try).

Thanks for the email address - just sent an email to Solar. Well I've looked up
CLK_TCK and is definitely is OBSOLETE - I am running bleeding edge and run into
issues early. This will affect everyone who moves to GLIBC 2.4 next week - so
unless it gets out soon expect nothing but duplicate bug reports. It's a GLIBC
2.3.9/2.4 issue - GCC-4.1.0 is a misnomer. Hence I added the WHOLE forum
posting...

I am yet to actually submit a valid fix to Gentoo (look at all my bug reports)
and get them added - yet help people on the forums and over Instant Messengers
by giving my overlays. Is there any point in submitting bugs to Gentoo - I just
hit a brick wall everytime and am loosing patience.

Please, relax. I did not say I was not going to add your fix - I just wanted to
know more about it. This is done because 1) I need to KNOW what I am doing, 2)
I need to TEST the fix and 3) LEARNING for similar bugs. Most developers are
not running bleeding edge glibc since we need stable systems to test everything
else. Because of this, I could not do 1 or 2.

We are more than willing to review and commit your fixes, but first we have to
know what on Earth they are meant to be fixing. Ok?

Ok, I thought the post from the forum was clear - and had pretty much come to
the end of my teather (actually I think I did). Everyone says to keep
submitting bugs - but when you are told they are non-existant or get fixed in
the same way by a dev days later (duplicated efforts) you start to loose your
nerve. I worked for many years on contributing to Slackware, where fixes are
accepted almost instantly and the people reviewing bugs seem to know more about
them than the contributors. This is just such a frustrating Gnome dev style
culture shock. Gnome devs have recently been questioned by Linus about being
"interface nazis" but I think what he was on about more was the development
practice. I only find this style of bug rejection within Gentoo/Gnome - not
Slackware/KDE - and I for one REALLY think something needs done about it.
Gentoo is the best distribution for all my varied systems to date - but the
contribution system really knows how to wind me up.

The irony with the GLIBC statement is that both the CVS GLIBC is very stable at
the minute - it's soon going to be 2.4 - nxsty is having to maintain the GLIBC
overlay and is doing a great job.

I do not maintain glibc, I do not run glibc from cvs and quite frankly I am
sorry I took an interest in this bug so that you can keep insulting me because
I asked you what the problem was. You are your own brickwall.

glibc from cvs is not part of Gentoo and therefore not supported. You did a
good job at making me not care, too. Reopen when glibc-2.4 hits Portage.

Also, I recommend you stop reporting bugs about software that is not in the
tree altogether - it will save a lot of frustation from your side and ours.

Deal.

This patch (more like hack) is flawed as it breaks backwards compatiblity.
Solar informed me aswell.

It was never a direct attack against Marcelo Goes.

I was the one lacking information.

Openwall are working on this issue so expect problems to be resolved upstream
instead (as originally adviced).

Created an attachment (id=81541) [edit]
scanlogd-2.2.6.ebuild

This is an -rc ebuild that compiles without patches - TEST RELEASE ONLY!!!
Don't think Solar would appreciate bug reports yet :p

PLEASE DON'T USE THE LATEST EBUILD!!!

Solar asked me to pull it as he wants to release the new Openwall software
first and the link to the tarball will die soon. Expect a new Openwall software
suite with GLIBC 2.4 support really soon - so all probs will be fixed upstream
- whoever is maintaining the ebuilds can always ask for help with version
bumped editions as soon as it's released - will just put them in an overlay and
link here if they aren't done by the time I get round to it.

Created an attachment (id=81910) [edit]
scanlogd-2.2.6.ebuild

Solar has now officially released the new version.

Valid ebuild and released upstream version.

Thanks, bumped in cvs.
There was no need for RESTRICT="primaryuri" in the ebuild AFAIK, so I removed
it.

Cheers!

RESTRICT="primaryuri"

justs removes GENTOO_MIRRORS from working (needed to get the new version from
the net.

It will propagate through our mirrors automagically. That restriction is for
stuff that we are not allowed to mirror.

Depends on how long your GENTOO_MIRRORS is - I use overlays form myself and
friends so my custom ebuilds often say it - you're right to remove it though.

Created an attachment (id=82254) [edit]
scanlogd-2.2.6-custom-cflags.patch

Allows the setting of C/LD FLAGS in the make.conf to propagate.

Created an attachment (id=82255) [edit]
scanlogd-2.2.6-r1.ebuild

An ebuild using the new patch with an IUSE="custom-cflags" and the patch
application in src_unpack with an if statement.

Addition of custom-cflags.

Created an attachment (id=82257) [edit]
scanlogd-2.2.6-pexit.patch

It shouldn't be returning pexit inside a void function.

Created an attachment (id=82258) [edit]
scanlogd-2.2.6-r2.ebuild

New ebuild with new patch.

Thanks, user CFLAGS/LDFLAGS are now respected. The other patch should be sent
upstream as it isn't Gentoo related.