[Oorexx-devel] Fwd: native lib problem in leopard

[<rvj...@xs...>]

I just forward this in its entirety. I am in correspondence with Apple =20=

Java support since Leopard (Mac OSX 10.5.1) came out because BSF4Rexx =20=

will not run, with an UnsatisfiedLinkError on the native library (or a =20=

library loaded by that, probably ooRexx).  This is the outcome of much =20=

investigation. Personally I cannot really see the improvement of =20
changing the rules halfway through the game (remember when ISPF =20
appropriated more of your variable names in each release), but, in =20
time, it might impact other OS'ses that go for the stricter approach.

I found a

extern char **environ;

in kernel/platform/unix/ExternalFunctions.cpp and have tried to modify =20=

all fours uses of it in the file to the _NSGetEnviron() call as =20
suggested by the Apple Java team, but I still get a U _environ in =20
librexx. Any other suggestions/thoughts?

best regards,

Ren=E9.

Begin forwarded message:

> From: Pratik Solanki <pso...@ap...>
> Date: 7 december 2007 19:49:54 GMT-04:00
> To: Dmitry Markman <dma...@ma...>
> Cc: jav...@li..., Shawn Erickson <sh...@gm...>, =20
> Greg Guerin <glg...@am...>
> Subject: Re: native lib problem in leopard
>
> Many of you complained about UnsatisfiedLinkerErrors with some =20
> libraries on Leopard while those libraries loaded just fine on =20
> Tiger. I believe I've figured out the issue.
>
> It all boils down to having "extern char **environ" in your code. A =20=

> quick way to see if your library is running into this issue is to =20
> run nm
>
> $ nm <library> | grep environ
>         U _environ
>
> U means the symbol is undefined and needs to be resolved when the =20
> library gets loaded. Since the java binary does not define it, the =20
> library fails to load. This is a change from Tiger to Leopard. Using =20=

> environ is not okay for shared libraries. It is only fine for the =20
> main executable. Leopard got much stricter than Tiger in this regard =20=

> and "man environ" has the following to say
>
> -----
> Programs can query and modify the environment, using the environment =20=

> routines getenv(3), putenv(3), setenv(3) and unsetenv(3). Direct =20
> access can be made through the global variable environ, though it is =20=

> recommended that changes to the enviroment still be made through the =20=

> environment routines.
>
> Shared libraries and bundles don't have direct access to environ, =20
> which is only available to the loader ld(1) when a complete program =20=

> is being linked.  The environment routines can still be used, but if =20=

> direct access to environ is needed, the _NSGetEnviron() routine, =20
> defined in <crt_externs.h>, can be used to retrieve the address of =20
> environ at runtime.
> -----
>
> So your shared library directly accessing environ is actually a bug. =20=

> Ideally, you should use setenv/getenv/putenv calls. But if you =20
> really need to access environ, then you need to call _NSGetEnviron() =20=

> as stated. Please take a look at your sources to see if you are =20
> accessing environ (as an extern char**). See 'man environ' on Leopard.
>
> Now normally, if you just try recompiling your code, it will fail =20
> and will complain about environ. One can suppress that error by =20
> passing '-undefined dynamic_lookup' to ld or '-Wl,-=20
> undefined,dynamic_lookup' to gcc. If you're passing that option, =20
> your library will compile just fine but fail to be loaded.
>
> Please update your code to use getenv/setenv/putenv or =20
> _NSGetEnviron() and your library should load. If you're facing this =20=

> issue and it's *not* due to the undefined environ symbol, please let =20=

> me know so I can investigate that case.
>
> Pratik
>