Tuesday, August 01, 2017

icudt58_dat size mismatch (Re: libreoffice broken?)

On 2017/07/31 19:10, Laurence Tratt wrote:
> > soffice.bin:/usr/local/lib/libicuuc.so.13.0: /usr/local/lib/libicudata.so.13.0 : WARNING: symbol(icudt58_dat) size mismatch, relink your program
> > soffice.bin:/usr/local/lib/libreoffice/program/libvclplug_gtklo.so: undefined symbol '__cxa_thread_atexit'
> > ld.so: soffice.bin: lazy binding failed!
>
> Thanks to everyone (Nigel, Stuart, Marc) for the suggestions. The patches in
> CVS now get rid of the above crash so soffice at least loads. However, Word
> import seems broken and I assume that's why most of use Libreoffice ;)
> Whether that's because of the icu issue or not I have no idea!

The icu thing isn't really an issue. They're using a trick (Marc looked
into it, see below), the only difference with the gcc build is that it's
using -finhibit-size-directive so there's no warning. (*generally* size
mismatches are a problem, this is special).

There is another way around it, using --with-data-packaging=archive, but
that breaks use within chroot (notably the php-intl module, but we might
also have a problem if we enable smtputf8 in postfix) unless the data
file is copied in. There is another way we could handle that, add a
second (and possibly third) copy of the data file to either icu4c or
to other packages using it, but that's not particularly appealing..

If anyone has other ideas of how to quieten this (er, maybe not a
strcmp in ld.so though.. :) please speak up!



----- Forwarded message from Marc Espie -----

The actual generated data (from tmp/out/icudt58l_dat)
U_EXPORT struct {
uint16_t headerSize;
uint8_t magic1, magic2;
UDataInfo info;
char padding[8];
uint32_t count, reserved;
struct {
const char *name;
const void *data;
} toc[3429];
} U_EXPORT2 icudt58_dat = {


The declaration in udata.cpp (after preprocessing):

typedef struct {
uint16_t headerSize;
uint8_t magic1;
uint8_t magic2;
} MappedData;

typedef struct {
MappedData dataHeader;
UDataInfo info;
} DataHeader;


extern "C" const DataHeader icudt58_dat;


no wonder this doesn't match :)
One declaration is the header, the other one is the full populated
data structure.

the "simplest" fix would be to have a way to export just the initial
segment of the actual data...

I'll admit I don't quite know how to do that in C... there might some
elf magic with correct attributes that can do that.

----- End forwarded message -----

No comments:

Post a Comment