Re: [PATCH] Add initializer for _nl_domain_bindings

[Klee Dienes]

[ I should warn here that I'm not an expert on the OS X shared library 
mechanism; this is just my best understanding of how it works based on 
my own experience with it. ]

It's possible for shared libraries on OS X to have a non-empty BSS 
section.  The issue is the common linkage, not the BSS aspect.  On OS 
X, each source file in a shared library is a separate module.  All 
functions from a given module linked as a unit.  I belive the idea is 
to ensure that modules in shared libraries can count on "all or 
nothing" loading --- i.e. if you replace the system malloc library, you 
also have to replace the system free, and the system malloc/free/etc. 
can all count on their internal data structures to not have been messed 
with by dynamic loading. It's also possible for the programmer to 
define 'private extern' references that are exported to an entire 
module, but not outside of it.

My understanding is that multiple symbols with common linkage breaks 
this model, and so they are prohibited in dylibs.  It's still possible 
to generate zero-filled data regions, but you have to use a special 
assembler directive, or pass -fno-common to the compiler.

When the compiler sees an uninitialized global without -fno-common, it 
puts it in the common section and flags it as common linkage.  When it 
sees an uninitialized global with -fno-common, it puts it in the common 
section, marks it as zerofill and flags it as extern linkage.  The 
problem arises when there are libraries that rely on the ability to 
define the same global in multiple files and rely on the linker to 
coalesce them as common symbols --- the OS X mechanism will either 
complain about "ld: common symbols not allowed with MH_DYLIB output 
format" if -fno-common is not used, or will complain about "ld: 
multiple definitions of symbol _x" if -fno-common is used.

In the libintl case, it would appear I jumped the gun --- 
_nl_domain_bindings isn't being used as a common symbol, it's 
referenced with an extern in the only other file that uses it.  The 
problem is apparently the FSF GDB source tree doesn't support building 
intl/ with libtool --- it's just building it as a static library, and 
then linking it in at the end.  So I suspect that's likely the proper 
place to track this down; I'll let you know how it works out.


On Monday, October 28, 2002, at 07:06 AM, Bruno Haible wrote:

> Klee Dienes writes:
> > Without an initializer, _nl_domain_bindings ends up declared as a
> > common symbol on Mac OS X systems, and prevents the use of libintl as 
> > a
> > dynamic library.  The appended patch initializes _nl_domain_bindings 
> > to
> > NULL.
>
> You mean to say, it is impossible for a shared library (.dylib) on
> MacOS X to have a nonempty BSS section?
>
> If that is the case, Apple should better fix their runtime loader.
> Shared libraries with BSS are quite frequent (see appended listing
> from a Linux machine).
>
> If not, then can you please tell the error message that you saw when
> building libintl? It might be a problem in libtool; we need to sort
> that out. Of course, you alse need to tell the compiler which you used.
>
> Bruno