On 11/17/2011 12:38 AM, Jan Holesovsky wrote:
testtools/source/bridgetest/makefile.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 4f11d0aa461537efa2705e7b49bc2c828a700e43
Author: Jan Holesovsky<ke...@suse.cz>
Date: Wed Nov 16 22:57:28 2011 +0100
Revert the component.map removal from makefile to fix Windows build.
Can somebody with a working Windows build try out whether adding lines
SHL1IMPLIB = i$(SHL1TARGET)
SHL2IMPLIB = i$(SHL2TARGET)
would allow to revert the revert and keep Windows happy (it would at
least not break the Linux build)? I'm actually not really sure, because
these libs are built differently than others (via LIBnTARGETs, probably
because they share common objects), but in other cases that use
SHLnUSE_EXPORTS=name, a SHLnIMPLIB was necessary for some reason or
other (that I cannot remember; I always use configmgr/source/makefile.mk
as a blueprint for building a dmake-based UNO component with
visibility---I once tweaked that one with Ause until it was exactly
what's needed, without any obsolete cruft).
Stephan
diff --git a/testtools/source/bridgetest/makefile.mk
b/testtools/source/bridgetest/makefile.mk
index cc3661a..31c5b7e 100644
--- a/testtools/source/bridgetest/makefile.mk
+++ b/testtools/source/bridgetest/makefile.mk
@@ -88,7 +88,7 @@ SHL1STDLIBS= \
SHL1LIBS= $(LIB1TARGET)
SHL1DEF= $(MISC)$/$(SHL1TARGET).def
DEF1NAME= $(SHL1TARGET)
-SHL1USE_EXPORTS = name
+SHL1VERSIONMAP = $(SOLARENV)/src/component.map
# ---- test object ----
@@ -107,7 +107,7 @@ SHL2STDLIBS= \
SHL2LIBS= $(LIB2TARGET)
SHL2DEF= $(MISC)$/$(SHL2TARGET).def
DEF2NAME= $(SHL2TARGET)
-SHL2USE_EXPORTS = name
+SHL2VERSIONMAP = $(SOLARENV)/src/component.map
SHL3TARGET = constructors.uno
SHL3OBJS = $(SLO)$/constructors.obj
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
