New ebuild and patch to resolve the issue.
Created attachment 81324 [details] scanlogd-2.2.5-r1.ebuild
Created attachment 81325 [details, diff] 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 attachment 81541 [details] 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 attachment 81910 [details] 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 attachment 82254 [details, diff] scanlogd-2.2.6-custom-cflags.patch Allows the setting of C/LD FLAGS in the make.conf to propagate.
Created attachment 82255 [details] 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 attachment 82257 [details, diff] scanlogd-2.2.6-pexit.patch It shouldn't be returning pexit inside a void function.
Created attachment 82258 [details] 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.
