Peter,

I have run into the same thing compiling programs.  Like you, I have 
tried to change lines in the Makefiles and also making the "wrong" 
libraries disappear (by putting them on another directory).

The last thing I tried was to add the library search path in my 
.bash_profile file.  I added /usr/lib64:/usr/lib:/lib64:/lib
and The program seems to compile properly.  I used this on gnumeric 1.6.3

Hope this helps.

Harold
Peter Scott wrote:
> Here's a question:
>
> I've encountered this kind of error when trying to compile some
> 64-bit programs on SL 5.0:
>
> /usr/lib/libGL.so: could not read symbols: File in wrong format
>
> What it's trying to do is to use a 32-bit library when what it
> should really be using is /usr/lib64/libGL.so---the 64-bit
> library.
>
> I solve this problem using a rather hokey method, which is
> (temporarily, for the purpose of compiling) to switch the soft
> link /usr/lib/libGL.so to point to /usr/lib64/libGL.so instead
> of to the similar 32-bit library in /usr/lib/.
>
> Is there a more standard way to solve this mismatch?  I tried
> setting an environment variable (e.g. PKG_CONFIG_PATH) to put
> the 64-bit lib prior to the 32-bit lib, but that did not work.
>
> Should I change a line in the Makefile?  Is there a flag I
> could append to the ./configure script?  It would be nice to
> be a little cleaner.
>
> [For both of these I was able to compile the program from the
> source using the above-described hokey method.]
>
> This happened with gutenprint (which I need as a printer
> driver) and with xmms (the atrpms xmms rpm available through
> yum did not work for me).  (In the gutenprint case the library
> was libijs.so, but the problem was the same.)
>
> Any thoughts would be most welcome...
>
> [My cpu is an AMD Athlon 64 X2 Dual Core Processor 3800+
> which will run both 32- and 64-bit programs.]
>
>     -- Peter
>
>