Bug #1291
running maus on fedora18
100%
Description
complaining about freetype - but a yum install says it is up to date.
Not sure where to go next
Files
Updated by Taylor, Ian over 10 years ago
- Assignee set to Taylor, Ian
- Workflow changed from New Issue to Under Test
Hi Paul,
my guess is that you have freetype installed through yum, but not the freetype-devel package, which provides the header library that is being requested.
As a general rule, instead of guessing at matching file names to packages, you can run the following yum command to confirm which package provides a requested file:
yum provides */freetype/config/ftheader.h
On my machine, this produces the following output:
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit Loading mirror speeds from cached hostfile * fedora: mirror.steadfast.net * updates: mirror.steadfast.net freetype-devel-2.4.10-2.fc18.i686 : FreeType development libraries and header files Repo : fedora Matched from: Filename : /usr/include/freetype2/freetype/config/ftheader.h freetype-devel-2.4.10-2.fc18.x86_64 : FreeType development libraries and header files Repo : fedora Matched from: Filename : /usr/include/freetype2/freetype/config/ftheader.h freetype-devel-2.4.10-4.fc18.i686 : FreeType development libraries and header files Repo : updates Matched from: Filename : /usr/include/freetype2/freetype/config/ftheader.h freetype-devel-2.4.10-4.fc18.x86_64 : FreeType development libraries and header files Repo : updates Matched from: Filename : /usr/include/freetype2/freetype/config/ftheader.h mingw32-freetype-2.4.10-2.fc18.noarch : Free and portable font rendering engine Repo : fedora Matched from: Filename : /usr/i686-w64-mingw32/sys-root/mingw/include/freetype2/freetype/config/ftheader.h mingw32-freetype-2.4.11-1.fc18.noarch : Free and portable font rendering engine Repo : updates Matched from: Filename : /usr/i686-w64-mingw32/sys-root/mingw/include/freetype2/freetype/config/ftheader.h mingw64-freetype-2.4.10-2.fc18.noarch : Free and portable font rendering engine Repo : fedora Matched from: Filename : /usr/x86_64-w64-mingw32/sys-root/mingw/include/freetype2/freetype/config/ftheader.h mingw64-freetype-2.4.11-1.fc18.noarch : Free and portable font rendering engine Repo : updates Matched from: Filename : /usr/x86_64-w64-mingw32/sys-root/mingw/include/freetype2/freetype/config/ftheader.h freetype-devel-2.4.10-4.fc18.x86_64 : FreeType development libraries and header files Repo : @updates Matched from: Filename : /usr/include/freetype2/freetype/config/ftheader.h
which is a bit long. However, it is clear that most entries are for freetype-devel, with various versions and architectures available, but all you need is
yum install freetype-devel
and yum will determine the best version (correct architecture, latest version).
Updated by Kyberd, Paul over 10 years ago
I didn't think of the yum trick because I didn't think it was a package problem, although I should have tried it.
but yum install freetype-devel says all packages are upto date and a find . -name ftheader.h gives me a hit at
/usr/include/freetype2/freetype/config/ftheader.h
Updated by Kyberd, Paul over 10 years ago
- File install.log install.log added
I tried hacking the include file to point directly at the freetype file.
Then there was a problem that libXft header files were needed- so I downloaded libXft-devel.
Now when running I hit another problem with freetype.h also from the root build phase.
Rather than continuing to hack files one at a time is there anyway to "easily" alter/add the
required include path into the root build
Updated by Rogers, Chris over 10 years ago
- Category set to Build System
- Target version set to Future MAUS release
Updated by Rogers, Chris over 10 years ago
Just as a point of information, 21root.bash runs a script third_party/install/bin/library_finder.py that walks the directory structure up from /usr searching for .so files - but it does not search for .h files.
Updated by Taylor, Ian over 10 years ago
Hi Paul,
looking at the new log file, I've seen a line that says:
Checking for freetype-config ... /home/paul/Enthought/Canopy_64bit/User/bin/freetype-config
This is probably the point where it is getting the wrong location for the include files.
On my system, I see:
Checking for freetype-config ... /usr/bin/freetype-config
and running the command gives:
[epics@dhcp241 ~]$ freetype-config --cflags -I/usr/include/freetype2
which is the correct location.
So, my guess is that you have had a different freetype installed in the past, and that your PATH variable is still pointing to the Canopy_64bit bin directory. If you remove that from your PATH, then the script will find the system wide version, and go from there. I would also guess that the Canopy stuff is not MAUS related. I would suggest that if the same machine is going to be used for multiple pieces of work, then instead of putting project specific PATH elements (or any environment variables) into your .bashrc, they should instead go into scripts that you source when you decide to do MICE work, or Canopy work, or whatever.
Updated by Kyberd, Paul over 10 years ago
OK - I'll try getting rid of Canopy - it is in fact a python IDE, but more importantly it comes with a
whole set of useful libraries including graphics and plotting.
Updated by Kyberd, Paul over 10 years ago
Builds and runs tests sucessfully.
Can someone update the documentation to point out the incompatibility
Updated by Rogers, Chris over 10 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Documentation was updated.
Updated by Rajaram, Durga over 10 years ago
- Target version changed from Future MAUS release to MAUS-v0.5.5