There are basicically two classes of cases:
1) Where the code is for obscure historical reasons or what I see as
misguided "optimization" split into a more libraries than necessary,
and these then are loaded at run-time. Instead, just use direct
linking.
2) Where dynamic loading is part of the functionality offered to some
upper (scripting etc) layer, or where some system-specific non-LO
library is loaded dynamically, as it is not necessarily present on
end-user machines. Can't have such in the DISABLE_DYNLOADING case.
Change-Id: I9eceac5fb635245def2f4f3320821447bb7cd8c0
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
the intent of this header has canged over time. now it is already
systematically included with ustring.hxx and the operator overload it
provide fit nicely there...
Just to be safe, since that include as been added to the api during the
3.5 timeframe and therefore is already in 'production'
the header remain and simply attempt to include ustring.hxx
but a warning is issued indicating that this header should not be used
anymore... in a couple of major release we will thenr emove it completely
All internal users of that header are converted.
Change-Id: I8934c55f089e29d78c0f5649b7c87b2ecf024bad
Reviewed-on: https://gerrit.libreoffice.org/634
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Now that 5c47e5f63a79a9e72ec4a100786b1bbf65137ed4 "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
...after gbuild'ification (they used to be added via solenv/bin/addsym.awk).
And sunjavaplugin.map is actually unused.
Change-Id: If6804cff8d01e268b84512d6c4b1edebde018cc0
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
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)
