> On Jan 12, 2015, at 3:26 AM, David Holmes <david.hol...@oracle.com> wrote: > > cc'ing macosx-port-dev and hotspot-dev > > On 12/01/2015 8:41 PM, Erik Joelsson wrote: >> >> On 2015-01-12 00:02, David Holmes wrote: >>> Hi David, >>> >>> On 10/01/2015 2:00 AM, David DeHaven wrote: >>>> >>>> We have this nice little comment in common/autoconf/jdk-options.m4: >>>> # On Macosx universal binaries are produced, but they only contain >>>> # 64 bit intel. This invalidates control of which jvms are built >>>> # from configure, but only server is valid anyway. Fix this >>>> # when hotspot makefiles are rewritten. >>>> if test "x$MACOSX_UNIVERSAL" = xtrue; then >>>> HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT} >>>> fi >>>> >>>> >>>> So.. I turned it off: >>>> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >>>> # MACOSX_UNIVERSAL="true" >>>> MACOSX_UNIVERSAL="false" >>>> fi >>>> >>>> And in hotspot/make/bsd/makefiles/defs.make: >>>> # Universal build settings >>>> ifeq ($(OS_VENDOR), Darwin) >>>> # Build universal binaries by default on Mac OS X >>>> # MACOSX_UNIVERSAL = true >>>> MACOSX_UNIVERSAL = false >>>> ifneq ($(ALT_MACOSX_UNIVERSAL),) >>>> >>>> hotspot still seems to build happily (I'm kicking off tests now). Is >>>> there are particular reason this hasn't been done yet? I'd like to >>>> know before I pursue this as a means of eliminating our dependency on >>>> lipo which is causing an inordinate amount of grief when trying to >>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some >>>> logic to work around using the broken /usr/bin/lipo, but it doesn't >>>> help later in some "other" build target that ends up using '-arch >>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc >>>> to do the fattening itself and so it fails even though I've gone to >>>> the effort of working around the broken lipo (and it isn't necessary >>>> anyways because it doesn't even build the i386 binaries even though >>>> it's supposed to be "universal"). >>> >>> The hotspot makefiles still haven't been rewritten (though Magnus had >>> been working on it). >>> >>> Also I was under the impression that we used the universal stuff >>> because we had to deliver in a particular way on OSX. But I don't know >>> the details and the people who dealt with the original OSX port effort >>> are no longer here. >>> >> I don't know why Hotspot is packaged as a universal binary. In the jdk, >> only libJObjC was built as a universal binary and that lib was removed >> before JDK 8 shipped. What part of Macosx would need to interact >> directly with libjvm.dylib in a way that required a (fake) universal >> format, but no other libs in the jdk? I would say go ahead and change it. > > In the spirit of "never take down a fence until you know why it was put up in > the first place" I've cc'd macosx-port-dev to see if there is anyone around > who recalls why hotspot is using the universal binary feature. > > David H. > -------
I did the original universal binary work for hotspot when bringing up macosx-port. At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit. The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile. As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it. > /Erik >> >>> David H. >>> >>>> >>>> Quite frankly I'd rather just remove all the universal binary stuff >>>> from hotspot, but I'm trying my best to minimize the changes there... >>>> the "other" problem I can handle easily. >>>> >>>> -DrD- >>>> >>