Skip to content

Failure to load X11 module in Fedora 13.

13 messages · Carlo Tambuatco, Marc Schwartz, Tom Callaway

#
I've googled around the archives for R-help and R-sig Fedora and found
that a lot of people have had the same errors I've gotten when
starting up the X11() module:

Error in X11() : X11 module cannot be loaded
In addition: Warning message:
In X11() : unable to load shared library '/usr/lib/R/modules//R_X11.so':
  /usr/lib/libfontconfig.so.1: undefined symbol: FT_Select_Size

But I have come across zero answers to this fundamental problem. (At
least none that make sense to a newbie user like me.)

This is after a fresh install of R on Fedora 13 via Yum.

I checked and /usr/lib/R/modules/R_X11.so indeed exists. But R somehow
doesn't care and fails to load it.

So, what did anyone do to resolve this issue?

Here's my sessionInfo():

R version 2.11.1 (2010-05-31)
i386-redhat-linux-gnu

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=C              LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
#
On Jul 3, 2010, at 7:54 AM, Carlo Tambuatco wrote:

            
Carlo,

What is the output of:

  ldd /usr/lib/libfontconfig.so.1

and 

  ldd /usr/lib/R/modules/R_X11.so

I noted the double forward slash in your output above for the second module, which is a bit confusing, but I don't think that should affect anything.

This is something that should work "out of the box". That you are having a fundamental problem here with X11 begins to point in the direction of a packaging issue or a version conflict with the R RPMs on F13.

Just in case, I am cc'ing Tom on this thread to solicit any comments that he might have.

Also, just for the heck of it, that you are having problems both on Fedora and on OSX with display related things, please verify that these are two separate computers. You are not running some virtual machine (eg. VMWare, VirtualBox, Parallels) with Fedora and OSX running at the same time on the same computer? 

Marc
#
On 07/03/2010 11:46 AM, Marc Schwartz wrote:
linux-gate.so.1 =>  (0x004d9000)
     libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x009a8000)
     libexpat.so.1 => /lib/libexpat.so.1 (0x00941000)
     libc.so.6 => /lib/libc.so.6 (0x00110000)
     /lib/ld-linux.so.2 (0x00375000)
linux-gate.so.1 =>  (0x00687000)
     libSM.so.6 => /usr/lib/libSM.so.6 (0x00527000)
     libICE.so.6 => /usr/lib/libICE.so.6 (0x00d68000)
     libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00bfe000)
     libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00110000)
     libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00dd7000)
     libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x009cb000)
     libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x00159000)
     librt.so.1 => /lib/librt.so.1 (0x002e2000)
     libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00395000)
     libX11.so.6 => /usr/lib/libX11.so.6 (0x0052f000)
     libpng12.so.0 => /usr/lib/libpng12.so.0 (0x0015e000)
     libz.so.1 => /lib/libz.so.1 (0x00766000)
     libcairo.so.2 => /usr/lib/libcairo.so.2 (0x0025e000)
     libXt.so.6 => /usr/lib/libXt.so.6 (0x0078f000)
     libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00bcf000)
     libtiff.so.3 => /usr/lib/libtiff.so.3 (0x008a0000)
     libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00cce000)
     libR.so => /usr/lib/R/lib/libR.so (0xb74af000)
     libm.so.6 => /lib/libm.so.6 (0x00ae3000)
     libpthread.so.0 => /lib/libpthread.so.0 (0x00186000)
     libc.so.6 => /lib/libc.so.6 (0xb7323000)
     libuuid.so.1 => /lib/libuuid.so.1 (0x00927000)
     libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x001a1000)
     libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00688000)
     libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00d2f000)
     libdl.so.2 => /lib/libdl.so.2 (0x00318000)
     /lib/ld-linux.so.2 (0x00375000)
     libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00201000)
     libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00495000)
     libXrender.so.1 => /usr/lib/libXrender.so.1 (0x0021f000)
     libXext.so.6 => /usr/lib/libXext.so.6 (0x00228000)
     libRblas.so => /usr/lib/R/lib/libRblas.so (0x00d03000)
     libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00f20000)
     libreadline.so.6 => /lib/libreadline.so.6 (0x00808000)
     libpcre.so.0 => /lib/libpcre.so.0 (0x0031d000)
     libbz2.so.1 => /lib/libbz2.so.1 (0x00239000)
     libicuuc.so.42 => /usr/lib/libicuuc.so.42 (0xb71c7000)
     libicui18n.so.42 => /usr/lib/libicui18n.so.42 (0xb7002000)
     libexpat.so.1 => /lib/libexpat.so.1 (0x00b7b000)
     libXau.so.6 => /usr/lib/libXau.so.6 (0x001cb000)
     libtinfo.so.5 => /lib/libtinfo.so.5 (0x002eb000)
     libicudata.so.42 => /usr/lib/libicudata.so.42 (0xb60bb000)
     libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb5fce000)
     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0034d000)
