Bug 5412 - Build system: Compile failing with 'Undefined symbols: "_environ", referenced from: _environ$non_lazy_ptr in heimdal_roken.o'
Summary: Build system: Compile failing with 'Undefined symbols: "_environ", referenced...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: x86 Mac OS X
: P5 major (vote)
Target Milestone: ---
Assignee: Jelmer Vernooij
QA Contact: Andrew Bartlett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-23 16:02 UTC by andrew tanner
Modified: 2008-10-27 18:57 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andrew tanner 2008-04-23 16:02:24 UTC
This was when compiling "4.0.0alpha3-GIT-1d940e4" on OSX:

Samba will be compiled with flags:
  CPP        = gcc -E
  CPPFLAGS   = -I./include -I. -I./lib -I./lib/replace -I./lib/talloc -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H 
  CC         = gcc
  CFLAGS     = 
  PICFLAG    = -fno-common
  BNLD       = gcc
  BNLD_FLAGS =  
  STLD       = /usr/bin/ar
  STLD_FLAGS = -rcs
  SHLD       = gcc
  SHLD_FLAGS = -dynamiclib -Wl,-search_paths_first -undefined error
  MDLD       = gcc
  MDLD_FLAGS = -dynamiclib -Wl,-search_paths_first -undefined dynamic_lookup
  SHLIBEXT   = dylib
  srcdir     = .
  builddir   = .
  pwd        = /Users/andrew/Development/Samba/source
Linking bin/shared/libdcerpc.dylib
Undefined symbols:
  "_environ", referenced from:
      _environ$non_lazy_ptr in heimdal_roken.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [bin/shared/libdcerpc.dylib] Error 1

From what I can tell _environ$non_lazy_ptr is a OSX specific symbol.
Comment 1 andrew tanner 2008-07-05 19:23:43 UTC
Here is an excerpt from the OSX environ(7) man page that should explain this 
failure:

PROGRAMMING
    Programs can query and modify the environment, using the environment rou-tines routines
    tines 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 rou-tines. routines.
    tines.

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

And here is a patch that fixes the failure:

diff --git a/source/heimdal/lib/roken/roken.h.in b/source/heimdal/lib/roken/roken.h.in
index 82473d7..a3408f2 100644
--- a/source/heimdal/lib/roken/roken.h.in
+++ b/source/heimdal/lib/roken/roken.h.in
@@ -445,8 +445,13 @@ extern int opterr;
#endif

#if !HAVE_DECL_ENVIRON
+#ifdef __APPLE__
+#include <crt_externs.h>
+#define environ (*_NSGetEnviron())
+#else
extern char **environ;
#endif
+#endif
Comment 2 Matthias Dieter Wallnöfer 2008-08-02 08:43:27 UTC
We've now a new version of HEIMDAHL Kerberos in the source tree. Please retest if the problem persists!
Comment 3 Matthias Dieter Wallnöfer 2008-08-14 11:39:18 UTC
So I'm going to close this for now. If the problem persits, reopen!
Comment 4 Andrew Bartlett 2008-08-19 21:57:52 UTC
The build farm shows this is still a problem on MacOS, so probably BSD too.  Please leave this open. 
Comment 5 Matthias Dieter Wallnöfer 2008-10-27 16:56:25 UTC
That's now up to Jelmer.
Comment 6 Matthias Dieter Wallnöfer 2008-10-27 17:18:47 UTC
Ok, we can't fix this until we have access to a MacOS X installation. If someone has some interest to look into this, we would be glad :-) !
Comment 7 Jelmer Vernooij 2008-10-27 18:57:10 UTC
Fixed in aafe9ca1aa829f64d4bad1df3ee1d5997fb17d71