discuss-gnustep
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]