Linking to JavaRuntimeSupport framework

[David Kocher]

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