Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have some 32-bit apps installed on a 64-bit machine running RHEL 4.7 that use pango and are becoming the bane of my existence. In my .bashrc file (which is sourced by .bash_profile) I have done the following to get .pangorc to point to the proper pango modules before running an app:
alias firefox='ln -fs ~/.pangorc64 ~/.pangorc && firefox'
alias acroread='ln -fs ~/.pangorc32 ~/.pangorc && acroread'
This works fine for running terminal commands, but when I click something in the GUI or (in some cases) when another program calls one of these apps they fail to work. Plus, every time I discover a new pango-using program I have to add a new alias to the list.
Unfortunately, any update will wipe out your edit to the startup script.
Still, writing aliases as you have but using the PANGO_RC_FILE environment variable would be more convenient than playing with those symlinks - for one, you're not forever altering those inodes on disk.
As for clicking icons - well, you have to take time setting up the command executed by those icons. As you can imagine, this can be really bad news if the installer put menu items and icons all over the place and you have numerous users. An alternative is to rename affected programs and replace the actual programs with a small script. Once again, any software update will screw things up. It's just one of those hassles you have to live with when using a mixed system.
I don't know what the purpose of this pangorc file is. Maybe you could clarify that.
I use Gentoo, and I use pango on 32 and 64 programs without problems. It comes preconfigured out of the box, and the only thing that the programs needs is to have the right libs available, which is done using /etc/ld.so.conf usually.
As you see, Gentoo hold libs for 32 and 64 bits on different places. If a given program can't link against one lib, it should use the next one available with the same name, I think it works out of the box that way.
$ ls -lR /etc/pango/
drwxr-xr-x 2 root root 4,0K mar 20 2007 i686-pc-linux-gnu
-rw-r--r-- 1 root root 12K oct 22 15:48 pangox.aliases
drwxr-xr-x 2 root root 4,0K mar 20 2007 x86_64-pc-linux-gnu
-rw-r--r-- 1 root root 3,8K mar 18 2008 pango.modules
-rw-r--r-- 1 root root 3,8K oct 22 15:49 pango.modules
My question about clicking icons was really about getting some sort of system-wide configuration for pango, I suppose. The environment variables in the script would certainly do the trick, though I would have to be certain to keep a list of altered scripts around so I could keep track in the event of updates.
I too have the 32-bit and 64-bit pango libraries in separate locations -- I get a very similar listing when I run slocate. The purpose of the .pangorc file is simply to direct applications to the pangox.aliases and pango.modules files. As far as I can tell, an application that needs pango looks in the .pangorc file to figure out where to find these. My 64-bit version looks like this:
On my system I had to create it manually before any pango-using apps would run. It would be nice if it would just work out of the box, so maybe I'll post something in the Red Hat forum to see if this is really the way it should be. If so, I'll just go with the environment variable solution.
Well, this is how it is at the moment. I guess the next thing to do is find out if anyone is hassling the pango developers to make a change to support this out of the box, especially since mixed systems will be around for a while. For example - a config option which sets the default location which the library will check for the rc or aliases/modules files. That way the value can be set to something like /etc/pango32 when building 32-bit software and /etc/pango64 when building for 64-bit software.
Thanks pinniped -- I have done what you suggested and it works beautifully! I use 64-bit pango by default by setting the PANGO_RC_FILE in .bashrc, but change it in the startup scripts for my 32-bit applications. The only downside is, as you say, that I will have to redo my alterations each time a 32-bit app updates....