This repository has been archived by the owner. It is now read-only.

Fontforge: incorrect hardcoded paths #15258

Closed
cdlm opened this Issue Oct 2, 2012 · 15 comments

Comments

Projects
None yet
7 participants
Contributor

cdlm commented Oct 2, 2012

Fontforge loads at least up to the splash screen and open dialog, but complains about not finding libpng and libpango:

libpango: dlopen(/opt/local/lib/libpango-1.0.0.dylib, 1): image not found
libpng: dlopen(/opt/local/lib/libpng.2.dylib, 1): image not found

(there are a bunch of the libpng messages)

10.8.2, homebrew installed in /opt/homebrew (note that above it says /opt/local, not even /usr/local)

Member

mxcl commented Oct 3, 2012

Do you have anything in /opt/local that is causing fontforge to think these files may exist during the build?

Contributor

cdlm commented Oct 3, 2012

@mxcl no, I just have /opt/X11 from XQuartz, and /opt/homebrew

About reporting it upstream, I'm really not a C expert, and not even sure it's fontforge's fault; I tried looking with otool but didn't see these library loads.

Contributor

jacknagel commented Oct 3, 2012

They won't show up in otool output because it is using dlopen() to load them.

Was there stuff in /opt/local previously?

Contributor

2bits commented Oct 3, 2012

And what options did you give to Fontforge when you brewed it? --with-cairo --with-pango?
How are you trying to run Fontforge? From the terminal? As an app?

Contributor

jacknagel commented Oct 3, 2012

Okay, I can reproduce this and I've certainly never had anything in /opt/local. Rebuilding it now.

Contributor

mistydemeo commented Oct 3, 2012

It looks like this was reported on the Fontforge mailing list (with reference to Homebrew) in July with no resolution: http://sourceforge.net/mailarchive/forum.php?thread_name=6CE9127677A14D3C900A544B28BFFBEC%40googlemail.com&forum_name=fontforge-devel

Contributor

cdlm commented Oct 3, 2012

@2bits /opt/homebrew/Cellar/fontforge/20120731 (377 files, 16M) * Installed with: --with-x, --with-libspiro, --with-pango, --with-cairo

The whole OS is a fresh install. I saw the message when I ran fontforge from the command line.

@mistydemeo Ok (sorry, I failed to check that…)

Contributor

2bits commented Oct 3, 2012

Weird that Jack can reproduce it, but I can't. Still trying various combinations of python & options.

Contributor

cdlm commented Oct 3, 2012

My python is the OS X one; I can build the homebrew one and try fontforge again.

Contributor

2bits commented Oct 3, 2012

You can try, sure. I just removed all my brews and wiped my site-packages. Then I installed fontforge with all the options like you did. When I run it from the command line I get this error:

$ fontforge
Copyright (c) 2000-2012 by George Williams.
 Executable based on sources from 14:57 GMT 31-Jul-2012-D.
 Library based on sources from 14:57 GMT 31-Jul-2012.
fontforge(50622,0x7fff7a704180) malloc: *** error for object 0x7f94d1c617c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Sorry about these hassles. We worked pretty hard to get fontforge working, but these things happen. It's probably the new pagno, I don't know. It does work for me if I don't use --with-pango. I have XQuartz 2.7.4 installed btw.

Contributor

mistydemeo commented Oct 4, 2012

The relevant source is here: http://fontforge.git.sourceforge.net/git/gitweb.cgi?p=fontforge/fontforge;a=blob_plain;f=gutils/dynamic.c;hb=557bcefbbcdf5139cb226f0462bbd4928b31d5f2

It does in fact hardcode /sw/lib/ and /opt/local/lib as its dlopen paths.

The entirety of dynamic.c is gone in git head though; it looks like dlopen is no longer used.

vxbush commented Dec 1, 2012

Is there a fix for this problem? I'm seeing exactly the same error messages in 2bit's comments. Alas, I am only now getting up to speed with homebrew so I'm not sure when or where I need to avoid the --with-pango option.

Contributor

adamv commented Jan 8, 2013

MacPorts has a patch, for an older version: https://trac.macports.org/browser/trunk/dports/graphics/fontforge/Portfile

We ought to be able to adapt it.

Contributor

adamv commented Feb 9, 2013

So I can't actually adapt this patch because it is trying to load multiple keg-only paths, and there's no one folder we can point to that contain these.

Contributor

adamv commented Feb 23, 2013

Since we're not going to carry a patch that tries dlopen across all of our keg-only folders, closing this in favor of "try the --HEAD build."

Willing to review someone else's patch though.

@adamv adamv closed this Feb 23, 2013

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.