- 24 Eki, 2013 40 kayıt (commit)
-
-
László Németh yazdı
Change-Id: Id7dc7a2853a8c56ee56eab55c078650e16c278fd
-
Stephan Bergmann yazdı
...after 800005b1 "Disallow --without-system-cairo combined with (implicit) --enable-gtk." Change-Id: I74f5e4f454f5e1724e258380bbbcd771bf58453a
-
Caolán McNamara yazdı
Change-Id: I996038a45495a5b6a63622ac0d290ac4fbc0bedd
-
Caolán McNamara yazdı
Project: help 91f8b3cb54e752a174ee10be4e528c7dcd4fb55e
-
Miklos Vajna yazdı
Change-Id: Ib422584d2f6cbb8bfd88dd67aef96b8b062c3d38
-
Miklos Vajna yazdı
This allows roundtrip of the whole tblCellMar XML fragment. Change-Id: I41c5afd6b1cfa7322f5f1bd8c44ed6bffe10eb41
-
Stephan Bergmann yazdı
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 122a1376 "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? 122a1376 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
-
Caolán McNamara yazdı
Change-Id: I99293a91018c130415bd3816fa23f44643512a74
-
Caolán McNamara yazdı
Change-Id: Iec4b0d041ec0389630d21572d6c5658639d85b17
-
Caolán McNamara yazdı
Change-Id: I0494f06ec8709fdf33ace6772823d7b986ff5847
-
Caolán McNamara yazdı
Project: help 4327d90e23cba2f2829a4d2bf0ed449fbeb92cdb
-
Michael Meeks yazdı
Change-Id: I0539e2708b973b8bea7bd63488277f00201c6c46
-
Stephan Bergmann yazdı
...otherwise e.g. during execution of sw/PythonTest_sw_python.mk workdir/*/LinkTarget/Library/libtest.dylib would not find workdir/*/LinkTarget/Library/libunotest.dylib without yet another addition to DYLD_LIBRARY_PATH. (Special cases where NONE libs are located somewhere else than workdir/*/LinkTarget/Library/ can be and are still found via DYLD_LIBRARY_PATH.) Change-Id: Ia301746842ef49393d0229915c01b61e378ca100
-
Michael Stahl yazdı
Project: help bb440434d0561b291c73cf467c16e803934b8abb
-
Stephan Bergmann yazdı
Change-Id: I32b9d2398d2d734a0d96c937b2238d8ff9a74ef7
-
Caolán McNamara yazdı
Change-Id: I6104ee3bb0928275a0e4ffb9a7ca1be37ebc1f9e
-
Michael Stahl yazdı
Change-Id: I69e75dbbaa16b6dc407a69ba8137c09888db50ce
-
Michael Stahl yazdı
Change-Id: I9d1267d6fc14a3149fb92a486bee3023a531e574
-
Michael Stahl yazdı
Change-Id: Ia31a6f56fd8347f6fc50677e86a414f4c5ed81b1
-
Michael Stahl yazdı
Change-Id: I4b967187bca35527a3c3d718952ae0a3ae6ebae9
-
Michael Stahl yazdı
Change-Id: I1e7a75ad4c8d35cb6adef8d6c4104f1955ad4574
-
Miklos Vajna yazdı
This allows e.g. storing a table style's w:tblPr -> w:tblInd -> w:type. Change-Id: I653edc8912ce4e61c703bfffc6e3dcf322295b6f
-
Miklos Vajna yazdı
This allows to store keys in table style's tblPr (no contents yet). Change-Id: I2aa80c8bee3f76a7c0090407f97156e3e3061a1d
-
Miklos Vajna yazdı
With this, we can store tblPr (itself, not yet its child elements) inside table styles. Change-Id: I7e9008fec566e73c50c4ccfc565fd0e8a3293998
-
Miklos Vajna yazdı
And also add a method stub where contents will be preserved as well. Change-Id: Ide52102d1bdf6bf9d73b84ed6760f2b1e086a805
-
Eike Rathke yazdı
Change-Id: I3aba3f85face62e0b8d54aebb92412c350aa2923
-
Eike Rathke yazdı
Change-Id: Ie2aadab8302f365379a569989bd9640db55b9716
-
Eike Rathke yazdı
... to hopefully be able to generate a diff when the next release of MS-LCID.pdf will be available at http://msdn.microsoft.com/library/cc233965.aspx Change-Id: I10877cdc8d4b90c6b971dfa5e05ad796fd2a2d00
-
Eike Rathke yazdı
... as downloaded from http://msdn.microsoft.com/library/cc233965.aspx Change-Id: I07f81ca0d6230c38f1f80f93f262debdf939ca87
-
Caolán McNamara yazdı
as opposed to "hyperlink". Be more generic and consistent across both ctrl+click and click modes. Change-Id: I673ed59fc9f3408a0c4534c6490d9bbc3598bc08
-
Caolán McNamara yazdı
Change-Id: Idf0fee94ef2c360ce509b34a2828022a8daf04d0
-
Caolán McNamara yazdı
when link is in a toc, and Cursor in protected areas is disabled, causing the cursor to leap before the toc before trying to see what's under the cursor in order to jump to it Change-Id: Iaf348e3621df02628b4d2ac8c1165df7082237ed
-
Tor Lillqvist yazdı
Change-Id: I37a5edbc578a71cb7eba29c3191cfa36e90ca022
-
Tor Lillqvist yazdı
Makes it more obvious to the code reader that nothing wrong is going on (or the compiler would have complained). Change-Id: I2ab420ffeb71f5c0b68e1b7db039cb9cde6af801
-
Tor Lillqvist yazdı
Change-Id: Ia8a47bcd07cf10302b5cf6f550627e5c7cd1d9f6
-
Tor Lillqvist yazdı
Change-Id: I202ab418d2cf0d4f0f9d7786fec837dd76abd7b5
-
Caolán McNamara yazdı
Change-Id: I156c2a2d645c140bfd716f41d8c81c0656ceee56
-
Laurent Godard yazdı
Change-Id: I8f26c75ac6d95f584e649fb7acf637394129ba44 Reviewed-on: https://gerrit.libreoffice.org/6414Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
-
Ptyl Dragon yazdı
Change-Id: Ic9d972fd67123e3ab04f023806f7f96c89a883a7
-
Ptyl Dragon yazdı
Change-Id: I4b350dc6c796bb1af0740917e17ac79b2a259a0a
-