commit 4b56d82c7d20ba5897d87aaf7fc94da5356b8eec converted the cli_uno
library from "Managed C++" to "C++/CLI", but forgot one detail:
The destructors on "ref" classes were mapped to Finalize() methods in
the old syntax, but the new one maps them to Dispose() methods, which
are only invoked on stack-allocated objects. Presumably this omission
results in leaking of native C++ UNO objects.
Reading the C++/CLI documentation i get the impression that:
1) the destructor should explicitly call the finalizer
2) the CLR will not call the finalizer itself iff the destructor is
invoked
http://msdn.microsoft.com/en-us/library/ms235315.aspxhttp://msdn.microsoft.com/en-us/library/ke3a209d%28v=vs.110%29.aspx
Change-Id: I509d9b69a399c3d7d6597060ab9b7c78c5916e11
Reviewed-on: https://gerrit.libreoffice.org/11132
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
It looks like what works is to give the source file names with
backslashes but everything else with forward slashes?
Change-Id: Iaf910ab5fc41984d1315a30b164a334d28344c16
Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
Convert code like:
aStrBuf.appendAscii( RTL_CONSTASCII_STRINGPARAM( "ln(x)" ));
to:
aStrBuf.append( "ln(x)" );
which compiles down to the same code.
Change-Id: I24c7cb45ceb32fd7cd6ec7ed203c2a5d746f1c5c
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliLibrary and CliLibraryTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: If0fea1337349c41f231c8cde122852c71d5080a7
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliNativeLibrary and CliNativeLibraryTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- the Library remains in layer NONE; the derived CliNativeLibrary
is in INSTDIR
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: I3bf4859e8c574f84d69eb43d12ddce0d34b5730c
Introduce SDKDIRNAME as a configury variable and use it instead of the
gbuild gb_Package_SDKDIRNAME. Then we can easily construct the
SDKDIRNAME_FOR_BUILD variant that is needed to find the specially
named SDK in instdir on OS X when cross-compiling.
Move the version number section in configure.ac earlier.
Change-Id: Iee3db1a50ad4c7a9f91bbc5e0d0b01d76a76f701
The library is already in the URE/bin directory, but that is not
sufficient to be able to run sdk/bin/climaker.exe.
There are apparently 4 ways for a .net/CLR executable to locate
shared libraries:
1) in the same directory as the executable
2) in some mysterious "GAC" thing in C:/Windows
(which is presumably how it works if you actually install LO)
3) via an application configuration file entry "probing",
which only works when it's in a sub-directory of the
one the executable is in
4) via a DEVPATH variable, but that only works with a
special configuration entry in a system "machine config" file
of the .net framework
Specifically PATH is apparently ignored. Since building on Windows is
enough of a PITA already and we don't want developers to have to edit
another config file, put another copy of the library into sdk/bin.
http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94Resolving_Names_to_Locationshttp://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94CLR_Loader
Change-Id: I511957ad9a9a918ed0c316126304a1980fb2d289
This is a follow up commit to
- 22d1beb78a475e4846af945afde1c4d6c263b5d6
- 1c7af455ab9345304a7ac48ce2e0310de2ac8a75
Change-Id: I55ff666c357c89ad355a1a5bc0d0347fcc188476
This is a follow up commit to
- 22d1beb78a475e4846af945afde1c4d6c263b5d6
- 1c7af455ab9345304a7ac48ce2e0310de2ac8a75
Change-Id: I102685391125f3b4f7bdf838f8bd17a2283d558d
gb_LinkTarget__add_internal_headers was used only for sdi headers now
anyway, hopefully for no good reason.
One headers target is enough for all.
Change-Id: Ia01fb7a0aac7f72915448424b3393ecd9ba0f8f5
Whether it works, no idea. But on the other hand, from the dicsussion
in fdo#61503 it doesn't seem as if that commit was deeply insightful
either. (And how it compiled on the commit author's machine, no idea.)
Change-Id: If6355b33c406e8da5bdb2bf77aaf8b2ac0c39343
