Re: OpenGL

[Francesco Pietra <frapietra@alice.it>]

On Thursday 06 July 2006 17:40, A J Stiles wrote:
> On Thursday 06 July 2006 13:35, Francesco Pietra wrote:
> > > What do you see when you do
> > >     $ ldd applicationname
> > > ?
> >
> > For a global-search molecular-mechanics application that I compiled (and
> > which has no graphics):
> > $ldd /home/francesco/applicationdir/executable
> > lib.so.6 => /lib/libm.so.6    (0x00002aaaaabc3000)
> > lib.so.6 => /lib/libc.so.6     (0x00002aaaaad49000)
> > /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
>
> That's compiled for 64-bit, as evidenced by the 16-digit hex numbers, and
> properly installed, as evidenced by all the required libraries being
> present.
>
> > For the molecular mechanics application (which contains all its libraries
> > except for OpenGL graphics) and which gives above errors while trying to
> > load:
> > $ldd /home/francesco/applicationdir/executable
> > linux-gate.so.1 => (0xffffe000)
> > libXm.so.3 => not found
> > libGL.so.1 => not found
> > libGLU.so.1 => not found
> > libjpeg.so.62 => not found
> > libXt.so.6 => not found
> > libXt.so.6 => not found
> > libX11.so.6 => not found
> > libm.so.6 => /lib32/libm.so.6 (0x55578000)
> > libc.so.6  => /lib32/libc.so.6 (0x5559c000)
> > /lib/ld-linux.so.2 (0x55555000)
> > libXmu.so.6 => not found
>
> The 8-digit hex numbers show that this is a 32-bit application expecting
> 32-bit libraries.  In fact, it's expecting quite a few libraries which you
> don't have.
>
> > deb64:/# ldconfig
> > after a while reports nothing (or did you mean issuing this command for a
> > particular directory?)
>
> This command is supposed to regenerate a configuration file which says
> which library is to be found where and also the various symbolic links from
> libfoo.so to libfoo.so.0.  You need to run it after installing a library,
> but Debian's package management system takes care of that for you.
>
> It looks as though you will have to search for the packages containing the
> libraries which shew up as "not found"  (There's a facility on
> packages.debian.org where you can search for packages containing named
> files. Go to "Search the contents of packages", enter the filename in the
> text box and select the top radio button  ["packages that contain files
> named like this"].  Set your architecture to i386  [because you want 32-bit
> this time] and your distribution to match the 64-bit distribution you are
> running, and hit "search".)  Download the relevant .deb files  (you might
> need to change distributions if the versions you find are too old or too
> new),  then manually extract the needed libraries and place them in an
> appropriate directory with other 32-bit libraries  (in this case, /lib32,
> which is probably a symlink).
>
> This won't be as neat as doing it all "properly"  (which would entail
> recompiling the 32-bit program as 64-bit, and possibly dealing with all
> manner of warnings and errors if the author naïvely assumed all systems
> were all 32-bit throughout), nor half-properly  (creating and installing a
> proper Debian package with just the 32-bit libraries you need in the right
> places); but one thing you soon learn about Linux is that all kinds of
> horrendous bodges work.
>
> The only thing that would stop it working would be if it depended on some
> 32-bit feature that is not available once the processor is running in
> 64-bit mode  (IIRC there are certain 16-bit 8086 instructions that an 80386
> can't do once it has been placed into 32-bit mode, I don't know enough
> about modern hardware to know if there is another level to this.)  The fact
> that you've had it running on Red Hat  (which has 32-bit libraries in /lib
> and 64-bit libraries in /lib64)  would seem to indicate that this is not
> the case.

Thanks a lot for this general lesson. That it runs on RedHat was reported to 
me from the author of the application. What I'll try is to recompile the 
application at full 64bit as the companion one above (which was easier 
because of no graphics) I have to ask for the latest source, which was 
recently improved to deal with mpqc. 

As indicated in my previous mail (which did not reach you at the time you 
wrote) is to clean from 32bit lib. Please have a look at that mail. You may 
ask why to purge from all 32lib (except grub): I fear that on compiling 
programs that I need for computation - and where the floating point is of 
utmost importance - end not at the best. 

At any event, I understand that there is a limit for programs not conceived 
for parallel machines. The impressive boost I observed for mpqc from a simple 
Athlon to the multicore amd64 was not observed for the above compilation, 
albeit correct at 64bit. It runs faster on the multicore than on the Athlon 
pc, but not so much.

thank you 
francesco