If we are planning to try and modularize each aspect of LO to the point where it could be built on its own with out the rest of the suite, wouldnt it be best to merge libs that have to do with their appropriate apsect of the program writer has all its respective libs merged, and then anything that is common to all aspects has its own merged lib with just the common libs etc?
On Tue, Apr 9, 2013 at 11:57 AM, Michael Meeks <michael.me...@suse.com>wrote: > Hi guys, > > On Mon, 2013-04-08 at 17:08 -0400, Peter Foley wrote: > > On Mon, Apr 8, 2013 at 10:19 AM, Tomáš Chvátal <tomas.chva...@gmail.com> > wrote: > > > This switch all/core/no sound pretty cool. > > > Libreoffice is currently built with mergedlib enabled on opensuse and > gentoo > > > in production and there are no visible issues (currently master fails > tests > > > [so i turned off my tinderbox after having it fail for a week] but hey > the > > > app still runs fine). > > > > Right now libmerged seems to be causing very strange crashes in the unit > tests. > > I'm trying to figure out what exactly is going wrong, but any help > > would be appreciated. > > IMHO we really do need a small re-think here; the primary use-case > I > was aware of for libmerged is to enable more LTO, and faster start-up. > > I rather suspect that merging all the components: base, writer, > calc > etc. into the libmerged may not help startup on lots of hardware; so I'm > curious as to the plan there. > > If we break the unit tests by doing that, almost certainly we'll > break > the run-time functionality too :-) so - prolly rather better to back > that stuff out until it works. So I'll merge this: > > https://gerrit.libreoffice.org/3280 > > Peter - any chance of tweaking your use-case to include those > libraries > that you want merged in there (assuming you do) conditionally with a > non-default configure switch as Matus suggests ? > > I believe Matus is trying to get this into a more reliable and > ship-able state for Raspberry Pi, so until we've nailed the regressions > and thought this through some more, I'd prefer to take a step back and > re-think if that's ok ? > > Peter - did you get any further with the graphics filters ? at some > stage, I suspect that they are doing some oslLoadModule to load the > graphics driver pieces - that might be going wrong. > > If there is some symbol overlap problem, you could try to find that > like this: > > for a in *.so; do echo $a ; readelf -s $a --wide | grep -v UND | cut > -c52-; done > /tmp/symbols.txt > sort /tmp/symbols.txt | uniq -c | sort -n | less > > I'd start by using readelf --dyn-syms perhaps and then use -s if > that > fails; of course you want to reverse grep _ZThn and _ZTV etc. and > manually ignore inlined methods which are expected to be duplicated but > are hopefully the same everywhere (due to the ODR). > > Beyond that - debugging, and careful unwinding back to what is > going > wrong with image load/export would be good - I'd use gdb to see where > your pointer got corrupted (IIRC I gave some pointers to that in the > past on the list?). > > HTH, > > Michael. > > -- > michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot > > _______________________________________________ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- Jonathan Aquilina
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
