Dear Harold,

Thanks for your note.

Were you thinking of setting the
LD_LIBRARY_PATH variable to this path?

Actually I had tried that (setting it temporarily for the
compilation process, since running almost any program
would use it, something you probably don't want), but it
did not fix the compilation.  Neither did setting something in
/etc/ld.so.conf.  The compiler (compiling gutenprint) seemed
to want to look explicitly for /usr/lib/libijs.so, but since
that phrase is not in the Makefile I'm not sure how it gets
generated.  Maybe it gets generated by the "configure" script,
but although there are many references to "/usr/lib", there
are no references to "/usr/lib64".  This seems a little
surprising, since gutenprint wants to be compiled using
64-bit libraries.

I did write a note to Robert Krawitz (gutenprint's author) but
he only (correctly) guessed that the compiler was trying to use
32-bit libs when it should be using 64-bit libs.  He did not
suggest a fix strategy, so I just tried 

rm /usr/lib/libijs.so
followed by
ln -s /usr/lib64/libijs.so /usr/lib/libijs.so

and voila! the program compiled and it works.

[I have since removed that link (ldconfig would give warning
messages) but the compiled printer driver still drives the
printer, so either this printer does not actually use
libijs.so, or the libijs.so is not loaded when the printer is
called, or the printer is quite happy to run with the 32-bit
lib.]

[On the other hand, although xmms (which uses libGL.so) will
compile if I put the soft link to the 64-bit lib in, and runs
generally very well to produce good sound, it crashes if I
try to double the size of the gui by clicking on its "D",
giving this error message:

Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 1909 error_code 8 request_code 72 minor_code 0

I have no idea whether the libGL.so is related to this crashing
behavior or not, but the libGL.so is, I believe, part of the
nvidia graphics driver.  Maybe when the next SL kernel appears
some light will get shed on this issue (because that will also
entail switching to a different nvidia driver version).]

It is all quite mysterious at this point---just another little
puzzle.

    -- Peter

p.s. I am copying my friend Al Kelley because he is also
interested in this question.

==========================================================

On Aug 16, 2007 at  5:42 pm, Harold Norris wrote:
| 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
| >
| >  
|