[libvoikko] Libreoffice-voikko build broken on MacOSX

Sjur Moshagen sjurnm at mac.com
Thu May 30 15:38:31 EEST 2013

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 \

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:

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.


More information about the Libvoikko mailing list