[libvoikko] Libreoffice-voikko build broken on MacOSX

[Sjur Moshagen]

29. mai 2013 kl. 23:33 skrev Harri Pitkänen <hatapitk at iki.fi>:

> Something like this would hopefully do (I can't test this so check for typos 
> and correct line breaks etc.):

It didn't make a difference.

What it seems to boil down to is that both the dynamic libraries extended linking AND a regular -l linking flag is needed.

That is, with the following makefile:



        -luno_cppuhelpergcc3 -luno_cppu -luno_sal \
        -Wl,-dylib_file, at loader_path/libuno_cppuhelpergcc3.dylib.3:'/Applications/LibreOffice.app/Contents/ure-link/lib/libuno_cppuhelpergcc3.dylib' \
        -Wl,-dylib_file, at loader_path/libuno_cppu.dylib.3:'/Applications/LibreOffice.app/Contents/ure-link/lib/libuno_cppu.dylib' \
        -Wl,-dylib_file, at loader_path/libuno_sal.dylib.3:'/Applications/LibreOffice.app/Contents/ure-link/lib/libuno_sal.dylib' \
        -lvoikko \
        -lhfstospell \
etc.


I get the following linking messages:


ld: warning can't open dynamic library: /Applications/LibreOffice.app/Contents/ure-link/lib/libuno_cppu.dylib referenced from: /Users/adminis//macosx/lib/libuno_cppuhelpergcc3.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
...
__ZN9salhelper21SimpleReferenceObjectD2Ev referenced from @__________________________________________________URELIB/libuno_cppuhelpergcc3.dylib.3 expected to be defined in @loader_path/libuno_salhelpergcc3.dylib.3
__ZN9salhelper21SimpleReferenceObjectdlEPv referenced from @__________________________________________________URELIB/libuno_cppuhelpergcc3.dylib.3 expected to be defined in @loader_path/libuno_salhelpergcc3.dylib.3
...


whereas if I remove the line:

        -luno_cppuhelpergcc3 -luno_cppu -luno_sal \

from the make file all symbol references become unknown:


ld: Undefined symbols:
__ZN4cppu25component_writeInfoHelperEPvS0_PKNS_19ImplementationEntryE
__ZN4cppu26component_getFactoryHelperEPKcPvS2_PKNS_19ImplementationEntryE
__ZN4cppu28createSingleComponentFactoryEPFN3com3sun4star3uno9ReferenceINS3_10XInterfaceEEERKNS4_INS3_17XComponentContextEEEERKN3rtl8OUStringERKNS3_8SequenceISE_EEP16_rtl_ModuleCount
_rtl_allocateMemory
_rtl_freeMemory
_rtl_uString_assign
...



This got me thinking: all the messages of the inability to open dynamic libraries and symbol X referenced from dylib Y could probably be ignored, and I should only concentrate on fixing the missing symbols from the static libraries that hfst-ospell depend on.

Is it possible that the whole thing will work despite the dylib messages, as long as I can fix the other linking issues (they are (hopefully) manageable)?


> Not necessarily. But you will likely need to add some compiler switches. 
> Googling for this suggests the following:
> 
>  -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5

Yes, thanks for the reminder, I used those when building both hfst-ospell and libvoikko.

Sjur