Age | Commit message (Collapse) | Author |
|
valgrind + bff
Change-Id: Ib3ed8a6e518c0686f8cbeaf021b9ca3a07005032
|
|
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
|
|
Change-Id: I2705bbb4db52779e0065400f09604384fd9cf151
|
|
Change-Id: I2d208c7cc5ff9bf26bff5ab2aa40e0bf57373342
|
|
Change-Id: I5eb2428f4c71e5aa9bfc0bf71c06d87be039ad3b
|
|
Change-Id: I5d39bebbd55cc3170ff52459731fad333a2e92f9
|
|
Change-Id: I009e0f388cfe1861cef89d2148a02380dd47c1ff
|
|
Change-Id: If289dcbff125ac0088f01b5c9752f9f3173585dc
Reviewed-on: https://gerrit.libreoffice.org/11020
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ib3f43db131cf5562ad011538873c2ee51839665c
|
|
Change-Id: If56233b5226cec9516d5e2f8992e1b0beae733bf
|
|
Change-Id: I853b6b1cfcd4847603d9920a47298d1b9105b46f
|
|
Regression from commit de84529b55f5b295b089043a7119d6b0d8b92408.
Change-Id: I8f0b148ec7df4f676341f588c04780a705c80a5c
|
|
Change-Id: Idb909c205dfadaadeb8b98ce08fe2f4286cfce26
|
|
Change-Id: Ic1dae7aac2f4367b4196ba3128c0aea9be1fbbda
|
|
Change-Id: Id2fab3e4b7a8feed3107e66d02cdf2a278ae9ef7
|
|
by converting the bit munging to use bitfields.
Remove unused return values.
Add asserts to check that AddRef() is not called after the object
is deleted.
Fix the code in SfxObjectShell to not call AddRef() after
SfxObjectShell is deleted.
Change-Id: I3a3565a0bc45fc9d1d086222265ab8b8175818a7
|
|
Change-Id: Id1321766532eab6ee49e418b0597e62d14b5b33c
|
|
Change-Id: Idc0f3ef53f48b2e77e4cecbcdbbc44a115c6ec2e
|
|
Saves ~40bn cycles, 10% of calculation for the bug document.
Change-Id: I9d48706ad2cfe290965b648306d95b4d66e5fc63
|
|
Change-Id: Ic1c999ffdc391ea01be5711721e7c9e63179473e
|
|
Change-Id: I4bdfb074b3cf6fcb49765322308dfa4b9ed67713
|
|
Change-Id: I0a8860f2b0ea053cdfe9504dc266be36cdb0043e
|
|
Change-Id: I6ffaaa36f2e594a2e8155589a4d7000db21ab30b
|
|
Change-Id: Ida7a6ab077e1f0436f8b775956d30c82c4ad5338
|
|
Change-Id: Icebdf0cad5306ae42a30de0b4f997e3b611675eb
|
|
and strip away some stuff in rsc that should now be dead
Change-Id: I6411e706c50dff299099680f1f942bf61c4e79f2
|
|
Change-Id: I54880de44ee10d4f71c8a514f905e8e00774fde7
|
|
Change-Id: I42119f656ca528286fb25d2d36c0af54b7d04a6b
|
|
Change-Id: I5eafd6250bbde7227dcc0447a4280b7741c320de
|
|
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Conflicts:
tools/source/fsys/urlobj.cxx
Change-Id: I59b5b95cf9b65920ec04922fdb25e4228fd22995
|
|
Change-Id: I47582b072bb939cf270a76e430a9f7908b5c1d93
|
|
Change-Id: I1e542455ad3e4ab1a445366517c92b102471840a
|
|
Change-Id: Icb95d60a7f786ee75ea1904cfb7292e51eb607cc
|
|
This makes tools pch ready.
Change-Id: I8d5d5fcbb417f3790749aeb9d9c947f739ecb30f
|
|
Change-Id: I66b3dc79998de018eae1c7eff8ce23f95e3c3f33
|
|
The fun thing is that with the (only) call-site to ReadAsynchron in
PNGReaderImpl::ImplReadIDAT (vcl/source/gdi/pngread.cxx) passing in rIStm
references to stack-allocated SvMemoryStream instances, mpIStm could point to an
old, destroyed instance from a previous call, but which would have been located
at exactly the same stack address as the currently passed in rIStm, so the wrong
mpIStm->Read call would effectively behaved exactly the same as a correct
rIStm.Read call.
This went unnoticed "since the beginning" until AddressSanitizer's
UseAfterReturn check came along...
Change-Id: I7c75ed2d36a4c24c111d88eff647816bd2c5dbca
|
|
...(which can be called multiple times in a row). But which actually looks
wrong...
Change-Id: I2e4914e6fed8ced383e430699dd462add9da8c08
|
|
Change-Id: I2714b1f1dadc74f8501203bc8b0722c56c9c5fb9
|
|
Change-Id: Ibe2f5f4ad52510247fb4134f433bba4b737d9c33
|
|
...and document how the member functions are supposed to be called from client
code.
Change-Id: Ia4847945e4a361c43a0ed001e3e78e901c9abcad
|
|
Change-Id: I2103f8a323d0454bdd1c779aadb99889ae1cf6e5
|
|
Change-Id: I275abafe81c8bb617c70646244b14f6cecc33854
|
|
...and directly use zlib.h's Z_DEFAULT_STRATEGY
Change-Id: Ibf528cbc32afec4d442656aa2963f50c0875d6a5
|
|
...so just use zlib.h's MAX_MEM_LEVEL directly.
Change-Id: I76d73f665df242bfb180b76aa7054cf8ddbe9e67
|
|
Change-Id: Ib831b80afcdde98928a2759616810923348f65e8
|
|
Change-Id: I41da8920e33dfdd0f1483ea2d7cf67111224b441
|
|
Detect arguments larger than 64 chars passed by value.
Change-Id: I9b0ea9ccb99d115984a26eab67c9cf6afd5f6cae
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
AsRGBHexString returns the Color as a RGB hex string. For example
"00ff00" for green color.
Change-Id: Ia95c7f9eb6d9aefc3ca989046fa8d76b7b7f9e8f
|
|
Change-Id: I3e51a62710bb46c8255fd228d41d9300c90a1fb5
Reviewed-on: https://gerrit.libreoffice.org/9360
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: If5813e0321ff68ddf2cdbce3cdd216fda2830849
|