Fedora and OS X are not running at the same time, but they are on the 
same computer (my MacBook Pro). It's not a virtual machine.
#
On 07/03/2010 11:46 AM, Marc Schwartz wrote:
That is strange. But that is what I copied verbatim as the output from 
within R.
#
On Jul 3, 2010, at 4:24 PM, Carlo Tambuatco wrote:

            
So a dual-boot system then.

Thanks for the clarification. That should hopefully obviate any VM associated issues.

When you get a minute, please run 'yum update' as root to be sure that your system is fully updated. Depending upon whether you have run that since installing F13, it could take a while to download and install any RPM updates. Once you have done that, re-check R for any errors.

Also, please run the following command at the CLI:

  rpm -qi freetype

That should display version information for the freetype RPM that is installed. If you post back, be sure to note whether you run that before or after running the 'yum update' command so as to avoid confusion. The most recent version is freetype-2.3.11-3.fc13.

The original error messages suggest a version link conflict between libfontconfig and freetype, so presuming that you have not manually installed or removed something that might result in the conflict, this would tend to further support a packaging issue AFAICS. So we might have to wait for Tom to comment.

Regards,

Marc
#
On 07/04/2010 12:27 PM, Marc Schwartz wrote:
From: rpm -qi freetype

Run after 'sudo yum update'

X11() module still fails to load in R.


Name        : freetype                     Relocations: (not relocatable)
Version     : 2.3.11                            Vendor: Fedora Project
Release     : 3.fc13                        Build Date: Wed 03 Mar 2010 
05:32:03 PM EST
Install Date: Wed 09 Jun 2010 02:04:00 PM EDT      Build Host: 
xb-01.phx2.fedoraproject.org
Group       : System Environment/Libraries   Source RPM: 
freetype-2.3.11-3.fc13.src.rpm
Size        : 814191                           License: FTL or GPLv2+
Signature   : RSA/8, Wed 03 Mar 2010 05:46:21 PM EST, Key ID 
7edc6ad6e8e40fde
Packager    : Fedora Project
URL         : http://www.freetype.org
Summary     : A free and portable font rendering engine
Description :
The FreeType engine is a free and portable font rendering
engine, developed to provide advanced font support for a variety of
platforms and environments. FreeType is a library which can open and
manages font files as well as efficiently load, hint and render
individual glyphs. FreeType is not a font server or a complete
text-rendering library.
1 day later
#
On 07/04/2010 02:30 PM, Carlo Tambuatco wrote:
So, I can't reproduce this at all on Fedora 13:
== i386 (KVM instance) ==
[spot at f13 ~]$ rpm -q R-core
R-core-2.11.1-1.fc13.i686

[spot at f13 ~]$ R

R version 2.11.1 (2010-05-31)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
== x86_64 (my laptop) ==
[spot at pterodactyl ~]$ rpm -q R-core
R-core-2.11.1-1.fc13.x86_64
[spot at pterodactyl ~]$ R

R version 2.11.1 (2010-05-31)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
I confirmed that FT_Select_size is a valid symbol in freetype (on both
arches):

[spot at f13 ~]$ eu-readelf -s /usr/lib/libfreetype.so.6 |grep FT_Select_Size
  223: 009b6930    128 FUNC    GLOBAL DEFAULT       11 FT_Select_Size

[spot at pterodactyl ~]$ eu-readelf -s /usr/lib64/libfreetype.so.6 |grep
FT_Select_Size
  224: 000000000000dc70    108 FUNC    GLOBAL DEFAULT       11
FT_Select_Size

