[Caml-list] Bug in libunix.a + Patch

[Caml-list] Bug in libunix.a + Patch

[Keyan]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Hi,

_envrion was not found, when linking libunix.a to a library on Mac OS X:

Undefined symbols for architecture x86_64:
  "_environ", referenced from:
      _unix_execvpe in libunix.a(execvp.o)
      _unix_environment in libunix.a(envir.o)

I added the following lines:

#ifdef __APPLE__ 
#include <crt_externs.h> 
#define environ (*_NSGetEnviron()) 
#else 
 extern char **environ; 
#endif 

to the flies:

otherlibs/unix/envir.c
otherlibs/unix/execvp.c

as they it was suggested here:

http://trac.macports.org/browser/trunk/dports/lang/hugs98/files/patch-packages-base-include-HsBase.h.diff?rev=81676

patches are attached to this email.

best,
Keyan


[-- Attachment #2: envir-patch.txt --]
[-- Type: text/plain, Size: 153 bytes --]

22a23,31
> 
> #ifdef __APPLE__ 
> #include <crt_externs.h> 
> #define environ (*_NSGetEnviron()) 
> #else 
>  extern char **environ; 
> #endif 
>    
> 

[-- Attachment #3: execvp-patch.txt --]
[-- Type: text/plain, Size: 156 bytes --]

24a25,34
> 
> #ifdef __APPLE__ 
> #include <crt_externs.h> 
> #define environ (*_NSGetEnviron()) 
> #else 
>  extern char **environ; 
> #endif 
>    
> 
> 

Re: [Caml-list] Bug in libunix.a + Patch

[Xavier Leroy]

On 07/20/2012 04:45 PM, Keyan wrote:

> _envrion was not found, when linking libunix.a to a library on Mac
OS X:
> 
> Undefined symbols for architecture x86_64:
>   "_environ", referenced from:
>       _unix_execvpe in libunix.a(execvp.o)
>       _unix_environment in libunix.a(envir.o)

At the risk of sounding like a broken record, could you please file a
report on our bug tracker:
http://caml.inria.fr/mantis/
It's the best way to ensure that the issue will not slip past our radar.

Also, please tell us which versions of MacOS X and of Xcode you're using.

Because this sounds very much like a bug in the C library or in the
linker: the "environ" variable is standardized as part of POSIX and
derived standard like the Single Unix Specification, and MacOS X has
been very very good so far at following POSIX standards.

- Xavier Leroy

Re: [Caml-list] Bug in libunix.a + Patch

[Keyan]

Hi,

I will post it on the bug tracker too. My setting is:

Mac OS X 10.7.4
gcc version: i686-apple-darwin11-llvm-gcc-4.2
ocaml 3.12.1
Xcode 4.3.3 (4E3002)

I don't develop in Xcode, but use makefiles instead. Homebrew was used to install ocaml.

The error only occurs when linking to a dynamic lib, not when I link against an executable (main loop in c).

Best,
Keyan


On 20 Jul 2012, at 18:32, Xavier Leroy wrote:

> On 07/20/2012 04:45 PM, Keyan wrote:
> 
>> _envrion was not found, when linking libunix.a to a library on Mac
> OS X:
>> 
>> Undefined symbols for architecture x86_64:
>>  "_environ", referenced from:
>>      _unix_execvpe in libunix.a(execvp.o)
>>      _unix_environment in libunix.a(envir.o)
> 
> At the risk of sounding like a broken record, could you please file a
> report on our bug tracker:
> http://caml.inria.fr/mantis/
> It's the best way to ensure that the issue will not slip past our radar.
> 
> Also, please tell us which versions of MacOS X and of Xcode you're using.
> 
> Because this sounds very much like a bug in the C library or in the
> linker: the "environ" variable is standardized as part of POSIX and
> derived standard like the Single Unix Specification, and MacOS X has
> been very very good so far at following POSIX standards.
> 
> - Xavier Leroy

Re: [Caml-list] Bug in libunix.a + Patch

[Benedikt Meurer]

On Jul 20, 2012, at 19:13 , Keyan wrote:

> Hi,
> 
> I will post it on the bug tracker too. My setting is:
> 
> Mac OS X 10.7.4
> gcc version: i686-apple-darwin11-llvm-gcc-4.2
> ocaml 3.12.1
> Xcode 4.3.3 (4E3002)
> 
> I don't develop in Xcode, but use makefiles instead. Homebrew was used to install ocaml.
> 
> The error only occurs when linking to a dynamic lib, not when I link against an executable (main loop in c).

Of course... as stated in environ(7):

"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 run-
 time."

It has always been this way on OS X, so Keyan's patch is correct.

> Best,
> Keyan

Benedikt