[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ubuntu freetype link problem PDFKit
From: |
Wolfgang Lux |
Subject: |
Re: Ubuntu freetype link problem PDFKit |
Date: |
Sat, 18 Mar 2017 19:54:20 +0100 |
Hi Riccardo,
>
> 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
my understanding is that you should not need 2). Having a closer look at PDFKit
it seems the problem is the order of link arguments in the PDFKit
GNUmakefile.in, which effectively means you are not linking the PDFKit
framework at all with the freetype-config --libs option. Note that the order of
arguments on the linker command line is important. In particular any -l options
MUST follow the object files that use the respective libraries, otherwise those
libraries are simply not used during linking. So, instead of
ADDITIONAL_LDFLAGS += $(LIB_FREETYPE_LDFLAGS)
ADDITIONAL_LDFLAGS += $(XPDF_OBJ_FILES) -lm
you should use
ADDITIONAL_LDFLAGS += $(XPDF_OBJ_FILES) -lm
ADDITIONAL_LDFLAGS += $(LIB_FREETYPE_LDFLAGS)
Wolfgang