Linking to JavaRuntimeSupport framework

[Mike Swingler]

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.
>>>>> 
>>>> 
>>> 
>> 
>