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

Reply via email to