[Libreoffice] prefix bits ...

[Matúš Kukan]

I'm sorry about not CCing last message.

On 15 June 2011 21:47, Michael Meeks <michael.meeks at novell.com> wrote:
>
> On Wed, 2011-06-15 at 13:13 +0200, Matúš Kukan wrote:
>> What do you mean by testing? So far I have just a little knowledge of
>> what I'm doing.
>
>        Oh - we need to check the toolkit components really still work and are
> activated correctly when we try to use the toolkit pieces. ie. try
> dropping some GUI/form controls (buttons etc.) onto a spreadsheet - if
> that works, we're fine :-)
>
I have problems with customize options. Tools -> Customize.. ->
Toolbars or Events tab -> crash.
But I don't know if this is toolkit related and caused by my patch.

>> Did you mean which libraries are loaded?
>> Mostly bootstrap.uno.so, stocservices.uno.so, configmgr.uno.so,
>> libvclli.so, libfwkli.so and others.
>
>        Sure - so it is easy to get this data;
>
>        Just do:
>
>        LD_DEBUG=files ./soffice.bin -writer 2>&1 | tee /tmp/log
>
>        and some sedding on that should get us a nice list of library names.
>
We want just to get all the library names?

>> And then somehow change that and merge some libraries?
>
>        Lets defer the merging until we have list of what to merge.
>
>        Oh - and can you CC the dev. list on all these mails ? :-)
Sorry about that.

>> I will try to describe how I understand this. We want to use some
>> service, so we know its implementation and in which component it is.
>> So we load some library and use it.
>
>        Sure :-) of course, if it is already loaded, then 'dlopen' just
> succeeds instantly, and there is ~no cost.
>
>> And if we want another service we must unload the first library and
>> load other. (if they differ).
>
>        Nah - but we have to load another library - which is a pain, causes
> seeks on the disk, and also means we can't optimise ordering of sections
> inside shared objects, and more that we can do with fewer, bigger DLLs.
> Firefox is (mostly) just one huge dll FWIW - and we want to move closer
> to that,
>
>        Is that clearer :-)
>
Sure, thanks.

I'm also sending patches. But I created them in my second workdir.
I have recently done ./g pull -r there.
And I'm getting the same error as last time:
dllcomponentloader.cxx:(.text+0x1bf): undefined reference to
`cppu::loadSharedLibComponentFactory(rtl::OUString const&,
rtl::OUString const&, rtl::OUString const&,
com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory>
const&, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey>
const&)'
collect2: ld returned 1 exit status

But this time I'm not successful with that. In my older workdir I just added
_ZN4cppu29loadSharedLibComponentFactoryERKN3rtl8OUStringES3_S3_RKN3com3sun4star3uno9ReferenceINS6_4lang20XMultiServiceFactoryEEERKNS8_INS6_8registry12XRegistryKeyEEES3_
into cppuhelper/source/gcc3.map. But It's not working now this way.
I found that string with objdump -T
./solver/350/unxlngi6.pro/lib/libuno_cppuhelpergcc3.so.

Thanks,

Matus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Start-using-toolkit-component-prefix.patch
Type: text/x-patch
Size: 1927 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110616/d1069aca/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-prefix-information-about-component-into-registry.patch
Type: text/x-patch
Size: 6596 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110616/d1069aca/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Allows-using-prefix-information-about-component.patch
Type: text/x-patch
Size: 9587 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110616/d1069aca/attachment-0005.bin>