Summary: | java.eclass and java-vm-2.eclass does not always match the correct arch | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew Schultz <mattsch> |
Component: | Eclasses | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Matthew Schultz
2006-12-29 19:31:42 UTC
The fallback uname call makes no sense to me, because $ARCH should be always fine as set by profiles, unless somebody overrides it with bogus in make.conf, in which case it should better die. (In reply to comment #1) > The fallback uname call makes no sense to me, because $ARCH should be always > fine as set by profiles, unless somebody overrides it with bogus in make.conf, > in which case it should better die. > Agreed. (In reply to comment #2) > (In reply to comment #1) > > The fallback uname call makes no sense to me, because $ARCH should be always > > fine as set by profiles, unless somebody overrides it with bogus in make.conf, > > in which case it should better die. > > > > Agreed. > Using uname also doesn't work in a cross compiling scenario. So it should just substitute x86 to i386 (that's how the dirs are named) and probably x86-fbsd -> i386? (In reply to comment #4) > So it should just substitute x86 to i386 (that's how the dirs are named) and > probably x86-fbsd -> i386? > Something like that yes. I've now rewritten the function so that it is ABI-aware and doesn't generally suck. :) |