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):
perfect, fails every time.
Steps to Reproduce:
1. start computer
2. start program
3. crash on startup
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
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 >= 2.9.1
$ rpm -q freetype
$ 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 ***
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
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.
(In reply to Akira TAGOH from comment #1)
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
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.
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.)
"dnf remove freetype-freeworld" fix this bug for you ?
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.
I never had freetype-freeworld installed,
$ rpm -qa | grep freetype
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.
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.]