Hi Wolfgang,
I'm back on this issue... after we were able to solve other GNUstep
issues in the meanwhile and I didn't have to use Ubuntu for a bit.
I did some further test, let me explain better.
Wolfgang Lux wrote:
On Ubuntu I have a also a similar issue: PDFKit compiles fine, but then it
fails to resolve symbols.
>The actual library is located in:
>
>/usr/lib/i386-linux-gnu/libfreetype.so
>
>However:
>$ freetype-config --libs
>-lfreetype
>
>I wonder i there is a bug, like a missing symlink in Ubuntu? or a bug in
freetype-config?
>
>I don't have clean workaround like in OpenBSD: I do not know how to guess the
actual directory (architecture dependent) and also how to detect I am running on
Linux, Isince the TARGET_OS is linux and on other linux systems it works fine.
>
>Any opinions? Any ubuntu experts?
As Fred mentioned the output of freetype-config is correct (on my Ubuntu 16.04
there's /etc/ld.so.conf.d/i386-linux-gnu.conf, which makes sure that
libfreetype should be found). If you get linking errors then I'd suspect that
either you haven't installed the libfreetype6-dev package (the .so file doesn't
contain any symbols, they are present in the corresponding .a file, which is
part of the -dev package) or there's an issue with the order of libraries on
the command line.
I can get things to work&link this way
1) compile PDFKit against freetype with the standard freetype-config
--libs options, which would be -lfreetype, this completes without error
2) when using PDFKit (in this case GWorkspace) I need to again add
-lfreetype to be able to link against PDFKit
I think the above confirms that I have all necessary dev packages and
libraries installed (which I shoul have by a check).
Do you think this behaviour is correct? I would prefer not to "expose"
the fact that PDFKit links against freetype, or every usage of it needs
to be aware of it. I would like to avoid that.
On OpenBSD and NetBSD I can use -Wl,-rpath=<path> to embed a search
path, I tried this on Ubuntu but it did not help (besides, I hacked it
in, but it should be actually done architecture aware). Am I on the
wrong way to solve this issue (for you German, the "wooden path"). Or is
this behaviour simply expected on Ubuntu and maybe other platforms now?
Riccardo
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep