SCIENTIFIC-LINUX-USERS Archives

August 2007

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Peter Scott <[log in to unmask]>
Reply To:
Peter Scott <[log in to unmask]>
Date:
Tue, 14 Aug 2007 19:44:58 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
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

ATOM RSS1 RSS2