This bug was encountered running on a P3 400 MHz with a Gentoo-Crypto-Kernel, no special/additional use flags where set. The "emerge kde" command stops when emerging cdrtools-1.11.29. The last error reported is: /usr/i686-pc-linux-gnu/bin/ld: cannot find -lscg I have reinstalled the system and even tried to rebuild all packages with "emerge -e world". The bug stayed the same. When I try to emerge cdrtools alone it still fails. I consider this a showstopper bug as kde depends on it and for most users that will be important.
could you post more of the error ?
which gcc?
According to "gcc -v": GCC 2.95.3 20010315 (release) What else informatin could be helpful and how can I report it best? Is there any "trigger" to tell portage to save a logfile when something goes wrong?
And btw, my PC is a P2 400 not a P3 400 as originally reported. But I figure that shouldn't really be important.
i just emerge 1.11.29 and although a lot of errors went by complaining about missing header/make files, it still worked ... do this ... `emerge cdrtools >& cdrtools-buglog` then post that file, 'cdrtools-buglog' be sure to include the '>&' as that will capture all the output where as '>' only captures stdin
Created attachment 3077 [details] Logfile from Portage I posted the logfile of a failed attempt to emerge cdrtools.
Created attachment 3079 [details] cdrtools-1.11.29.ebuild just replace /usr/portage/app-cdr/cdrtools/cdrtools-1.11.29.ebuild with this file, then run emerge again and see if it works ... basically i change emake -> make
In file included from scsihack.c:125: scsi-linux-sg.c: In function `sg_settimeout': scsi-linux-sg.c:985: `CONFIG_JIFFIES' undeclared (first use in this function) scsi-linux-sg.c:985: (Each undeclared identifier is reported only once scsi-linux-sg.c:985: for each function it appears in.) make[2]: *** [OBJ/x86-linux-cc/scsihack.o] Error 1 there is the source of your problem ... the weird thing is, when i compiled mine, nowhere in the configured src tree did i have 'CONFIG_JIFFIES' or 'JIFF'
I've masked it out for now.
Hi SpanKY! I just tried to emerge cdrtools with your "replacement" ebuild. It still does not work (same error)...
Seemant Kulleen: I can see that the ebuild is now included in the package.mask file. I also did a env-update but It still tries to compile it when I want to emerge kde, it gives no warning (not sure if it should) when I try to emerge it specifically and it does not show up as masked when I do "emerge -s cdr". Am I doing something wrong?
I just found another location where jiffies are mentioned, the Kernel configuration: When one runs "make menuconfig", go into 'Processor type and features' -> '(1000) Set jiffies for i386 (HZ) (NEW)'. However there is no explanation given to what that is and what it does or how to turn it off.
I overlooked that while cdrtools-1.11.29 is masked (after I logged off and on again) cdrtools 1.11.28 is not and it fails with the exact same error when emerging it. Damn jiffies!
I have a gut feeling that this bug is actually about the kernel sources/headers. Since Drobbins seems to maintain the crypto-sources package, I'm adding him to the discussion. Here's what I found in a CVS log for crypto-sources-2.4.19-r7: New -r7 crypto and gentoo sources with a little JIFFIES compile fix... (See http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/sys-kernel/crypto-sources/crypto-sources-2.4.19-r7.ebuild). Proteus, what version of crypto-sources package do you have installed?
I am indeed using the crypto-sources 2.4.19-r7. Now I guess the fastest workaround is to switch to gentoo-sources or vanilla. But can anyone fix the bug or explain the jiffies to me?
unmasking the .29 ebuild
Proteus: AFAIK, jiffies are time units used in the kernel. Could you try installing a different kernel source tree and attempt compiling the cdrtools package with them? Note that you would not have to compile and install a different kernel, and you can keep the crypto kernel sources as well. Just emerge gentoo-sources, update /usr/src/linux to point to the new kernel, and try to emerge cdrtools. Thanks.
Well, I deleted Gentoo, repartinioned everything and installed from scratch. (It took a while for me...) Now it works! (But I got other compile errors now - i.e. mysql-DBI... Strange!!)
*** Bug 10809 has been marked as a duplicate of this bug. ***
I had this problem with cdrtools-1.11.39 exactly as the summary states. The problem had nothing to do with a crypto kernel, because I don't use the crypto kernel. The problem was that I had the linux symlink in /usr/src pointing to the gentoo sources instead of the vanilla sources and I use vanilla. I've seen other bugs related to this, it would nice if gentoo did more to manage the kernel symlinks.
actually its policy to not mess with /usr/src/linux its better to let users manage their kernels than force stuff onto them
*** Bug 18547 has been marked as a duplicate of this bug. ***
I can't get it to work. It just says: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lscg collect2: ld returned 1 exit status make[1]: *** [OBJ/x86-linux-cc/scgcheck] Error 1 make[1]: Leaving directory `/var/tmp/portage/cdrtools-2.01_alpha20/work/cdrtools-2.01/scgcheck' make: *** [all] Error 2 I have kernel 2.4.23-pre6aa3 I seems that it has something to do with kernel sources?
Hi, I'm getting the "cannot find -lscg" when emergeing cdrdao like as in this bug: http://bugs.gentoo.org/show_bug.cgi?id=30798 It directed me here, but there isn't a real fix that I can see.
