User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
cairo-1.15.10-5.fc29 works fine. cairo-1.15.12-1.fc29 causes bino (and gmplayer) to fail.
Steps to Reproduce:
[bruno@laptop1 ~]$ bino
bino: symbol lookup error: /lib64/libcairo.so.2: undefined symbol: FT_Done_MM_Var
A window for the program.
I run xfce for the desktop.
It has been reported that this problem does not affect f28. So perhaps the real issue is in freetype (or there is an API change) and the new cairo build picked up the error.
This is also blocking boot into a graphical interface. I'm not sure if this is new with a new build (e.g. xorg) or if I never booted with the bad cairo previously. Downgrading fixes the problem, but it is a bit of a pain to recover. Especially when grub2 doesn't recognize the control key on my macbook so I can't easily boot to a non-graphical system.
Booting into a graphical interface in openQA tests of current Rawhide appears to be working fine...
I had it happen on two different laptops. One was i686, the other x86_64. Both use XFCE. I saw an error message that looked like another true type function call error, but the function was different. Just reverting cairo (including a couple of other rpms from the same source package) fixed the problem. Maybe there is a missing dependency that isn't properly required.
Or it could be Xfce-specific? openQA doesn't test Xfce...
I tested rebooting my work desktop with cairo 1.15.12-1.fc29 and a graphical display never appeared, but I could use ctrl-atl-f2 to get to a vt. Supposedly the graphical target was running. Downgrading cairo made things work normally on the next boot.
I'll will look to see which display manager I use and see if that is also the same across all three machines.
I run lightdm on the laptops and lxdm on the desktop.
Given the problem seems to affect things before the desktop starts I wouldn't expect that to be restricted to xfce.
The display managers are different from each other, but neither is gdm, which is most likely to be tested. And I think that both gdm and and kdm get more attention so there could be a change that they account for that some others don't. So I'll test gdm and see what happens.
gdm had the same problem. It doesn't work with 1.15.12 and does with 1.15.10.
I ran startx from a vt and got the following:
[root@cerberus bruno]# startx
xauth: file /root/.serverauth.8299 does not exist
This is a pre-release version of the X server from Fedora Project.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 220.127.116.114 (1.20.0 RC 4)
X Protocol Version 11, Revision 0
Build Operating System: 4.15.3-300.fc27.x86_64
Current Operating System: Linux cerberus.csd.uwm.edu 4.17.0-0.rc1.git0.1.fc29.x86_64 #1 SMP Mon Apr 16 18:02:09 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.17.0-0.rc1.git0.1.fc29.x86_64 root=/dev/mapper/luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 ro rd.md.uuid=7f4fcca0:13b1445f:a91ff455:6bb1ab48 rd.luks.uuid=luks-cc6ee93c-e729-4f78-9baf-0cc5cc8a9ff1 rd.md.uuid=ef18531c:760102fb:7797cbdb:5cf9516f rd.md.uuid=42efe386:0c315f28:f7c61920:ea098f81 rd.luks.uuid=luks-f5e2d09b-f8a3-487d-9517-abe4fb0eada3 LANG=en_US.UTF-8
Build Date: 12 April 2018 03:27:17PM
Build ID: xorg-x11-server 18.104.22.1684-2.fc29
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 18 11:33:48 2018
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] Kernel modesetting enabled.
dbus: Unable to set up transient service directory: XDG_RUNTIME_DIR "/run/user/1000" is owned by uid 1000, not our uid 0
Failed to connect to bus: Operation not permitted
touch: cannot touch '/root/.cache/imsettings/log': No such file or directory
/usr/libexec/gnome-session-binary: symbol lookup error: /lib64/libcairo.so.2: undefined symbol: FT_Done_MM_Var
xinit: connection to X server lost
waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.
This could also be specific to X, I suppose...does Wayland work?
I'm experiencing the same issue. After cairo upgrade on my laptop with Fedora Rawhide some applications stopped to work:
gnome-terminal: symbol lookup error: /lib64/libcairo.so.2: undefined symbol: FT_Done_MM_Var
XPCOMGlueLoad error for file /usr/lib64/firefox/libmozgtk.so:
/lib64/libcairo.so.2: undefined symbol: FT_Done_MM_Var
Couldn't load XPCOM.
Looking at the brew build logs:
checking for FT_Done_MM_Var... no
checking for FT_Done_MM_Var... yes
In F29 there is freetype-2.9-1 that exports FT_Done_MM_Var, unlike in F28 which has freetype-2.8-10.
CCing freetype maintainer to see if he can shed any light...
Hi, do you have freetype-freeworld installed?
Ohhh, right, *that* old chestnut. I knew about that gotcha, sorry, Marek, should've thought of it myself without bothering you...
No problem. I just hope that it is the case :), otherwise it would need longer investigation.
(In reply to Marek Kašík from comment #13)
> Hi, do you have freetype-freeworld installed?
Yes, indeed. Removing freetype-freeworld helps.
I have freetype-freeworld installed as well.
Does this package just need to get rebuilt in rpmfusion or is this something that should go away?
I think it means we need it updated to 2.9 and rebuilt in rpmfusion-rawhide - basically it has to stay in sync with the Fedora version, or else this kind of thing will happen, Rawhide packages are built against the Rawhide freetype which has this symbol, if the one in Fusion is older and doesn't have this symbol, there's obviously gonna be issues like this.
Thanks. For now I'm removing it and updating cairo, but I added it to my list of packages to add back when it works again.
I created a bug for this in rpmfusion's bug tracker (https://bugzilla.rpmfusion.org/show_bug.cgi?id=4873).