Re: [Libreoffice] Using Inflater/Deflater classes from component/package - using component symbols

Hi Peter,

On Mon, 2011-03-21 at 22:57 +0000, Peter Jentsch wrote:
> after hibernating for a while I've started to finish where I left off in 
> removing the Java dependency from xsltfilter (was EasyHack De-Java-Ise 
> flat xml export).

        Wonderful news :-)

>  I've ported the Java code from XSLTFilterOLEExtracter 
> (sic) to C++ and found there's a generic C++ interface to zlib hidden in 
> component/package (components/package/source/zipapi). It features 
> Inflater/Deflater classes that work pretty much like the ones in the Java 
> runtime. I figured how to compile against that by delivering the header 
> files to solver, but fail to link against the libpackage2.so library that 
> seems to contain the classes.

        Ah - ok; so first off in the 'beautiful' theory of UNO components
mind-set that is a "bad idea" (TM) - on the other hand, I happen to not
believe in a beautiful world of UNO components - and tons of libraries
export both components and symbols that can be usefully re-used without
tons of inefficient time-wasting pain :-)

        So - lets go for it.

>  The Zip implementation also seems to be 
> exposed as a UNO service, but that assumes I'm working on complete zip 
> files, while the OLE embedding stuff xslt filter uses assumes it only 
> works on single deflated entries. 

        Well - if you are using a zip file underneath - I would suggest using
the existing package/ UNO interface - it is not particularly pleasant,
but you can see how the images.zip stuff works for the theme in some
fairly simple code in vcl/ sniff around vcl/source/gdi/impimagetree.cxx
(eg.).

> Should I try to rewrite the stuff to work on top of that service? Is there 
> a way to make Inflater/Deflater directly accessible to other code? I'm 
> stuck here and need some advice. 

        Of course; if you just have an individual compressed stream that you
want to work on I don't see why we can't export those symbols.

        The problem is the component.map file that is linked against; cf.
package/util/makefile.mk:

        SHL1VERSIONMAP=$(SOLARENV)$/src$/component.map

        This hides all symbols except a few C entry points for good performance
reasons. Checkout objdump -T <libpackage*> to see for yourself.

        If we want to selectively export symbols we need to do this
differently. See:

        sw/inc/swdllapi.h

        You need a header like that file inside package/ Then you need to add a
PACKAGE_DLL_PUBLIC to the symbols you want to export, and of course to
add a CFLAGS+=-DPACKAGE_DLLIMPLEMENTATION type thing in the
makefile.mk's where you're compiling that stuff.

        Then drop the map file in util/makefile.mk; and -hopefully- you have a
library that can be linked to & re-used easily.

        Hope that helps !

        Looking forward to seeing the fruit of your labour,

        ATB,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot