| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I50ffc10f007f03c3252ef0196b59b881429cc159
Reviewed-on: https://gerrit.libreoffice.org/734
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
|
|
... new gb_LinkTarget_add_standard_system_libs
Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
|
|
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
|
|
Change-Id: I0e6992afbeffaf3b993e6630fb396d93012890e0
Reviewed-on: https://gerrit.libreoffice.org/632
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Ia91118388240c9a54d010b94aef34ad528ce5761
|
|
Change-Id: I531e47538f308ee43e0fe8d7db59f525e45942c3
|
|
Change-Id: Ife2f42b3a917ece10dc7ee9fcd83f1558084c4f1
Reviewed-on: https://gerrit.libreoffice.org/454
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
|
|
This partially reverts b63027f0992cf5c368faeb807c69110997dd00ea
http://lists.freedesktop.org/archives/libreoffice/2012-July/035331.html
Change-Id: I2c87ea89e1b05aa6874a74d2b781b976e970f979
|
|
...after gbuild'ification (they used to be added via solenv/bin/addsym.awk).
And sunjavaplugin.map is actually unused.
Change-Id: If6804cff8d01e268b84512d6c4b1edebde018cc0
|
|
Change-Id: I96f76ed6b33f5c786d1e3ab3981a535037a9c1b5
|
|
Change-Id: I7c62d086cb593744785abecae7a107686a4d65ce
|
|
|
|
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
Change-Id: Ibe5c739c3066f3e706a44b64d4ad775abde9662c
|
|
Change-Id: Idbab17b87d042079a8fa6ded7a7424a745761b2f
|
|
Change-Id: I53d4f6ddd9c79b9cd025339ef9a5e92ce1a881bc
|
|
Change-Id: Idbab17b87d042079a8fa6ded7a7424a745761b2f
|
|
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
|
|
|
|
...to match style used for other data members.
|
|
GCC gives the following warning which breaks compilation when using --enable-werror:
lockbyte.cxx: In function 'storeError store::FileLockBytes_createInstance(rtl::Reference<store::ILockBytes>&, rtl_uString*, storeAccessMode)':
lockbyte.css:512:37: error: 'prephitmp.221' may be used uninitialized in this function [-Werror=uninitialized]
lockbyte.cxx:906:1: note: 'prephitmp.221' was declared here
It's not clear from GCC's message, but what it warns about is
FileMapping::m_hFile. This is because of the following sequence:
* xMapping.release() makes xMapping.m_value be a default constructed
FileMapping
* the xMapping local variable in store::FileLockBytes_createInstance
gets destructed
* ~ResourceHolder() calls ResourceHolder::reset
* ResourceHolder::reset() calls FileMapping::UnmapFile::operator()
passing m_value as rMapping
* FileMapping::UnmapFile::operator() uses rMapping.m_hFile but
rMapping is a default constructed FileMapping and therefore has
m_hFile uninitialized
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>:
To me, this looks more like a compiler error. Also note that
ResourceHolder::reset only calls FileMapping::UnmapFile::operator() if tmp !=
value, which is not the case here, as both tmp and value are default-
constructed. And FileMapping::operator!= is carefule not to use the potentially
uninitialized m_hFile. But always intiializing m_hFile is probably not a bad
idea, anyway. And if it helps a certain compiler, all the better.
|
|
...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
|
|
|
|
|
|
|
|
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
|
|
have MappedLockBytes take complete ownership of the file handle and
unmap it and close it on release. Otherwise xFile will close it
and MappedLockBytes will unmap it in that order, which breaks
post android requirement to have a valid file handle in unmap
|
|
On Android, when an app is installed, arbitrary files bundled in the
app won't be unpacked into actual separate files in the file
system. They will exist only as archive entries in the .apk file
(which is a zip archive).
The SDK tooling puts such files under the /assets folder in the
.apk. The LibreOffice bootstrapping code for Android maps the .apk
file into memory.
osl_openFile() knows about the /assets special case, and uses a
separate abstraction for such memory-mapped files.
Obviously, when producing an .apk, one needs to make sure these
bundled files are not compressed, if one wants to be able to use them
directly from the memory-mapped .apk file. We do that in our test and
sample Android projects.
When mapping such files under /assets , just return a pointer to the
file's location inside the mapped .apk archive.
We can't use the old osl_unmapFile() on such mapped files, as that
would unexpectedly unmap fairly arbitrary pages of the .apk mapping,
wreaking havoc on later use of the same pages.
So, introduce a new osl_unmapMappedFile() function that takes also the
oslFileHandle originally passed to osl_mapFile(). Use this instead in
the few places where the code actually called osl_unmapFile(). Make
sure osl_mapFile() is nonexistent on Android.
|
|
|
|
|
|
|
|
|
|
|
|
Done with perl regex:
s/(\n\s*OSL_TRACE\(\s*\"[^\n]+?)\s*(\\n)+(\"[^\n]*\)\;\n)/$1$3/gs;
- removed trailing whitespaces and (multiple) newlines
|
|
|
|
|
|
|
|
I don't really see the point in having the UDK_MAJOR in the import
library name. We don't do that for any Unix either, just -lstore is
used. It isn't as if it would make any sense in keeping a mix of
(import) libraries for incompatible versions/builds of the LO (SDK) in
the same location anyway. The simpler, the better.
|
|
|
|
|
|
Conflicts:
codemaker/source/bonobowrappermaker/corbaoptions.cxx
codemaker/source/cppumaker/cppuoptions.cxx
codemaker/source/cunomaker/cunooptions.cxx
codemaker/source/idlmaker/idloptions.cxx
codemaker/source/javamaker/javaoptions.cxx
cppu/source/typelib/typelib.cxx
idlc/source/options.cxx
offapi/com/sun/star/util/PathSubstitution.idl
offapi/drafts/com/sun/star/form/ListEntryEvent.idl
offapi/drafts/com/sun/star/form/XBindableValue.idl
offapi/drafts/com/sun/star/form/XListEntryListener.idl
offapi/drafts/com/sun/star/form/XListEntrySink.idl
offapi/drafts/com/sun/star/form/XListEntrySource.idl
offapi/drafts/com/sun/star/form/XValueBinding.idl
registry/tools/checksingleton.cxx
registry/tools/options.hxx
registry/tools/regcompare.cxx
registry/tools/regmerge.cxx
sal/cppunittester/cppunittester.cxx
sal/osl/unx/socket.c
sal/osl/w32/diagnose.c
sal/prj/d.lst
sal/rtl/source/alloc_fini.cxx
sal/rtl/source/alloc_global.c
sal/rtl/source/makefile.mk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
