[tlbuild] starting builds (kfreebsd-amd64)

[Alan Braslau]

On Monday 09 May 2011 10:21:55 Peter Breitenlohner wrote:
> 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>

$ file libsicudata.a
libsicudata.a: symbolic link to `libicudata.a'
$ nm -s libicudata.a
nm: icudt46l_dat.o: File format not recognized
so, of course:
$ nm -s libsicudata.a
nm: icudt46l_dat.o: File format not recognized

The problem seems not to be with the symbolic link, but rather
with the creation of icudt46l_dat.o
$ file icudt46l_dat.o
icudt46l_dat.o: ELF 32-bit MSB (SYSV)
which seems wrong.
$ nm -s icudt46l_dat.o
nm: icudt46l_dat.o: File format not recognized


Strangely, we do not have the same problem with kfreebsd-i386, where
$ file icudt46l_dat.o
icudt46l_dat.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), 
not stripped
$ nm -s icudt46l_dat.o
00000000 R icudt46_dat

Alan