[libvoikko] libreoffice-voikko 3.2rc1

[Flammie Pirinen]

Harri Pitkänen kirjoitti 17.2.2011 kello 18.45:

>> My guess
>> is that since this is not the standalone version and I didn't include
>> the linked libraries it might be needing them. I wonder if the
>> libraries should be in the oxt file even in this version?
>
> It might have been that the absolute path of libvoikko.dylib is  
> encoded by
> default within the component library (voikko.dylib). So it won't be  
> found even
> if you include libvoikko.dylib within the extension unless you fix  
> that path
> or use a fixed installation location for libvoikko.dylib. See manual  
> pages for
> otool and install_name_tool on how to change the path. I suspect  
> that the
> solution is there if it can be solved at all, but I could not get it  
> working
> when I tried that years ago.

Well indeed it seems that 1) the autoconf-libtool combination will  
create libraries with whole path included in the name and 2) this is  
used in the dylib that gets made for the plugin. I suppose it is  
possible to copy all the libraries and make their name same as  
plugin's dylib's, I nevertheless feel that it defeats the whole  
purpose of dynamic linking and provides no improvement to easier  
static linking process, since updating the library inside the plugin  
is not much easier than installing new version of whole plugin  
altogether. As for one coming from linux world I would expect a  
possibility to have such dynamically linked plugin that will pick up  
new and updated libraries from system, but this doesn't seem like  
common practice in Mac software?

> Another thing is that if you build the extension on a given version  
> of OS X it
> won't run on anything older than that. There is a way to fix that,  
> you need to
> link against some older compatibility libraries that come with the  
> operating
> system SDK. This probably needs to be done for both libvoikko and  
> libreoffice-
> voikko. I have never done that but it should be possible. Again  
> otool will
> help you check what version of C/C++ runtime libraries are required  
> to run the
> resulting library.

Ok, I'm still with 10.5 so it shouldn't be a big problem for most  
users, but is something to look out for in the future. If it's only  
changing the library names it should be relatively trivial with  
library_name_tool.