RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx
David Holmes
david.holmes at oracle.com
Fri Jun 22 01:20:45 UTC 2012
On 22/06/2012 4:25 AM, Staffan Larsen wrote:
> On 21 jun 2012, at 19:12, Scott Kovatch wrote:
>
>> 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.
I'm not sure what "next phase" relates to here. The two chunks in the
make file operate on distinct sets of files.
>> 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.
>
> Yes. Or rather, only the client jvm was combined, but the client jvm isn't copied into the j2sdk-image on mac, so nothing was copied.
Which begs the question: if we only build 64-bit on OSX then how/why is
client being built in the first place?
David
-----
> /Staffan
>
>>
>> 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.larsen at 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.larsen at 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!
>>>>>>>
>>>>>
>>>
>>
>
More information about the build-dev
mailing list