Linking to JavaRuntimeSupport framework
Mike Swingler
swingler at apple.com
Mon Aug 1 19:21:24 PDT 2011
Do you know how libjava.dylib is getting loaded in? Perhaps it's being loaded with dlopen() with private options (instead of being generically linked in and loaded by dyld). You can tell by using $DYLD_PRINT_APIS=1 ("man dyld" for more environment variable goodies).
Curious,
Mike Swingler
Java Engineering
Apple Inc.
On Aug 1, 2011, at 3:23 PM, David Kocher wrote:
> Thanks for the swift response. No, there is no more a Java dictionary in the Info.plist.
>
> Below the output when the environment variable is set (thanks for the useful tip!). I have removed some of the output which should make no impact but it shows that libjava.dylib is loaded before JavaRuntimeSupport and JavaNativeFoundation. The IOD is triggered just after loading the SecurityHI framework.
>
> -
> David
>
> dyld: loaded: /usr/lib/libz.1.dylib
> dyld: loaded: /Applications/…/Contents/MacOS/./../Resources/Java/Runtime.jdk/Contents/Home/jre/lib/server/libjvm.dylib
> dyld: loaded: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> dyld: loaded: /usr/lib/libSystem.B.dylib
> dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> ...
> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
> dyld: loaded:
> ...
> dyld: loaded: /Applications/…/Contents/Resources/Java/Runtime.jdk/Contents/Home/jre/lib/libverify.dylib
> dyld: loaded: /Applications/…/Contents/Resources/Java/Runtime.jdk/Contents/Home/jre/lib/libjava.dylib
> dyld: loaded: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/JavaRuntimeSupport
> dyld: loaded: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
> dyld: loaded: /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM
> dyld: loaded: /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
> dyld: loaded: /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
> dyld: loaded: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> ...
> dyld: loaded: /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
> dyld: loaded: /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
> dyld: loaded: /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
> dyld: loaded: /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
> dyld: loaded: /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
> dyld: loaded: /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
> dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
> No Java runtime present, requesting install.
>
>
> On 02.08.2011, at 00:03, Mike Swingler wrote:
>
>> For grins, can you try linking in libjava.dylib too? I know for a fact that libjvm.dylib isn't linking in anything but libSystem and libstdc++. The only way the IOD dialog should be triggered is if JavaVM.framework is getting loaded before the symbols in libjava.dylib get introduced to the process' address space.
>>
>> You could also try setting $DYLD_PRINT_LIBRARIES=1 to see what libraries are getting loaded in what order (also assuming you have no "Java" dictionary in your Info.plist).
>>
>> Let me know how it goes,
>> Mike Swingler
>> Java Engineering
>> Apple Inc.
>>
>> On Aug 1, 2011, at 2:57 PM, David Kocher wrote:
>>
>>> No, none of them but only
>>>
>>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
>>> @executable_path/../Resources/Java/Runtime.jdk/Contents/Home/jre/lib/server/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)
>>> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.29.0)
>>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
>>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)
>>>
>>>
>>> On 01.08.2011, at 16:42, Mike Swingler wrote:
>>>
>>>> As long as libjava.dylib is loaded first, IOD is not triggered, and everything works as expected. I tested that this works correctly with the command-line executables. Are you linking against JavaNativeFoundation or JavaVM in your launcher?
>>>>
>>>> Regards,
>>>> Mike Swingler
>>>> Java Engineering
>>>> Apple Inc.
>>>>
>>>> On Jul 30, 2011, at 9:19 AM, David Kocher wrote:
>>>>
>>>>> Hello Mike,
>>>>>
>>>>> What are your findings? This is somewhat urgent for me as bundling a JRE and still getting an optional install triggered is rather pointless.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 21.07.2011, at 19:07, Mike Swingler wrote:
>>>>>
>>>>>> Depending on JavaVM.framework, JavaRuntimeSupport.framework, or JavaNativeFoundation.framework isn't a problem, if the Install-on-Demand machinery can detect the presence of the "JLI_MemAlloc" symbol which is exported from libjava. The point of the fix yesterday was to ensure that libjava could be loaded without hauling in any of those other frameworks first.
>>>>>>
>>>>>> I'm going to be looking into this more today to make sure we've covered all the cases.
>>>>>>
>>>>>> Regards,
>>>>>> Mike Swingler
>>>>>> Java Engineering
>>>>>> Apple Inc.
>>>>>>
>>>>>> On Jul 21, 2011, at 8:45 AM, David Smith-Uchida wrote:
>>>>>>
>>>>>>> Oh, and the only reason that patch works for me is because my app is Rococoa based. The AWT native code has a large number of dependencies on JavaRuntimeSupport. So, unless JavaRuntimeSupport initalization is patched to not generate the install a JVM message, the path to java_props_md.c won't do anything.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Dave Smith
>>>>>>>
>>>>>>> On Jul 21, 2011, at 10:43 PM, David Smith-Uchida wrote:
>>>>>>>
>>>>>>>> I haven't tried building and running it yet, but the problem was triggered by the call to JRSCopyOSVersion in
>>>>>>>> jdk/src/solaris/native/java/lang/java_props_md.c
>>>>>>>>
>>>>>>>> Looking at the new code, it's now linking JavaRuntimeSupport dynamically to call it. Do you have that update?
>>>>>>>>
>>>>>>>> I'm not sure if that's going to fix it because when I traced down into the code with gdb it was JRSCopyOSVersion calling into some java init that triggered the check for the runtimes, not the static links.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the macosx-port-dev
mailing list