<div dir="ltr">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? </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Apr 9, 2013 at 11:57 AM, Michael Meeks <<a href="mailto:michael.meeks@suse.com" target="_blank">michael.meeks@suse.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:tomas.chvatal@gmail.com">tomas.chvatal@gmail.com</a>> 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: <a href="https://gerrit.libreoffice.org/3280" target="_blank">https://gerrit.libreoffice.org/3280</a> 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. -- <a href="mailto:michael.meeks@suse.com">michael.meeks@suse.com</a> <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list <a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </blockquote></div> -- Jonathan Aquilina </div>