On Tue, May 24, 2011 at 11:26:30AM +0100, Caolán McNamara wrote:
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.
After a few days of idle meditation, I tend to agree with this position:
even though the DLLPOSTFIX character string has no useful purpose, it
would be best to ensure the libraries keep unique names, different from
system or third-party packages ones.
I'd like to use 'lo' as a common platform suffix.
In a first stage, the build system would still be using DLLPOSTFIX as-is,
only with a unique value.
In a second stage, the suffix would be directly integrated to the library
names, and could be kept or removed on a case-by-case basis.
If there is no objection, I intend to begin the work in a few days.
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.
I vaguely remember someone mentionning a giant file server in Hamburg where
all binaries where stashed together ...
--
Francois Tigeot
Context
- Re: [Libreoffice] Removing DLLPOSTFIX (continued)
Re: [Libreoffice] Platform-specific DLL suffix usefulness · Tor Lillqvist
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.