Summary: | eselect-compiler does not remove wrappers that don't exist in the switched-to compiler (was dev-java/gnu-classpath-0.90 requires fastjar (i.e. gcc-4.0 or 4.1, not <4.0 or >=4.2)) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kevin F. Quinn (RETIRED) <kevquinn> |
Component: | [OLD] Development | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 1i5t5.duncan, andre, Bjoern.Thorwirth, felix-gentoo, gothiger, java, jdaluz, johnherdy, jrmalaq, kmeagher, m.labhard, mmw, pesa, portage, rose, shellsage, sprockhoevel, stefan, zlin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
log of emerge
config.log attached |
Description
Kevin F. Quinn (RETIRED)
2006-06-05 16:06:10 UTC
Created attachment 88483 [details]
log of emerge
Just to confirm; fastjar has indeed been dropped from gcc in 4.2.0. See http://gcc.gnu.org/java/index.html#news item dated April 4, 2006. Ultimately adding fastjar http://savannah.nongnu.org/projects/fastjar as a separate package and DEPEND on it seems most sensible, but it's a little early yet ;) I just made an initial package of fastjar using the sources at the savannah project page (we previously had one that yanked it out of gcc's tarball). It doesn't seem like there's an official release yet, but it looks like I'm going to get commit access and that jazz, so hopefully we can make seomething happen. >As summary, really. Build depends on fastjar, which is only available in
>gcc-4.0 and 4.1 (it might be gone in 4.2, not sure, but my alpha doesn't have
>it).
It shouldn't need fastjar because it uses app-arch/zip for the compressing. You should have that installed as it is a dependency. Works fine here without any jar programs installed.
I remember the new eselect-compiler puts the wrappers in /usr/bin. I think you got hit by this: checking for fastjar... /usr/bin/fastjar You have the wrapper there and the build process detects it. This leads to problems. I have added --disable-fastjar to workaround this and to lower the used combination of build tools but this is not an actual bug. You should rm the wrappers. Well --without-fastjar does not seem to work so I can't disable the detection atm. 'tis an eselect-compiler issue - reopening... to re-assign. Jeremy, eselect-compiler should remove wrappers that are not relevant, I think: # eselect compiler set i686-pc-linux-gnu-3.4.6/hardened Successfully set compiler for i686-pc-linux-gnu to i686-pc-linux-gnu-3.4.6/hardened. # which fastjar which: no fastjar in (/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/opt/ghc/bin:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin) # eselect compiler set i686-pc-linux-gnu-4.0.3/vanilla Successfully set compiler for i686-pc-linux-gnu to i686-pc-linux-gnu-4.0.3/vanilla. # which fastjar /usr/bin/fastjar c1358217 ~ # eselect compiler set i686-pc-linux-gnu-3.4.6/hardened Successfully set compiler for i686-pc-linux-gnu to i686-pc-linux-gnu-3.4.6/hardened. # which fastjar /usr/bin/fastjar # fastjar gcc-config error: fastjar wrapper: Unable to determine executable. CTARGET=i686-pc-linux-gnu exec=fastjar Got it - in do_set() (line 383 of svn 271 of compiler.eselect.in): set_v="COMPILER_CONFIG_SET_${COMPILER_CONFIG_DEFAULT_CTARGET}" should be set_v="COMPILER_CONFIG_SET_${COMPILER_CONFIG_DEFAULT_CTARGET//[-.]/_}" (based other set_v assignments) Thanks Kevin. *** Bug 136363 has been marked as a duplicate of this bug. *** This is fixed in rc2-r1. Ummm... Could you update the eselect-compiler changelog to reflect this? Neither my sync of a couple hours ago nor viewCVS seem to think the changelog has been touched in 43 hours, while viewCVS says this change happened 10 hours ago. (I've been paying close attention to eselect-compiler since I've been one of the testers, and an -rX bump with no changelog gets me wondering what's up!) Duncan Whoops. Thanks Duncan. *** Bug 153873 has been marked as a duplicate of this bug. *** *** Bug 158168 has been marked as a duplicate of this bug. *** *** Bug 172104 has been marked as a duplicate of this bug. *** *** Bug 177282 has been marked as a duplicate of this bug. *** *** Bug 183285 has been marked as a duplicate of this bug. *** *** Bug 183285 has been marked as a duplicate of this bug. *** *** Bug 185754 has been marked as a duplicate of this bug. *** hmm, my bug has been marked as a duplicate iof this one, so here we go. i am unable to recompile sandbox on my ~amd64. config.log attached. on the screen while compiling i see this: --libdir=/usr/lib32 and this: * Configuring sandbox for ABI=x86... doesnt look right to me? Created attachment 125251 [details]
config.log attached
*** Bug 185754 has been marked as a duplicate of this bug. *** *** Bug 186058 has been marked as a duplicate of this bug. *** *** Bug 186238 has been marked as a duplicate of this bug. *** *** Bug 187456 has been marked as a duplicate of this bug. *** Delete any symlinks in /usr/bin related to gcc, g++, c++, etc... if if it references i686 and not x86_64. I had the same problem. Apparently eselect-compiler left some nasty things behind, that gcc-config could not fix. You can run gcc-config until you are blue in the face and it wont fix it... Deleting the old symlinks is what worked. (In reply to comment #22) > hmm, my bug has been marked as a duplicate iof this one, so here we go. > i am unable to recompile sandbox on my ~amd64. config.log attached. > > on the screen while compiling i see this: > --libdir=/usr/lib32 > and this: > * Configuring sandbox for ABI=x86... > > doesnt look right to me? > *** Bug 188648 has been marked as a duplicate of this bug. *** *** Bug 190879 has been marked as a duplicate of this bug. *** *** Bug 196212 has been marked as a duplicate of this bug. *** Just FYI for future searchers... I went round in circles for a day, following the dupes here. Noone has referred (either as a dupe, or as further info) to the bug that finally sorted this out for me: http://bugs.gentoo.org/show_bug.cgi?id=133209 #25 seems to fix *all* the crud left behind by eselect-compiler. *** Bug 196448 has been marked as a duplicate of this bug. *** *** Bug 197140 has been marked as a duplicate of this bug. *** (In reply to comment #34) > *** Bug 197140 has been marked as a duplicate of this bug. *** Wow, I'm impressed you were able to find this connection based om my decription... Anyway, what I should do now is "Delete any symlinks in /usr/bin related to gcc, g++, c++, etc... if if it references i686 and not x86_64. I had the same problem. Apparently eselect-compiler left some nasty things behind, that gcc-config could not fix. You can run gcc-config until you are blue in the face and it wont fix it... Deleting the old symlinks is what worked." as stated in comment #28? My bug was duplicated wrongly, I think. I found the solution out myself using the link to the better bug as indicated in comment #32... *** Bug 199660 has been marked as a duplicate of this bug. *** *** Bug 200429 has been marked as a duplicate of this bug. *** *** Bug 201350 has been marked as a duplicate of this bug. *** (In reply to comment #39) > *** Bug 201350 has been marked as a duplicate of this bug. *** > Well I solved the problem and I think my bug report isn't related to this bug. The problem was with the crossdev toolchain installed on my system, I just removed it using : crossdev -C i686-pc-linux-gnu After tried that, sandbox compilation success. *** Bug 201414 has been marked as a duplicate of this bug. *** |