| Age | Commit message (Collapse) | Author |
|---|
|
o Stop pretending/forcing *Nix shared lib versioning on macOS
o Use smaller and more easily manageable temp temps by leveraging --headerpad dyld option
o misc gbuild fixes
Notes:
ignore: aoo
|
|
which it apparently needs to build on *nix.
Patch by: me
Notes:
ignore: obsolete
|
|
The problem before was apparently that including udkapi
ended up using the solver headers, instead of our
generated "comprehensive" headers.
Patch by: me
Notes:
prefer: b222aa8fff63c803781703e72366ca203f3e6a76
|
|
Patch by: me
Notes:
ignore: obsolete
|
|
WeakImplHelper1 needs to be SAL_DLLPUBLIC_EXPORT to prevent
multiple definition errors when building in debug mode
as opposed to CPPUHELPER_DLLPUBLIC we would normally use.
Without -DCPPUHELPER_DLLIMPLEMENTATION, the header's
CPPUHELPER_DLLPUBLIC would become SAL_DLLPUBLIC_IMPORT,
and on MSVC that presumbly causes symbols to be redefined
and exported for some unknown reason, whereas when we use only
SAL_DLLPUBLIC_EXPORT, it is exported in multiple modules, but
at least when building those modules we won't get errors,
as the modules' dependencies presumably aren't searched.
This has no effect on FreeBSD and hopefully other platforms.
Make all WeakImplHelper[1-12] SAL_DLLPUBLIC_EXPORT just in case.
This need for mysterious platform-specific code attributes that
affect the linker in undocumented ways really reveals a
profound and terrible truth: how ugly, poor, flimsy, degenerate,
twisted, dark, revolting and sick C++ remains as a language,
even after decades of its development.
Patch by: me
Notes:
prefer: 36627af621d46674273f44e2eb85731419a41cc1
|
|
will get the module building in gbuild and using source-level attributes
to control symbol visibility. The original commit was worded as:
Change default symbol visibility to hidden in main/cppuhelper, and export
symbols using source-level attributes (SAL_DLLPUBLIC_EXPORT) instead.
Stop using the .map file for Windows, and rely only on the above to control
symbol visibility.
This is not a perfect solution, as the exported symbols lack some typeinfos
compared to before, but it doesn't seem to break anything, and a full symbol
audit needs to be done later to fix other modules anyway.
Also added some files to get it to build with gbuild, which are currently
unused, as the gbuild build seems to break in main/i18npool.
Patch by: me
Notes:
ignore: obsolete
|
|
in 1847839 and 1847840 for now, as they break the Windows build in the most
mysterious ways...
Patch by: me
Notes:
ignore: aoo
|
|
Patch by: me
Notes:
ignore: obsolete
|
|
symbols using source-level attributes (SAL_DLLPUBLIC_EXPORT) instead.
Stop using the .map file for Windows, and rely only on the above to control
symbol visibility.
This is not a perfect solution, as the exported symbols lack some typeinfos
compared to before, but it doesn't seem to break anything, and a full symbol
audit needs to be done later to fix other modules anyway.
Also added some files to get it to build with gbuild, which are currently
unused, as the gbuild build seems to break in main/i18npool.
Patch by: me
Notes:
ignore: aoo
|
|
Patch by: me
Notes:
ignore: obsolete
|
|
since we've rolled back to .map files for cpphelper's
symbols.
Patch by: me
Notes:
ignore: obsolete
|
|
r1826428
r1826398
for now, while I investigate why they produce
multiple symbol errors on Windows when linking main/svtools.
Patch by: me
Notes:
ignore: obsolete
|
|
for Win32 and Win64.
Patch by: me
Notes:
ignore: obsolete
|
|
symbol visibility using source-level declarations instead.
C++ symbols are mangled differently on Win64 and Win32, and extracting
new symbols from binaries and updating .DEF/.map files that control symbol
visibility is painful. Both Windows and *nix have moved from using .DEF
and .map files to using declarations in the source code instead, of the
form __declspec(dllexport) and __attribute__ ((visibility("default")))
(which we wrap in SAL_DLLPUBLIC_EXPORT).
The GBuild ported modules also have to replace .map files with source code
declarations (and all so far have), as the default symbol visibility in
GBuild is "hidden" and GBuild has no mechanism to use .map files so far.
So for the purpose of the Win64 port, but as a generally good idea and a
necessity for future GBuild ports, re-implement linker symbol visibility
in main/cppuhelper using SAL_DLLPUBLIC_EXPORT declarations in the source
code instead of using .map files. The purpose of .map files is to version
symbols in the ELF binary format on *nix instead of just controlling
visibility, so they still provide that benefit on *nix, but Windows has no
symbol versioning, all dmake does with .map files is convert them to
unversioned .DEF files, which are harder to maintain than source-level
declarations (as they are both mangled and in a separate file, and have
to be specified per method instead of only once per class).
This turned out to cause trouble, as our autodoc tool doesn't have a C
preprocessor, so the "CPPUHELPER_DLLPUBLIC" was breaking generating
documentation, which was breaking the build due to documentation
completeness checks in main/odk. Thus main/autodoc had to be patched to
allow command line parameters passed to it to specify parsing tokens to
ignore, and main/odk had to be patched to pass "CPPUHELPER_DLLPUBLIC" as
the token to ignore.
Patch by: me
Notes:
ignore: obsolete
|
|
instead of recursing infinitely.
Notes:
prefer: 9598e9061f76439daa841f991fbec05412826971
|
|
Notes:
ignore: obsolete
|
|
uses executables,
not libraries, so they don't need version maps any more.
Notes:
ignore: googletest
|
|
Test
Notes:
ignore: googletest
|
|
Notes:
ignore: obsolete
|
|
Notes:
ignore: googletest
|
|
but don't run it on every build as an assertion outside the test fails during the test.
Notes:
ignore: googletest
|
|
and run it on every build.
Notes:
ignore: googletest
|
|
and run it on every build.
Notes:
ignore: googletest
|
|
Attempt to clean up most but certainly not all the spelling
mistakes that found home in OpenOffice through decades. We
could probably blame the international nature of the code but
it is somewhat shameful that this wasn't done before.
Notes:
merged as: 0a1d822372927e3252f40b7a16590716ccc2eedd
|
|
stoc's OServiceManager has it as a base class so we really need
XContentEnumerationAccess' "comprehensive" type description early.
WeakMap priming enforces that now.
Notes:
prefer: d83de4b1a93ba7ed7bc3243073be3de96a44bfa9
|
|
Notes:
ignore: aoo
|
|
Notes:
prefer: a66f9903bba9dc7eeff6683ebddcd34d4ad70068
|
|
Notes:
prefer: a66f9903bba9dc7eeff6683ebddcd34d4ad70068
|
|
link), on Windows drop unoinfo and use the path from the registry directly
Notes:
prefer: a66f9903bba9dc7eeff6683ebddcd34d4ad70068
|
|
Notes:
prefer: a66f9903bba9dc7eeff6683ebddcd34d4ad70068
|
|
pre-tr1-stl specializations
In stlport<=4 the functors hash and equal_to had specializions for conveniently handling c-strings.
For consistency reasons this specialization was not included in the TR1 report and the C++11 standard.
The two new helper functors are drop-in replacements for the old specializations.
Notes:
merged as: 1857688e1f4ba982d147a9cac69fad948361d1c0
|
|
classes
the canonic way to disallow copy construction and assignment of an object
is to declare unimplemented methods for them taking const references.
Notes:
merged as: 7725dddf05a9cbd3eb91d3bde45b22e4182b86dc
|
|
Notes:
prefer: dee53a32a9feba2021782db5762b5a9a034efae4
|
|
Notes:
prefer: dee53a32a9feba2021782db5762b5a9a034efae4
|
|
used in bootstrapping
Cppumaker and its brethren emit different implementations for
the same symbol by design (!) which is quite... unfortunate
and can confuse the heck out of dynamic linkers, debuggers, etc.
For bootstrapping the so-called "comprehensive" type descriptions are needed.
The workaround compels these descriptions to be registered in the so-called "WeakMap"
before they are needed by the bootstrap operation.
The proper and un-hacky solution would be to change cppumaker and its brethren
to use different symbol names for different implementations. In particular
"cppu_detail_getUnoType" should be divided into full, weak and mini implementations.
For now there is no time to risk such a major overhaul of this system.
Types that are candidates for this special workaround are the ones mentioned
by the exceptions thrown from implbase_ex.cxx's __queryDeepNoXInterface() method.
They also need to added to the makefile's UNOTYPES define so that the build magic
requests the full type descriptions to be generated and used.
Notes:
prefer: dee53a32a9feba2021782db5762b5a9a034efae4
|
|
Notes:
ignore: aoo
|
|
-- impact on corresponding strings in the UI, folder names, package names, ...
Notes:
ignore: aoo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
