Bug 1645237 - libfontconfig.so.1: undefined symbol: FT_Done_MM_Var
Summary: libfontconfig.so.1: undefined symbol: FT_Done_MM_Var
Keywords:
Status: CLOSED DUPLICATE of bug 1579464
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-01 17:28 UTC by gj
Modified: 2018-11-08 14:59 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-05 09:24:51 UTC
Type: Bug


Attachments (Terms of Use)

Description gj 2018-11-01 17:28:23 UTC
Description of problem:
release of FC29 breaks the major scientific package ccp4. All graphical components (for example the program coot) crash.

Version-Release number of selected component (if applicable):
fontconfig.x86_64                    2.13.1-1.fc29 

How reproducible:
perfect, fails every time.

Steps to Reproduce:
1. start computer
2. start program
3. crash on startup

Actual results:
error message: /disk1/jogl/xsoft/ccp4-7.0/ccp4-7.0/libexec/coot-bin: symbol lookup error: /lib64/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var

Expected results:
functional program

Additional info:

Comment 1 Akira TAGOH 2018-11-05 09:24:51 UTC
That symbol is provided by freetype-2.9.1 or later and fontconfig has proper dependency to it:

$ rpm -q --requires fontconfig | grep freetype
freetype
freetype >= 2.9.1
libfreetype.so.6()(64bit)
$ rpm -q freetype
freetype-2.9.1-3.fc29.x86_64
$ readelf -s /usr/lib64/libfreetype.so.6 | grep FT_Done_MM_Var
   124: 000000000001c990    38 FUNC    GLOBAL DEFAULT   12 FT_Done_MM_Var

*** This bug has been marked as a duplicate of bug 1579464 ***

Comment 2 schlaffi 2018-11-05 11:09:22 UTC
Same problem here with a 3rd party proprietary software.

I am not sure how Akiras answer contributes to solving the issue, because

$ objdump -p /lib64/libfontconfig.so.1 | grep NEEDED
  NEEDED               libfreetype.so.6
  NEEDED               libexpat.so.1
  NEEDED               libuuid.so.1
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6

so, libfreetype should be loaded together with libfontconfig.

It is a really bad surprise if one upgrades and an essential tool that one uses stops working. I know it is 3rd party...but still it occurred in the fedora upgrade.

Comment 3 Sergio Basto 2018-11-06 00:02:06 UTC
(In reply to Akira TAGOH from comment #1)
> freetype-2.9.1-3.fc29.x86_64

Since freetype-2.9.1-4.fc29.x86_64 Fedora enable ClearType code after Microsoft joining OIN and freetype-freeworld is not needed anymore and was removed from RPMFusion.

With freetype-2.9.1-3.fc29.x86_64 , you should not have freetype-freeworld counterpart updated, so you get this error, at least I saw this error when it happened to me. 

i.e this might be a race condition between repos and should be fixed with freetype-2.9.1-6

Comment 4 Akira TAGOH 2018-11-07 05:33:10 UTC
How our package behaves doesn't matter. you should understand your own risk when you are going to install 3rd party package, particularly conflicting with our own. that would breaks the assumption of packaging system easily like deps added to avoid this error unless 3rd party doesn't follow the original. if you can't address the sort of this by yourself, you shouldn't touch them.

Comment 5 schlaffi 2018-11-07 09:13:11 UTC
I just think this one should not be closed as a CLOSED DUPLICATE, because the issue is new and still exists. If you feel that this is none of your business as a distro provider, I would have expected a WONTFIX.

However, I think there is something wrong here in the distro, because things are apparently setup correctly, but the symbol is not resolved. It seems that there is something wrong with the fontconfig/freetype combo and the history with this problem suggests to me that there is.

(Please understand the situation. These 3rd parties have slow upgrade cycles, because this is huge software. This means that I currently will not be able to use Fedora 29 and possibly run into EOL of Fedora 28 before it is fixed at their end. So, I think reporting this is useful for you as distro maintainer, how you use this information is of course up to you.)

Comment 6 Sergio Basto 2018-11-08 00:47:48 UTC
"dnf remove freetype-freeworld" fix this bug for you ?

Comment 7 Akira TAGOH 2018-11-08 04:20:49 UTC
There are nothing wrong in distro. in fact this won't happens on clean install or even upgrading from f28 say. the problem happens only when you broke your box with freetype-freeworld apparently. and that package has a trick to use it prior to the original freetype library and the problem here is freetype-freeworld provides *similar* functionality but not compatible unfortunately. this is totally out of our responsibility. we don't know what you use. so you have to pay attention carefully for about what happened and report a problem as needed to the appropriate place. I don't think here is first place for you, at least for this.

If you don't like DUPLICATE, what I can do so far is only to update the dependency to freetype-2.9.1-6 which has freetype-freeworld in Obsoletes line though, anyway, see Bug#1644700.

Comment 8 schlaffi 2018-11-08 12:10:35 UTC
I never had freetype-freeworld installed,

$ rpm -qa | grep freetype
freetype-devel-2.9.1-6.fc29.x86_64
freetype-2.9.1-6.fc29.x86_64

Comment 9 Akira TAGOH 2018-11-08 12:28:55 UTC
No, you can't prove it with that because 2.9.1-6 has changes to replace freetype-freeworld. so you can't install both with it anymore. try this. you should have that symbol in library now:

$ readelf -s `rpm -ql freetype|grep -e "libfreetype.so.6$"`|grep FT_Done_MM_Var
   124: 000000000001d0b0    38 FUNC    GLOBAL DEFAULT   12 FT_Done_MM_Var

If you still have this issue with some apps, that would means they may have own freetype library bundled and mixing it up with system fontconfig library. that's not also our businness. ask them to update libraries then.

Comment 10 schlaffi 2018-11-08 14:59:26 UTC
Ahh, thanks for that hint. Yes, they heroically provide their own libfreetype...I guess they have to have it there for compatibility with other distros. I'll file a bug for them.

[For others running into it, this is how I patched it for the moment: I copied the still functional libfontconfig.so.1.11.1 from f28 to some cosy place and set LD_LIBRARY_PATH it.]


Note You need to log in before you can comment on or make changes to this bug.