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.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
