Age | Commit message (Collapse) | Author |
|
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
|
|
As the system gtk libraries may depend on later versions of libcairo.so.2 and
its bring-along libpixman-1.so.0 with the same SONAMEs. So if it would ever
happen at runtime that our bundled libcairo.so.2 and/or libpixman-1.so.0 get
loaded before the system ones, the system gtk would probably not work correctly.
Ultimately, the bundled cairo can probably go completely.
This reverts 122a137672d761418a549568ad8cad623dd2b4b5 "extensions: crude hack
for mysterious cairo link failure."
As discussed at #libreoffice-dev:
Oct 24 10:10:15 <mst__> sberg, caolan, dtardon any idea what the proper fix is
for pluginapp.bin? 122a137672d761418a549568ad8cad623dd2b4b5 breaks on RHEL5
tinderbox...
Oct 24 10:10:17 <IZBot> core - extensions: crude hack for mysterious cairo link
failure -
http://cgit.freedesktop.org/libreoffice/core/commit/?id=122a137672d761418a549568ad8cad623dd2b4b5
Oct 24 10:12:53 <dtardon> mst__, i'd try
gb_Executable_use_external,pluginapp.bin,cairo
Oct 24 10:13:58 <mst__> dtardon, i'm not sure if that is the intent - the
-lcairo comes from the gtk external so we should use same cairo as gtk i.e.
system one? but id on't understand why linker won't find the pixman library
Oct 24 10:16:35 <sberg> mst__, I get no build failures in "make
extensions.clean && make extensions" when I comment out that FIXME in
extensions/Executable_pluginapp.bin.mk
Oct 24 10:18:59 <mst__> sberg, it only started to fail for me when i removed
libcairo.so from solver, probably you still have a stale one
Oct 24 10:19:42 <sberg> mst__, in solver/*/lib/? no
Oct 24 10:20:48 <sberg> mst__, but turns out I'm using --with-system-cairo (as
required by --enable-gtk3), so ignore me
Oct 24 10:22:53 <mst__> sberg, so if i rm solver/unxlngx6/lib/*cairo*
solver/unxlngx6/lib/*pixman* it still fails for me, how could system-cairo
work then?
Oct 24 10:24:13 <sberg> mst__, in that /usr/lib64/libcairo.so has a DT_NEEDED on
libpixman-1.so.0 (which "our" libcairo.so is missing, I'd assume)
Oct 24 10:24:44 <sberg> mst__, erm
Oct 24 10:41:18 <mst__> sberg, so if i filter out -lcairo in
gb_LinkTarget__use_gtk then it magically works - are there any problems with
that approach?
Oct 24 10:47:19 <sberg> mst__, so the root of the problem is that there's two
different libcairo involved? (just doing a local build --wihtout-system-cairo
here, to see what's going on)
Oct 24 10:47:55 <mst__> sberg, i don't think so since i get same problem after
removing all cairo libs from solver
Oct 24 11:12:11 <sberg> mst__, so the link line for pluginapp.bin contains
-lcairo twice, apparently dragged in indirectly (via _use_externals gthread
and gtk, likely), and does not contain "our" -L.../cairo/src/.libs (as it
doesn't _use_externals cairo), but does contain -Lsolver/*/lib. Now,
/usr/lib64/libcairo.so needs libpixman-1.so.0 and there happens to be one in
solver/*/lib that lacks syms compared to /usr/lib64/libpixman-1.so.0
Oct 24 11:13:43 <sberg> mst__, so this was nicely hidden when all the external
libs were delivered to solver/*/lib, but in the end I think the bug is to
combine system gtk with non-system cairo and/or pixman
Oct 24 11:14:49 <sberg> mst__, as long as our cairo and/or pixman have the same
SONAMEs or exported symbol names as system ones, all hell can happen at
runtime anyway
Oct 24 11:15:32 <mst__> sberg, but... why then does it fail for me if i don't
have the cairo/pixman libs in solver?
Oct 24 11:15:57 <mst__> ahhh -Wl,-rpath-link,$S/instdir/unxlngx6/program <-
taht must be why
Oct 24 11:17:40 <mst__> is it normal that -Wl,--trace does not print out what
libraries were found via -Wl,-rpath-link? it only appears to print explicit
-lfoo
Oct 24 11:18:27 <sberg> mst__, because of -Linstdir/*/program
Oct 24 11:20:27 <mst__> sberg, so we need
-Wl,-rpath-link,$S/instdir/unxlngx6/program obviously;
Oct 24 11:22:08 <mst__> sberg, apparently everything builds successfully when
filtering out -lcairo from GTK_LIBS, do you think that is the best workaround
for this?
Oct 24 11:22:14 <sberg> mst__, no, we need to change configure.ac to disallow
--enable-gtk --without-system-{ciaro,pixman}
Oct 24 11:22:39 <sberg> mst__, similarly to how we already disallow
--enable-gtk3 --without-system-cairo
Oct 24 11:24:48 <mst__> sberg, that would be sort of pointless, since linux is
afaik the only platfrom where cairo is used at all - effectvely we could
remove bundled caior then?
Oct 24 11:27:04 <sberg> mst__, effectively yes, unless it would still be useful
for some --disable-gtk scenario
Oct 24 11:33:41 <mst__> caolan, cloph does RHEL5 have a sufficiently recent
system cairo?
Oct 24 11:34:43 <cloph> cairo 1.2.4 on the CentOS 5.9 (well, more like 5.10 now)
system
Oct 24 11:37:08 <jcorrius> my RHEL6 build uses internal cairo
Oct 24 11:37:47 <caolan> rhel-5 cairo is 1.2.4
Oct 24 11:37:54 <mst__> caolan, the other option i can see is to do $(call
gb_LinkTarget_add_libs,$(1),$(filter-out -lcairo,$(GTK_LIBS))) in
gb_LinkTarget__use_gtk which works-for-me(TM)
Oct 24 11:38:30 <sberg> jcorrius, not for very much longer ,) (it typically
happens to work by luck to combine system GTK with bundled cairo)
Oct 24 11:38:59 <mst__> thorsten, are you aware of any reason why we must bundle
cairo on linux?
Oct 24 11:40:05 <sberg> mst__, "<caolan> rhel-5 cairo is 1.2.4" and we only
check for "cairo >= 1.0.2" in cofingure.ac, so all should be good
Oct 24 11:40:35 <sberg> mst__, "works-for-me(TM)" just by luck
Oct 24 11:41:33 <mst__> sberg, well perhaps guess the real problem is that
pkg-config spits out a spurious -lcairo for gtk+-2.0 so...
Oct 24 11:42:19 <mst__> ... but of course if a sufficiently good cairo is
available everywhere we don't have reason to bundle it anyway
Oct 24 11:45:45 <sberg> mst__, at least my /usr/lib64/libgtk-x11-2.0.so.0 does
have a DT_NEEDED on libcairo.so.2, so even if pkg-config wouldn't spit it out
we would still be in trouble at runtime
Oct 24 11:47:05 <mst__> sberg, at runtime we have this problem for a lot more
libraries than just cairo
Oct 24 11:47:43 <sberg> mst__, but why refuse to fix the problem, at least for
cairo, where there is apparently no good reason to bundle it anyway?
Oct 24 11:48:36 <jcorrius> is cairo used on Windows for anything?
Oct 24 11:48:42 <mst__> sberg, since there is no good reason to bundle it anyway
i don't object to removing the bundled cairo
Oct 24 11:49:38 <mst__> sberg, ... but i can still hold the opinion that gtk
shouldn't put -lcairo in its pkgconfig :)
Oct 24 11:53:12 <sberg> mst__, since "pkg-config --cflags gtk+-2.0" includes
"-I/usr/include/cairo", one could argue that cairo is a "re-exported" part of
that, so should also appear in pkg-config --libs output; one could likely
argue either way
Oct 24 11:55:27 <mst__> sberg, well but if you're calling functions from cairo
then you're using cairo directly whereas if you just call gtk functions you
have no need to link cario
Oct 24 11:56:47 <sberg> mst__, sure, my argumentation depends on that
"re-exports" argument (which might be thin); anyway, are you going to remove
bundled cairo
Oct 24 11:56:54 <sberg> ?
Oct 24 11:57:34 <mst__> sberg, i'm going to force it to system in configure for
now
Oct 24 11:58:13 <sberg> mst__, I have a patch for exactly that already locally
here, so could push that if you've not done that too already anyway
Oct 24 11:59:00 <mst__> sberg, i havent' finished my freetype patch yet because
people always distract me on irc so you can push
Oct 24 11:59:01 <sberg> mst__, or, rather, my patch just errors out in the
--enable-gtk --without-system-cairo combination, so if you have a better one,
go ahead
Change-Id: I071e759a55f46338b36c3cf8ac7cd5591bd9e376
|
|
Why is /usr/lib64/libpixman-1.so not found automatically?
Change-Id: Ide3929b53d130aee44ff6b01dcf2f7491a61a09b
|
|
As now ::comphelper::existsValue is not used anymore, we're removing this too.
Change-Id: I9bd2544a9c378f5a18746255133f5684867e0114
Reviewed-on: https://gerrit.libreoffice.org/6378
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6e3e64a0e9a0510401f9b8ddbf9e18e2d6caba3e
Reviewed-on: https://gerrit.libreoffice.org/6400
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
They are practically always useless, often misleading or obsolete.
Change-Id: I2d32182a31349c9fb3b982498fd22d93e84c0c0c
|
|
Change-Id: I17ec25a836eda7bb023c440db1f40186b6156067
|
|
Change-Id: Iea98e52fd026d93f68ab9916ccb583b156d5c9a7
|
|
Change-Id: If59d7c75c89a102a573738d15d8593cb8ac5c486
|
|
hammer silver nails into coffin and bury in concrete
Change-Id: I3fda2ff47738bb33793adab97faba2d439ac9a28
|
|
Change-Id: I4278999b9b7d184c26036bbe9e3b98420f461e8c
|
|
As discussed in the bug report. I changed all occurrences, not only the one in the Calc menu.
Change-Id: Ia652cb10ec0123b0a79a719dda59e6d2f54f0680
Reviewed-on: https://gerrit.libreoffice.org/6123
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic046150605c599746ed3235c04bcbc981e18e589
|
|
Change-Id: Ide87f07a97a51d924947f7959016164b98ab43f9
|
|
Change-Id: I683c0d30c3286ed5d725d4eefe8b3977b82ee316
Reviewed-on: https://gerrit.libreoffice.org/6035
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Icd07fba84735325408741ad10864c63ea32a6481
|
|
Change-Id: I3b701f47bbd4141127e209673a4ce9335d68ca2a
|
|
Change-Id: I6e52bfb34e7c4be0d17dfa7849d4a96248aa49b4
|
|
Change-Id: I63b1de195bf2f3f8bfd185181f48b1520cdd849f
|
|
Change-Id: I57cb3540cb94dcf39252a87b56cba3856cba9c01
|
|
Change-Id: Ia4c291936ad0b31e67d8edb046424d29462171b5
|
|
Change-Id: If9667cad9fcc0ff3b1cc8d36c0619d80d7f3e2b9
|
|
Change-Id: Ia0cb9fe1eaebdd295fb1742074fe2c48be61c077
|
|
Change-Id: Iaadec33715f8e0e0c6595c5e684606905274fdab
|
|
Change-Id: Ib5c3a2daa4a48bc286b14fa2cebb3306ea0012bc
|
|
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
|
|
Refactor everything to find and link libraries directly in INSTDIR.
- add gb_LinkTarget_get_linksearchpath_for_layer, and use it to set up
-L paths for T_LDFLAGS in such a way that only allowed libraries
can be linked against; i.e. it's not possible to link URE
linktargets against OOO or not-installed libraries
- gb_Library_get_target is now same as the gb_LinkTarget_get_target
(TODO: this needs cleanup)
- since a pattern rule won't work for linking libraries in INSTDIR,
add a separate per-file rule for every INSTDIR lib
- pattern rule can't find link target in the clean target any more
so add a LINKTARGET variable
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- tweak the call to gb_Library_Library_platform to pass in a path
in sdk/lib for the versioned URE libs
- fix the Library clean target
- add LAYER parameter to gb_LinkTarget_LinkTarget
- adjust platform link commands
- MSVC link command now uses explicit -manifestfile and -pdb
parameters to keep misc. files out of INSTDIR
- remove gb_Helper_OUTDIR_FOR_BUILDLIBDIR
- adjust Extension, CppunitTest, JunitTest, PythonTest, Gallery,
various CustomTargets to search INSTDIR
- remove SDK library symlinks and import libs from odk/Package_lib
- on Mac OS X, put .dylib symlinks into sdk/lib even though those
are not packaged and would be created by the SDK configury;
we need these to be somewhere for linking anyway
- add a (unfortunately cyclic) dependency on Package ure_install to sal
Change-Id: I70d88742f8c8232ad7b9521416275c67b64fe6cf
|
|
Change-Id: I85d4a4c3c7bf708daa85dbe7f3af54311c4d7e2e
|
|
Change-Id: I504e2abd967476f2346095fea23c8cd8fbf9ebfc
|
|
Change-Id: I5cbb4d2cd367cb62af3d6ddde24e7e2d3598b75b
|
|
Change-Id: I2aebcf6486b80af31f1a06e9ae38e5610bee0cb4
Reviewed-on: https://gerrit.libreoffice.org/5970
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
|
|
Change-Id: I7a57a8c60c07909018280e52d2da70fbf22857a7
|
|
Change-Id: I7409f7a58796c9bf7542b6a7904ad40581637eeb
|
|
This is a follow up commit to
- 22d1beb78a475e4846af945afde1c4d6c263b5d6
- 1c7af455ab9345304a7ac48ce2e0310de2ac8a75
Change-Id: I102685391125f3b4f7bdf838f8bd17a2283d558d
|
|
Change-Id: Ia7575f0f51bc3ba355ec01d937bd155adb287572
Reviewed-on: https://gerrit.libreoffice.org/5684
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
Change-Id: I7f4d85f3e26ab8b19dae05c6907840b97a8af1d6
|
|
Change-Id: I2832229b01de0cc5a725fd5fe1574a775d0bf12a
|
|
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
|
|
Change-Id: Ida9785c4b9fda0459769957734952e69d7a9de44
|
|
Change-Id: I93e14d4936c0ffbe03425d4a54bb0e09bc62b3e3
Reviewed-on: https://gerrit.libreoffice.org/5550
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>
|
|
...it looks like it used to be the order the constants appeared in the .idl
file, while now it happens to be the lexicographical order of the constant's
names. For all the constant groups in com.sun.star.report the order expected by
the code appears to be the order of the constant's numeric values (which happens
to coincide with the order of appearance in the .idl files), so explicitly sort
them that way.
Change-Id: I550401b2742fffb7c96a7787498967a7cd78fff8
|
|
Change-Id: Ib451bdb3c1c2ca42347abfde44651d5cf5eef4f3
|
|
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
|
|
(cherry picked from commit 122e10cfd23b379b97e2d8ec002e7f0562ebd6f7)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/com/sun/star/ucb/makefile.mk
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
ucb/source/ucp/webdav/DAVResourceAccess.cxx
ucb/source/ucp/webdav/DAVResourceAccess.hxx
plus headerize.pl
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: I153e394a194d0fcad29d3e3b27d5b24f7c259fc4
|
|
Make css::ucb::XWebDAVCommandEnvironment::getUserRequestHeaders() return
a sequence of css::beans::StringPair; this avoids all the any overhead,
and is much more simple and intuitive.
(cherry picked from commit 80199136d0d84b51b3d0529fb313b8f20f5cf851)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
ucb/source/ucp/webdav/DAVResourceAccess.cxx
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: I1c5d0a0b225fe86aca6ba6d6c8903985005387c2
|
|
It should be derived from css::ucb::XCommandEnvironment
(cherry picked from commit 817e11dccbfe3431f9cc0466051f4d154ce33e5e)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/com/sun/star/ucb/XWebDAVCommandEnvironment.idl
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: Ie44bed44cce09c2423adab33c3790bdcb9be452d
|
|
Change-Id: I1b5a0c3f5946aac9d353550091616cf5a31e6f82
|
|
Change-Id: I0216d11ade872af889fc805e4c2a9241f7f230c5
|
|
Change-Id: I4899c89ee5b2a54c9c05b531ab284365f1558e3d
Reviewed-on: https://gerrit.libreoffice.org/5270
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|