Re: Ubuntu freetype link problem PDFKit

[Riccardo Mottola]

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