[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/48742: Building fontconfig fails with undefined reference to FcDirCacheRescan
The following reply was made to PR pkg/48742; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
Subject: Re: pkg/48742: Building fontconfig fails with undefined reference to
Date: Sat, 27 Dec 2014 01:48:40 +0000
(sorry I didn't answer this sooner)
On Mon, Jun 09, 2014 at 10:15:01AM +0000, Ian D. Leroux wrote:
>> On Sun, Apr 13, 2014 at 02:45:00PM +0000, idleroux%fastmail.fm@localhost wrote:
>>> CCLD fc-cache
>>> fc-cache.o: In function `scanDirs':
>>> fc-cache.c:(.text+0x1f7): undefined reference to
>>> `FcDirCacheRescan' Makefile:474: recipe for target 'fc-cache'
>>> failed gmake: *** [fc-cache] Error 1
>> This is caused by mixing native and pkgsrc X. Don't do that...
> As far as I know, I run strictly native X, and I ran into this in a
> freshly created pkg_comp chroot so there shouldn't have been any cruft
> from past mistakes lying around. As I see it, there are two
> possibilities: Either fonts/fontconfig is only useful with modular X
> and it had no business being built on my native-X system, or
> fonts/fontconfig is (potentially) useful with native X.
In general it's not useful with native X. However, for some pieces of
X, on some platforms, pkgsrc likes to build the pkgsrc version anyway,
because it thinks the native version is too old. This is not handled
well, and there's a long history of lossage arising from it.
One of these pieces is in fact fontconfig.
(For background: the basic problem is that after certain updates
pkgsrc gratuitously insists that the native version is no older than
the pkgsrc version. This is to (attempt to) avoid certain problems
that can arise in the presence of incompatible shared library changes;
but it's a very blunt hammer.)
> If pkgsrc fontconfig is not meant to be used with native X, then I'm
> perplexed that it got pulled in as a dependency while building
> packages for native X. I think I was trying to build firefox24 when I
> first tripped over this, back in April. However, I've just
> successfully built all the packages I care about from a pkgsrc tree
> checked out yesterday (2014-06-08) and fontconfig was not required, so
> if there was a bug in the dependencies it's gone now. In this case we
> can close the PR.
> If pkgsrc fontconfig is expected to build on a native-X system, then we
> still have a bug that I can reproduce in a fresh pkg_comp chroot, with
> nothing in /etc/mk.conf beyond what pkg_comp puts there itself. The
> bug doesn't affect me personally, but since I can reproduce it
> systematically I'm happy to help investigate if anyone else cares about
That is, as far as I know, a bug. The pkgsrc fontconfig builds ok for
me on -current and on -5 (don't have a -6 build box) though not in a
chroot, so maybe the problem is something that pkg_comp is doing
Anyhow, the linker error is caused by compiling against the current
version's header and linking to the older native library. It's easy
for this to happen when trying to build it against native X: x11-links
causes all the X libs it knows about to be buildlinked at once, and
that includes the native fontconfig library. So if something happens
in the wrong order on the command line, the wrong fontconfig library
comes up first and then everything fails.
Check work/.work.log to see what it's actually doing when trying to
link fc-cache. This is from mine just now:
--tag=CC --mode=link gcc -O2 -I/usr/pkg/include -I/usr/include
-I/usr/X11R7/include/freetype2 -L/usr/pkg/lib -L/usr/lib
-Wl,-R/usr/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib
-Wl,-R/usr/pkg/lib -o fc-cache fc-cache.o ../src/libfontconfig.la
<.> /usr/pkg/bin/libtool --silent --tag=CC --mode=link gcc -O2
-Wl,-R/usr/X11R7/lib -Wl,-R/usr/pkg/lib -o fc-cache fc-cache.o
The [*] lines are what's presented to the pkgsrc wrappers; the <.>
lines are what's actually run.
If yours is different, that's probably the problem (especially if
there's something obviously suspect in it) ... if not, the problem is
probably inside libtool.
Also make sure that the x11-links and libtool-base packages pkg_comp
is using are up to date.
> Is there currently a mechanism for indicating or even enforcing that
> certain packages are modular-X-only? In some cases its obvious, but
> for something like fontconfig (whose DESCR explicitly states that it is
> independent of X), it's not.
Not one that works :-|
David A. Holland
Main Index |
Thread Index |