[tex-k] Bug (arguably) in tex-file.c

Olaf Weber olaf at infovore.xs4all.nl
Thu Jun 12 10:10:04 CEST 2003

Norman Gray writes:

> Greetings,

> I'd like to report a bug/infelicity
> in web2c-7.4.5/texk/kpathsea/tex-file.c, which prevents drawing
> libkpathsea.a into a dynamic library on OSX.  I have a fix.

> I've attached the simple patch.

> The patch consists of adding a notional initialisation to the array
> kpse_format_info, even though this is elaborately initialised at
> runtime elsewhere in this module.  Thus:

>    kpse_format_info_type kpse_format_info[kpse_last_format] = { 0 };

> If this is not done, then this uninitialised global
> symbol is labelled a `common symbol' by the OSX linker,
> and this prevents it being includable in a Mach-O shared library.
> This manifests itself in the error message
>     ld: common symbols not allowed with MH_DYLIB output format
> (which I include here so that it'll show up in Google).  See
> <http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/2rt_mach-o_overview/chapter_2_section_3.html#163040>
> for Mach-specific discussion of this.

> With this change, I (or rather, libtool) can successfully build a dynamic
> library using code from libkpathsea.a.  I don't know if this is the only
> such symbol, since I don't know if the linker examines and complains
> about all such global symbols in a library, or just the ones used in a
> particular link.

Unix linkers in general handle cases like this gracefully, so there's
no (automatic) way to determine whether similar problems exist with
other symbols.  Traditionally, adding an initializer like this will
move the symbol from the zero-initialized .bss segment to the
explicitly-initialzed .data segment, making the library image somewhat
larger.  (Not much of a problem in this case, but it is the reason why
this kind of thing tends to be deliberate.)

The other people I know of who work with OSX haven't reported anything
like this, but may not have attempted shared libraries either.  On the
other hand, I do see that libtool passes (should pass) the -fno-common
flag on OSX, which should be an alternative fix for this problem.  Can
you verify whether this flag is indeed passed?

Olaf Weber

               (This space left blank for technical reasons.)

More information about the tex-k mailing list