Re: [PATCH] Add initializer for _nl_domain_bindings

[Bruno Haible]

Klee Dienes writes:

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

Thanks for the explanation. So it seems that -fno-common should be
used when compiling libintl (and probably also other shared
libraries). It would help me if you could test that by adding
-fno-common to the compiler command lines that contain -fPIC or -fpic.
If your test is successful, I'll patch gettext's copy of libtool
accordingly.

> _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.

So the "ld: common symbols not allowed with MH_DYLIB output format"
doesn't actually appear for libintl?

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

Is it linking it into a shared library, or into gdb itself? In the
latter case there should be no problem, right?

Bruno