On 9 February 2012 15:59, Tor Lillqvist <tml@iki.fi> wrote:
BTW, one thought about using --enable-mergelibs in a Windows build
(MSVC or Mingw, same issue) that came to my mind:
SAL_DLLPUBLIC_IMPORT is empty for Mingw (
http://cgit.freedesktop.org/libreoffice/core/tree/sal/inc/sal/types.h#n250
)
so it should be the same as for gcc.
How is the FOO_DLLIMPLEMENTATION thing handled? Don't we in the
--enable-mergelibs case need to add into the Library_blah.mk file for
each library that will be part of libmerged a -DFOO_DLLIMPLEMENTATION
for each library FOO that is part of libmerged (and that uses that
mechanism to select between dllimport/dllexport attributes)?
I don't know, maybe MSVC will complain, but I don't see why it had to.
All symbols should be exported properly, but maybe you are right and
the one marked with import can cause problem,
because they are in the same library and not imported from another, is
it really a problem ? I have no idea (will try later)
But now --enable-mergelibs is used only for android, probably will be
used with --enable-lto for gcc
but will somebody use it on Windows ?
Matus
Context
Re: OK to merge the fw? libraries in framework? · Lubos Lunak
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.