Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


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.