Summary: | java/openjdk6 fails to build | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | c.kworr | ||||
Component: | Individual Port(s) | Assignee: | freebsd-java (Nobody) <java> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | jkim | ||||
Priority: | Normal | ||||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
c.kworr
2011-12-01 08:50:09 UTC
Responsible Changed From-To: freebsd-ports-bugs->freebsd-java Over to maintainer (via the GNATS Auto Assign Tool) Ok, I found time to investigate it. Everything is about arch guessing. java/openjdk7 substitutes amd64 for x86_64 while java/openjdk6 doesn't. I just added missing bits from correspondent java/openjdk7 patch. Redports build: https://redports.org/buildarchive/20120307160255-45601 Patch attached. -- Sphinx of black quartz judge my vow. On Thursday 08 March 2012 02:50 am, Volodymyr Kostyrko wrote: > Ok, I found time to investigate it. > > Everything is about arch guessing. java/openjdk7 substitutes amd64 > for x86_64 while java/openjdk6 doesn't. I just added missing bits > from correspondent java/openjdk7 patch. > > Redports build: > https://redports.org/buildarchive/20120307160255-45601 > > Patch attached. Sorry but it doesn't make any sense. I guess you are patching this: ... # Platform settings specific to BSD ifeq ($(PLATFORM), bsd) OS_VERSION := $(shell uname -r) # Arch and OS name/version mach := $(shell uname -m) archExpr = case "$(mach)" in \ i[3-9]86) \ echo i586 \ ;; \ *) \ echo $(mach) \ ;; \ esac ARCH := $(shell $(archExpr) ) ARCH_FAMILY := $(ARCH) ... Unless "UNAME_m" environment variable is set, there is no way that this patch does anything at all. % uname -r 10.0-CURRENT % uname -m amd64 % env UNAME_m=x86_64 uname -m x86_64 I believe OpenJDK7 added it because some BSDs (e.g., DragonFlyBSD) return x86_64 for "uname -m". BTW, does "make DISABLE_MAKE_JOBS=yes" make any difference? Thanks, Jung-uk Kim > I believe OpenJDK7 added it because some BSDs (e.g., DragonFlyBSD) > return x86_64 for "uname -m". So why it ends up in our port and not in DragonFlyBSD's pkgsrc? > BTW, does "make DISABLE_MAKE_JOBS=yes" make any difference? Actually after successful build I can't reproduce this issue anymore. I seem to miss some bits of data so I'll try to retest in clean environment. -- Sphinx of black quartz judge my vow. On Monday 12 March 2012 11:26 am, Volodymyr Kostyrko wrote: > Jung-uk Kim wrote: > > On Thursday 08 March 2012 02:50 am, Volodymyr Kostyrko wrote: > >> Ok, I found time to investigate it. > >> > >> Everything is about arch guessing. java/openjdk7 substitutes > >> amd64 for x86_64 while java/openjdk6 doesn't. I just added > >> missing bits from correspondent java/openjdk7 patch. > >> > >> Redports build: > >> https://redports.org/buildarchive/20120307160255-45601 > >> > >> Patch attached. > > > > Sorry but it doesn't make any sense. I guess you are patching > > this: > > > > ... > > # Platform settings specific to BSD > > ifeq ($(PLATFORM), bsd) > > OS_VERSION := $(shell uname -r) > > # Arch and OS name/version > > mach := $(shell uname -m) > > archExpr = case "$(mach)" in \ > > i[3-9]86) \ > > echo i586 \ > > ;; \ > > *) \ > > echo $(mach) \ > > ;; \ > > esac > > ARCH := $(shell $(archExpr) ) > > ARCH_FAMILY := $(ARCH) > > ... > > > > Unless "UNAME_m" environment variable is set, there is no way > > that this patch does anything at all. > > > > % uname -r > > 10.0-CURRENT > > % uname -m > > amd64 > > % env UNAME_m=x86_64 uname -m > > x86_64 > > > > I believe OpenJDK7 added it because some BSDs (e.g., > > DragonFlyBSD) return x86_64 for "uname -m". > > So why it ends up in our port and not in DragonFlyBSD's pkgsrc? OpenJDK7 patchset is shared with other BSDs: https://wikis.oracle.com/display/OpenJDK/BSDPort OpenJDK6 patchset was based on early OpenJDK7 patchsets and it may or may not build on other platforms. I am 99% sure it won't build on DragonFlyBSD/x86-64, BTW. > > BTW, does "make DISABLE_MAKE_JOBS=yes" make any difference? > > Actually after successful build I can't reproduce this issue > anymore. I seem to miss some bits of data so I'll try to retest in > clean environment. These parallel build problems are very hard to reproduce. Actually, I was never able to reproduce it myself. Jung-uk Kim I just mark the port as MAKE_JOBS_UNSAFE (r356867). |