Age | Commit message (Collapse) | Author |
|
So that variables only used within SAL_INFO/WARN do not lead to
unused variable warnings in product builds. Also for OSL_TRACE
(which used to work that way before already); allowing to revert
a recent warning fix.
|
|
|
|
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
|
|
|
|
|
|
This reverts commit af19d9f563667376f759b4526bc1bcb056947394.
|
|
|
|
|
|
|
|
|
|
You are not expected to be make'ing here without knowing what you are
doing anyway. Just unconditionally require the stuff needed by the
sample cppunit tests mentioned on the last lines.
|
|
|
|
|
|
Helps debug crashes, segfaults, etc
as one gets the right backtrace in gdb and dumped core.
|
|
|
|
|
|
|
|
Now it runs until a crash caused by ICU library mixup between our ones
and the system ones, they have the same names but aren't
compatible... (see 7ee03666d7cfc27453315e1682e3c32d39a031b6).
|
|
|
|
|
|
|
|
|
|
For Android only for now. To be used to read raw asset files from the
application package (.apk file, a zip archive).
|
|
Add possibility to start strace tracing the process. Unfortunately it
this doesn't seem to work as nicely as one might have hoped. If the
process crashes, the last strace output does not show up. Some
buffering that gets abruptly discarded when the straced process dies?
Add a function to the native code to look up an archive member in the
.apk and return a pointer to it. To be used for non-compressed
resources only. We mmap the whole .apk. The Zip format parsing code is
borrrowed from Mozilla's APKOpen.cpp.
Correspondingly, add to the local build.xml a re-definition of the
"-package-resources" target from Ant's build.xml modified to not
compress resources.
Improved the Makefile a lot. New target "install" to build the apk and
install it without constructing the apk twice.
Other minor changes here and there.
|
|
These variables are set, but unused.
|
|
|
|
|
|
|
|
|
|
|
|
Android's dladdr() stores just the basename of a shared object in
Dl_info::dli_fname. LibreOffice expects either a complete absolute
pathname or a relative path from the current directory to be returned
there. So look up the full pathname of the library from
/proc/self/maps.
Also remove the fallback message loop after lo_main() returns, instead
just exit.
|
|
|
|
|
|
|
|
This allow to run make in a module wihtout the need to source
Env.Host.sh.
|
|
|
|
Do the LD_LIBRARY_PATH splitting in Java, much easier, and pass the
split up path to the native setup() method.
Use lo_dlopen() in the osl_loadModuleAscii.
Harcode en-US.UTF-8 as the locale for now.
Cut down on verbose logging of stuff that already works.
|
|
Do use NativeActivity and android_native_app_glue after all.
I hope this enables us to have a "message pump" (a loop that typically
would call ALooper_pollAll()) inside the LO "program" being run, as
expected by LO code.
(On Android, a "program", even one mostly implemented in native code,
is actually a shared library loaded by the main Java code of an app.)
The android_native_app_glue code and the android_main() it calls
belongs in the bootstrap library, though. Not in SAL_MAIN_IMPL.
The earlier idea, having a "normal" Java Activity subclass, would mean
events come in as method calls to that class. To then turn those into
something the LO code can "get", we would have effectively had to
re-implement what android_native_app_glue does anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We use the "native app glue" thing from the NDK to avoid having to
have an explicit Java wrapper. (There is one provided by the OS's
NativeActivity anyway; all Android apps are Java programs.)
For simplicity, we just #include android_native_app_glue.c in
sal/main.h. sal/main.h is included only from source files that
actually form the "main" programs for our programs anyway, I hope.
Presumably the only programs we actually want to build for Android in
this way are unit tests. Any real (or toy) LibreOffice-related Android
app would have a totally Android-specific user interface written in
Java, and just call LO libraries, I think.
|
|
|