site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Tue, 2007-05-29 at 09:08 -0400, Jack Howarth wrote:
Is there an Apple policy on the presence of undefined symbols in shared libraries? Specifically, the libraries created by openmpi currently create undefined symbols for environ because the following wrapper is not being used...
#if !defined(__WINDOWS__) +# ifdef __APPLE__ +# include <crt_externs.h> +# define environ (*_NSGetEnviron()) +# else extern char **environ; +# endif #endif /* !defined(__WINDOWS__) */
The upstream openmpi developers are resisting this change since it is target specific (which I find amusing since they already wrapper these lines for Windows). They claim this can be handled by the application developer through including the symbol there. My argument is that this is bad form since certain cases can't be handled so easily. For instance, if a python module were developed that used openmpi's shared libraries the system python would have to be replaced with on that provided the environ symbol. I would appreciate any advice on Apple tech notes addressing this issue or other arguments we can make to the openmpi developers for accepting such patches.
The environ symbol (as well as the other symbols that you see in crt_externs.h are available to every executable, they are in /usr/lib/crt1.o that is included by gcc in the link for every executable. Shared libraries, at link time, do not see crt1.o, so environ is marked as undefined, it will always be available at runtime. So, python, ruby and so on all have environ symbols in their executable, it is harmless to leave it as an undefined, however, with two level namespace, there is a startup speed advantage to having no undefined symbols in your shared libraries, if there is only one undefined symbol and the definition is available in the main executable image (as is the case with environ), then the speed advantage is quite likely not even measurable. Hope this helps, Peter _______________________________________________ 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... This email sent to site_archiver@lists.apple.com