Surely these are linked to by default anyway? Is this just old cruft,
or specific to OOo's use of MinGW on Cygwin, and not needed with a
modern mingw-w64 cross-compiler? Let's see...
Remove an unused style copy per registry entry that was added to
installer::windows::registry::add_userregs_to_registry_table()
as part of the integration of CWS jl67.
Added in CWS nativefixer5, but never used:
installer::existence::filename_exists_in_filesarray
installer::existence::filegid_exists_in_filesarray
Added in CWS native222, but never used:
installer::downloadsigner::logfollowmeinfohash
Added in CWS newscpzip2, but never used:
installer::converter::convert_hash_into_array
Added in 2004, used for a month, then dropped from usage:
installer::converter::get_number_from_directory
Its alternative values as used by OOo is irrelevant to us as we don't
intend to support building using MinGW on Windows itself. To us, MinGW
always means cross-compilation. For us it is enough to look at
$(OS)$(COM), and WNTGCC always implies cross-compilation.
(OOo on the other hand attempts to support use of the Cygwin gcc with
the -mno-cygwin option (which is practically considered an obsolete
option), the normal MinGW compiler (but still from Cygwin), but not
cros-compilation.)
This commit allows to set which libraries to merge
and creates merged library in tail_build if enabled.
This should save time when loading libraries in application
and also makes more sense for link-time optimization.
Signed-off-by: Michael Meeks <michael.meeks@novell.com>
This helped to get over
[ build ASM ] basic/source/runtime/wnt-x86
/bin/sh: /cygdrive/c/Programme/Microsoft: No such file or directory
when blanks are in the path as in
--with-asm-home="/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC/bin"
Another one related to fdo#39747.
The file solenv/bin/modules/installer/configuration.pm isn't used at
all currently. (I see that it was used for a while back in 2004 by
make_installer.pl.) This patch drops the file.
LGPLv3+/MPL
Jordan Ayers
>From fc1a7ebdb81cfb927f80a4ba4fb625a40840263f Mon Sep 17 00:00:00 2001
From: Jordan Ayers <jordan.ayers@gmail.com>
Date: Mon, 22 Aug 2011 23:42:00 -0500
Subject: [PATCH] Remove unused perl module.
Reduce scope of $packjobref.
Remove $exithandler and its shutdown check, since no handler was ever assigned.
Remove some unused install::global:: variables.
Take notice of USE_DEBUG_RUNTIME also in set_wntx64.mk.
Don't unset USE_DEBUG_RUNTIME and don't hardcode the non-debugging
msvcprt.lib when building the Explorer extension.
Undefine OSL_DEBUG_LEVEL in its source files that would otherwise drag
in the diagnosing functions from sal. We don't link the Explorer
extension with sal.
As such it might not make much sense to actually *use* a shell
extension built with assertions in the C++ library, against the
debugging C/C++ runtime. You don't want assertions to fire in
Explorer, do you? On the other hand, one could be debugging an
Explorer extension remotely. Maybe even locally, I don't know if some
lower levels of Windows get upset if Explorer is unresponsive due to
being debugged, or something.
But anyway, the main point for now is to make an --enable-dbgutil
build succeed.
Alternatively we could also make sure USE_DEBUG_RUNTIME is unset in
*all* makefiles in shell.