Do you have any libraries in /usr/local/lib? Did you add any paths to
/etc/ld.so.conf ? I suspect you have an old copy of freetype floating
around somewhere. It looks like it is not uncommon for third party
applications (VMWare, VirtualBox) to shove an old freetype library onto
the system.

~spot
#
On 07/06/2010 08:51 AM, Tom "spot" Callaway wrote:
This is what ls revealed about my /usr/local/lib directory:

total 4344
drwxr-xr-x. 3 root root    4096 Jun 19 17:04 blender
drwxr-xr-x. 2 root root    4096 Jun 15 17:15 codecs
-rw-r--r--. 1 root root   94132 Jun 15 17:04 libdvdcss.a
-rwxr-xr-x. 1 root root     822 Jun 15 17:04 libdvdcss.la
lrwxrwxrwx. 1 root root      18 Jun 15 17:04 libdvdcss.so -> 
libdvdcss.so.2.1.0
lrwxrwxrwx. 1 root root      18 Jun 15 17:04 libdvdcss.so.2 -> 
libdvdcss.so.2.1.0
-rwxr-xr-x. 1 root root   74687 Jun 15 17:04 libdvdcss.so.2.1.0
-rw-r--r--. 1 root root 2486916 Jun 19 06:29 libfreetype.a
-rwxr-xr-x. 1 root root     824 Jun 19 06:29 libfreetype.la
lrwxrwxrwx. 1 root root      20 Jun 19 06:29 libfreetype.so -> 
libfreetype.so.6.3.8
lrwxrwxrwx. 1 root root      20 Jun 19 06:29 libfreetype.so.6 -> 
libfreetype.so.6.3.8
-rwxr-xr-x. 1 root root 1765321 Jun 19 06:29 libfreetype.so.6.3.8
drwxr-xr-x. 2 root root    4096 Jun 19 06:29 pkgconfig
#
On 07/06/2010 03:01 PM, Carlo Tambuatco wrote:

            
This is your problem. R (well, the X11 part of it anyways) is looking
for libfreetype, finding the copy in /usr/local (I'm guessing blender
put it there) which doesn't match the system libfontconfig.so and things
explode from there.

The simplest solution would be for you to delete libfreetype* from
/usr/local/lib, although, there is a chance that whatever third party
app put those library files in /usr/local/lib might stop working.

~spot
#
On 07/06/2010 03:15 PM, Tom "spot" Callaway wrote:
You're saying I have to choose between running Blender and running X11() 
in R?
Is there a way to maybe create symlinks from where X11() expects to find 
the libfreetype to where libfreetype actually is to get both Blender and 
R X11() to play well together?
#
On 07/06/2010 03:42 PM, Carlo Tambuatco wrote:
Well, I'm saying that your copy of blender in /usr/local (assuming that
blender is what put the libfreetype* files in /usr/local) is causing all
of your system applications that depend on libfreetype to break,
including R.

Fedora provides blender as part of its package repositories. I would
recommend trying to use it instead of your copy, as it will properly use
the modern system libfreetype libs.

Simply moving the libfreetype* files out of /usr/local/lib should be
enough to get R working. You might even trying launching blender to see
if it also still works, but it may really need those files. You could
also explicitly tell blender about the new home (that isn't in the ld.so
path) like this:

LD_LIBRARY_PATH=/usr/local/freetypelibs/ blender

~spot
#
On 07/06/2010 03:47 PM, Tom "spot" Callaway wrote:
I did download blender from the Fedora repositories, so it should 
already use the proper modern system libfreetype libs. Where do you 
suggest I should move the libfreetype files to?
#
On 07/06/2010 03:56 PM, Carlo Tambuatco wrote:

            
Hmm, thats odd. Well, that means blender isn't responsible for those
libfreetype files in /usr/local.

Try this (as root):

mkdir -p /usr/local/freetypelibs/
mv /usr/local/libs/libfreetype* /usr/local/freetypelibs/
/sbin/ldconfig

Then, try running R (a new session) with X11(). It should start working.

The next step is to figure out what in /usr/local/lib (or even
/usr/local) really depends on that old copy of libfreetype. Something
wanted those old libfreetype files to just show up in the library path,
and it will need the LD_LIBRARY_PATH override (or you need to rebuild it
against the system freetype).

~spot