Hi Peter,

No, I didn't even think of doing that.  What I did was to add the 
library directories, in the order I wanted them searched to the end of 
my PATH variable.

I hope this helps.

Harold


Peter Scott wrote:
> 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
> | >
> | >  
> | 
>
>