Bug 392979 – media-gfx/fontforge-20110222-r1 fails to compile on x86-macos

• Status: RESOLVED OBSOLETE
• Product: Gentoo/Alt

[Description MATSUI Tetsushi 2011-12-03 04:16:00 UTC]

media-gfx/fontforge-20110222-r1 fails to compile on x86-macos.

First problem is that pthread related function is used without ifdef macro in gioftp.c.
Second problem after fixing the first is undefined symbols.

[Comment 1 MATSUI Tetsushi 2011-12-03 04:17:45 UTC]

Created attachment 294559 [details]
modified ebuild

Here is my attempt to solve the problems.

[Comment 2 MATSUI Tetsushi 2011-12-03 04:19:29 UTC]

Created attachment 294561 [details, diff]
fontoforge-20110222-gioftp-pthread.patch

patch to fix the first problem.

[Comment 3 Fabian Groffen 2011-12-03 10:35:51 UTC]

Not sure actually skipping locking is a good fix.  Besides, you're on Darwin, pthread_mutex_lock should exist, the code probably forgot a #include <pthread.h>.

[Comment 4 MATSUI Tetsushi 2011-12-03 12:04:43 UTC]

(In reply to comment #3)
> Not sure actually skipping locking is a good fix.  Besides, you're on Darwin,
> pthread_mutex_lock should exist, the code probably forgot a #include
> <pthread.h>.

I understand your worry.
But, if I have pthread.h and configure detects it,
then my patch has no effect, doen't it?

The pthread.h is actually included in gioP.h with #ifdef HAVE_PTHREAD_H,
which is included in gioftpP.h, which is included in gioftp.c.

Well, OK, I will try to read configure that seems to fail to detect pthread on Darwin.

[Comment 5 Fabian Groffen 2011-12-03 12:36:45 UTC]

Ah, yes.  If pthread is included conditionally, then they can't rely on its functions, indeed.

However, in your case pthread should be there, so you don't need to fix this problem for upstream ;)

[Comment 6 MATSUI Tetsushi 2011-12-03 12:56:38 UTC]

I found that the detection failure was caused by my mistakenly set LIBS.
So, yes, we can ignore the patch.  The only problem for us is the linker errors.

[Comment 7 Fabian Groffen 2011-12-04 09:05:03 UTC]

what linker errors?

[Comment 8 MATSUI Tetsushi 2011-12-04 12:47:40 UTC]

Created attachment 294705 [details]
log (original ebuild)

showing the failure at gioftp.c

[Comment 9 MATSUI Tetsushi 2011-12-04 12:49:18 UTC]

Created attachment 294707 [details]
log (after only patch)

I know the patch is unnecessary but, this shows the undefined symbols.

[Comment 10 Fabian Groffen 2011-12-04 12:51:03 UTC]

-pthread

[Comment 11 MATSUI Tetsushi 2011-12-04 12:59:43 UTC]

Two logs shows how builds fail.

On the way to reproduce the log (again), I recognize that the strange LIBS
problem is caused in configure.  If configure is run without --with-python-lib,
it tries to guess what it should be; the code

PyLib=`$python_prog -c "import distutils.sysconfig ;
print(distutils.sysconfig.get_config_var('LIBPL') + '/' +
distutils.sysconfig.get_config_var('LDLIBRARY'))"`

is used and detect, at least on my environment, the messing path:

$ python -c "import distutils.sysconfig ;
print(distutils.sysconfig.get_config_var('LIBPL') + '/' +
distutils.sysconfig.get_config_var('LDLIBRARY'))"
/Users/tetsushi/Gentoo/usr/lib/python2.7/config/

On time I wrote the last comment, I stopped using the patch on gioftp.c but
continued to use other part of the modified ebuild, which pass
--with-python-lib, luckily avoiding the configure's misbehavior.  It's an
upstream bug that can be ignored, if we set --with-python-lib as in the
attached ebuild.

[Comment 12 MATSUI Tetsushi 2012-05-31 12:28:59 UTC]

Created attachment 313711 [details]
modified ebuild

[Comment 13 Mike Gilbert 2017-08-20 01:53:16 UTC]

Please re-open this if the issue occurs with current versions of fontforge.