On Sun, 2011-05-22 at 11:43 -0600, Tor Lillqvist wrote:
> > What I would like to know is if there's still a reason to use this suffix
> > in 2011.
>
> Only backward compatibility of binary extensions
Extensions aren't supposed to link (or be able to link) against
DLLPOSTFIX libs AFAIR, they're only supposed to be able to directly link
against the ure libs that start (under Unix) with "lib". Those are
conveniently installed in /path/to/install/ure/lib for perusal, and
there are no uses of DLLPOSTFIX in there.
One gotcha is that tools/inc/tools/solar.h needs to be tweaked, etc. for
any dlopen stuff that libreoffice does. IIRC if you cock this up, it may
appear to work up until you attempt to open one of "factory" dialogs
e.g. format->character in calc and then it'll fail. Lazy uno porting
guide points out any gotchas like that.
IMO, a consistent DLLPOSTFIX name is probably better than removing it
totally, to avoid e.g. something like libCOMMONNAME${DLLPOSTFIX}.so
becoming libCOMMONNAME${DLLPOSTFIX}.so colliding painfully with some
common system lib like libCOMMON.so when linking or with the effectively
non-hierarchal flat rpm autorequires/provides.
Different DLLPOSTFIX files suggest that at some stage or other it was
desirable to be able to have the .sos from different architecture
side-by-side in the same dir. Maybe from an era before the separate arch
dirs in the solver dir, dunno.
C.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
