[tlbuild] starting builds (kfreebsd-amd64)

[Peter Breitenlohner]

On Sun, 8 May 2011, Alan Braslau wrote:

> On Sunday 08 May 2011 01:46:46 Karl Berry wrote:
>>      I see:
>>       ranlib libicudata.a
>>     and
>>       creating link 'libsicudata.a' -> 'libicudata.a'
>>
>> Indeed.  So ranlib was run.  Could the linker be refusing to follow
>> a symbolic link?  Seems highly improbable (and a bogus error
>> message to boot), but I have no other ideas :(.
>
> ranlib is OK. Here is what it get
>
> kfreebsd-amd64:
>  nm -s libsicudata.a
>  nm: icudt46l_dat.o: File format not recognized
> but
>  file Work/libs/icu/icu-build/data/out/tmp/icudt46l_dat.o
>  icudt46l_dat.o: ELF 32-bit MSB (SYSV)

Hi Alan,

this is really sad.  Could you check for kfreebsd-amd64:
(1) that libsicudata.a is a symlink -> libicudata.a
(2) nm yields the expected output for libicudata.a
(3) nm fails for libsicudata.a

If that is so, IMHO that is a pretty bad bug, however, there is nothing we
can do about at the moment.

=====================

Let me explain where this whole mess comes from.

Originally (for icu versions <=4.2.1) the ICU people had the peculiar idea
to use different names for shared and static libraries, e.g., libicudata.so
and libsicudata.a.  For recent icu versions that has been changed, but only
for some systems.  In order to cope with this, whenever libicuxxx.a exists
but libsicuxxx.a does not I have added instructions to create a symlink
libsicuxxx.a->libicuxxx.a and always using the name libsicuxxx.a when
building XeTeX and bibtexu.  I didn't dream of the complication that a
system wouldn't be able to cope with such symlinks.

======================

There are just two Makefile fragemnts that define STATIC_PREFIX=s and/or
STATIC_PREFIX_WHEN_USED=s.  The obvious way out is to remove these and
always use the names libicuxxx.a.  I'll try to do this today or tomorrow.

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>