54 # Package built libraries in a universal binary
55 $(UNIVERSAL_LIPO_LIST):
56 BUILT_LIPO_FILES=`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst
$(EXPORT_JRE_LIB_DIR)/,,$@) 2/dev/null`; \
57 if [ -n $${BUILT_LIPO_FILES} ]; then \
58 $(MKDIR) -p $(shell dirname $@); \
59 lipo -create -output $@ $${BUILT_LIPO_FILES}; \
60 fi
61
62
63 # Copy built non-universal binaries in place
64 $(UNIVERSAL_COPY_LIST):
65 BUILT_COPY_FILES=`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst
$(EXPORT_JRE_LIB_DIR)/,,$@) 2/dev/null`; \
66 if [ -n $${BUILT_COPY_FILES} ]; then \
67 for i in $${BUILT_COPY_FILES}; do \
68 if [ -f $${i} ]; then \
69 $(MKDIR) -p $(shell dirname $@); \
70 $(CP) $${i} $@; \
71 fi; \
72 done; \
73 fi
74
This first item will find all object files that were built separately for i386
and amd64 architectures, and then use 'lipo -create -output …' to create a
single universal binary.
The next phase copies those combined, universal binaries into
EXPORT_JRE_LIB_DIR, since the Mac has never had/needed to break out libraries
by architecture.
So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and
jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib,
and therefore not found.
Since we only build x86_64 the lipo command is effectively a cp.
-- Scott
On Jun 21, 2012, at 9:54 AM, Staffan Larsen staffan.lar...@oracle.com wrote:
At least for me, MACOSX_UNIVERSAL ends up being set to true in
hotspot/make/bsd/makefiles/defs.make.
Line 186 and forward:
# Universal build settings
ifeq ($(OS_VENDOR), Darwin)
# Build universal binaries by default on Mac OS X
MACOSX_UNIVERSAL = true
If this isn't intentional, then the fix for my problem is something else.
/Staffan
On 21 jun 2012, at 17:53, Henri Gomez wrote:
universal build, on OSX ? Happy to see that some works/fixes around it :)
BTW, how did you get in trouble since universal build is disabled for
now unless some code is added to :
There was an old thread on jdk7u-dev list and a proposed patch for
review
(http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch)
2012/6/21 Staffan Larsen staffan.lar...@oracle.com:
[adding build-dev and macosx-port-dev]
On 21 jun 2012, at 14:43, David Holmes wrote:
On 21/06/2012 10:30 PM, Staffan Larsen wrote:
Do you mean:
.PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST)
Yes. Now they will always be rebuilt.
Yes, that seems to have the same effect. Probably a better solution.
I think both of these simply mask the real problem. I still don't
understand how only some of the list items get rebuilt. The CR says
These targets will only be run for the last item in the xxx_LIST
variables (which happens to be the client jvm)
but I don't understand why that is?
Neither do I. Makefiles is black magic to me. I only discovered that
building the complete JDK from the top-level directory did not update the
hotspot bits in the j2sdk-image and this was the ultimate cause.
Here is an updated webrev:
http://cr.openjdk.java.net/~sla/7178667/webrev.02/
Thanks,
/Staffan
But I also don't understand this universalization process.
BTW you might want to run this past the bsd-port folks (don't recall the
exact alias) and/or build-dev. I seem to recall that last time we changed
something to do with universal builds it actually broke something.
David
Thanks,
/Staffan
On 21 jun 2012, at 14:12, David Holmes wrote:
Hi Staffan,
On 21/06/2012 6:33 PM, Staffan Larsen wrote:
Please review the following fix to makefiles for universal binaries on
max os x. The idea is to force the target to be executed for all items
in the list.
Fix contributed by Rickard Bäckman (rbackman).
webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/
I don't understand the problem that this addresses but wouldn't you get
the same affect by declaring those targets as PHONY ?
David
PS. Unrelated but I was astounded to see that bsd/Makefile and
linux/Makefile both have a chunk of code conditional on ifeq
($(OSNAME),solaris) Huh!
