Re: native lib problem in leopard

Subject: Re: native lib problem in leopard
From: Pratik Solanki <email@hidden>
Date: Fri, 7 Dec 2007 15:49:54 -0800
Delivered-to: email@hidden
Delivered-to: email@hidden

Many of you complained about UnsatisfiedLinkerErrors with some libraries on Leopard while those libraries loaded just fine on Tiger. I believe I've figured out the issue.

It all boils down to having "extern char **environ" in your code. A quick way to see if your library is running into this issue is to run nm

$ nm <library> | grep environ
         U _environ

U means the symbol is undefined and needs to be resolved when the library gets loaded. Since the java binary does not define it, the library fails to load. This is a change from Tiger to Leopard. Using environ is not okay for shared libraries. It is only fine for the main executable. Leopard got much stricter than Tiger in this regard and "man environ" has the following to say

----- Programs can query and modify the environment, using the environment routines getenv(3), putenv(3), setenv(3) and unsetenv(3). Direct access can be made through the global variable environ, though it is recommended that changes to the enviroment still be made through the environment routines.

Shared libraries and bundles don't have direct access to environ, which is only available to the loader ld(1) when a complete program is being linked. The environment routines can still be used, but if direct access to environ is needed, the _NSGetEnviron() routine, defined in <crt_externs.h>, can be used to retrieve the address of environ at runtime. -----

So your shared library directly accessing environ is actually a bug. Ideally, you should use setenv/getenv/putenv calls. But if you really need to access environ, then you need to call _NSGetEnviron() as stated. Please take a look at your sources to see if you are accessing environ (as an extern char**). See 'man environ' on Leopard.

Now normally, if you just try recompiling your code, it will fail and will complain about environ. One can suppress that error by passing '- undefined dynamic_lookup' to ld or '-Wl,-undefined,dynamic_lookup' to gcc. If you're passing that option, your library will compile just fine but fail to be loaded.

Please update your code to use getenv/setenv/putenv or _NSGetEnviron() and your library should load. If you're facing this issue and it's *not* due to the undefined environ symbol, please let me know so I can investigate that case.

Pratik

On Nov 1, 2007, at 1:46 PM, Dmitry Markman wrote:

on leopard I got
java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13- b05-237) Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM: /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (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 673.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 473.0.0)
as you can see for some reason current version is 1
On Nov 1, 2007, at 4:22 PM, Shawn Erickson wrote:
On 11/1/07, Greg Guerin <email@hidden> wrote:
Rene Jansen wrote:
    /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM
(compatibility version 1.0.0, current version 96.0.0)
That seems like a remarkably high "current version".
What was the JNI-lib compiled against?
On my Tiger system I see...
[serickson@serickson-main:~] [0:513] > otool -L /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM: /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version 1.0.0, current version 96.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/ Foundation (compatibility version 300.0.0, current version 567.28.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Dmitry Markman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


Follow-Ups:

Re: native lib problem in leopard
From: René Jansen <email@hidden>
Re: native lib problem in leopard
From: René Jansen <email@hidden>


Prev by Date:
Re: Is there a fix yet or soon to an application using -d64?

Next by Date:
Re: native lib problem in leopard

Previous by thread:
Re: JSheets & JMenuBar

Next by thread:
Re: native lib problem in leopard

Index(es):

Date
Thread













  
   Home
   Archives
   Terms/Conditions
   Contact
   RSS
   Lists
   About
 






Visit the Apple Store online or at retail locations.

1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2011 Apple Inc. All rights reserved.