site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry Appreciate any helpful comments. Thanks. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... You may want to ask this question on a mailing list that deals with Java, such as the java-dev mailing list, instead of cross-posting to the darwin-dev and unix-porting lists, which normally have nothing to do with Java. On Mar 18, 2009, at 11:03 PM, Rohitash Panda wrote: Hi, I have some confusion regarding how dependent libraries of a native library are treated on Mac OS X . I am on Mac OS X Leopard version 10.5.4 with JDK 1.4.2 I have a native library A which has a dependent library B . I see that, even if the JNI library A gets loaded and is able to successfuly load C , some sumbols which I should be seeing and which are present in library B don't seem to be exported/un-available. Using the verbose jni option provided I saw that after the native library A is loaded by JAVA, the JNI symbols directly exported from library A are resolved without any issues, but those are expected from library B are not getting resolved . Is this a known problem with this JDK version ? Since the symbols from the dependent libraries of the native library don't get exported in this case , then I guess the right way to fix this is to change the linker directives when building the jnilib . I am already using the flat-namespace option for Unix style loading/ resolving of symbols . Going through the man pages of ld , I found a couple of options which seem to be of relevance to the current context : -reexport-lx This is the same as the -lx but specifies that the all symbols in library x should be avail- able to clients linking to the library being created. This was previously done with a sepa- rate -sub_library option. -reexport_library path_to_library This is the same as listing a file name path to a library on the link line and it specifies that the all symbols in library path should be available to clients linking to the library being created. This was previously done with a separate -sub_library option. I am looking for comments from people who have faced this issue earlier. Also , to add to this, I don't seem to hit upon this issue using JDK 1.5. This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com