| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
|
|
|
|
The assumption in the comment is clearly wrong, as osl::Thread::create
returns a boolean result to indicate failure.
Slight modification of a patch by Michael Stahl <mstahl@redhat.com>.
|
|
|
|
|
|
|
|
|
|
...also improved the code somewhat.
|
|
|
|
|
|
|
|
|
|
* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
|
|
|
|
This is a cherry-pick of Matúš's e2f30c078fcf26d481c2e90398b450f6c475a483
from the feature/gbuild branch, with the following modifications by
Stephan Bergmann <sbergman@redhat.com>:
* Adapt salhelper/Makefile to what all those Makefiles currently need to
look like.
* Do not remove salhelper/source/gcc3.map, instead add directly into it
what otherwise solenv/bin/addsym.awk would add to it on Linux.
* In salhelper/Library_salhelper.mk, add code that on Linux takes care of
the soname and symbol versioning required for backwards compatibility.
Solaris would need those features too, and its backwards compatibility
is thus currently broken. Also add a bad hack to create the soname
symlink (xxx.3 -> xxx) in the solver needed on non-Windows platforms (it
is a bad hack for now in that it e.g. is not removed by "make clean").
* In solenv/gbuild/platform/macosx.mk, add an even worse hack to set the
correct install name for libuno_salhelpergcc3.dylib.3, with a trailing
".3".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
|
|
|
|
|
|
After of the vos removal, some classes in other parts of the code now
are subclasses of SimpleReferenceObject.
To avoid compilation and linking errors in those other parts, we seem
to need to have the operator new[] and operator delete[] in
SimpleReferenceObject as protected instead of private. We also need an
implementation of operator delete[]. As it can be unimplemented with
gcc, I hope it isn't actually called, though, so it for now crashes
intentionally if called.
Will see later if this actually works, this is just a commit to make
stuff build.
|
|
|
|
|
|
|
|
|
|
Fixes #fdo30794
Based on bin/add-modelines script (originally posted in mail
1286706307.1871.1399280959@webmail.messagingengine.com)
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Microsystems to Oracle; remove CVS style keywords (RCSfile, Revision)
|
|
and simplified it by requiring that first section is labeled UDK_3_0_0; adapted map files accordingly, replacing many individual ones with solenv/src templates
|
|
OS X and unused, anyway
|
|
|
