Additional 32 Bit libraries

[ahz]

I tried Porteus 64 Bit yesterday. Looks great, works with nearly all 32 Bit apps I used to use with Porteus 32 Bit (compat-multilib by Hamza is installed). Only one application fails: LabVIEW 2011. LabVIEW for Linux is a pure 32 Bit application but people seem to get it to run under 64 Bit. I found this one:

http://forums.ni.com/t5/LabVIEW/Install ... -p/1650044

Now the question: What are the equivalents to the following Centos packages:

yum install glibc.i686
yum install libgcc.i686
yum install libXinerama.i686
yum install libzip.i686
yum install libstdc++.i686
yum install glib2.i686
yum install bzip2-libs.i686
yum install glibc-devel.i686
yum install glibc-static.i686
yum install avahi-glib.i686
yum install dbus-glib.i686
yum install glibmm24.i686

Where can I get them from. Is thisalso such a multilib solution? Maybe I have found some packages here:

http://connie.slackware.com/~alien/multilib/current/

But this collection is extremly large so maybe someone with more knowledge about Centos can give me a hint.

Thanks in advance!

[Hamza]

Code: Select all

slackyd -u && slackyd -g glibc libgcc libXinerama libzip libstdc++ glib2 bzip2-libs glibc-devel glibc-static avahi-glib dbus-glib glibmm24

[brokenman]

First update database:
slackyd -u

I would suggest running each one individually: slackyd -g package. If it needs a dep it will ask if you want to download it. Then you can convert the txz file using: txz2xzm package-name-i486-1.txz package-name-i486-1.xzm

Also things like glibc you already gonna have in porteus install.

[ahz]

Thanks for helping to all. Unfortunally I can't get LabVIEW to run with Porteus 64 Bit. It always crashes with a segmentation fault:

root@porteus:~# /usr/local/bin/labview
Segmentation fault

and an entry in /var/log/messages that looks like

Feb 13 13:42:20 (none) kernel: [ 103.753479] labview[4190]: segfault at 8e6a035c ip 000000008e6a035c sp 00000000ffa89810 error 14

It runs with CentOS 64 Bit after you have installed some additional 32 bit libraries.

For me it looks like that there is a kernel configuration difference betweeen CentOS and Porteus.

[fanthom]

@ahz

what about creating your own small multilib env just for the Labview application?

a bit of work but may be worth trying:
1) boot to CentOS and run 'ldd /usr/local/bin/labview'
2) copy each library listed there to separate folder (preserve original paths)
3) create module containing these libs and activate it under Porteus
4) check if labview is starting, if not then run ldd once again and copy missing libs.

be aware that these libs will be comming from CentOS so should be used only for Labview and not any other 32bit Slackware application.

[ahz]

Thanks for the hint fanthom. ldd on Porteus 64 Bit lists a nvidia dependency (while CentOS does not because of running in a VM). Booting Porteus without the nvidia drivers runs LabVIEW immediatly. So it s a NVidia problem again? The exact same setup with an ATI-based compuiter has no problems (with the ATI-driver loaded). At the moment I use nVidia-290.10-porteus-v1.1-x86_64-2beny.xzm.

Just to compare I installed Linux Mint 12 (KDE 64 Bit) and activated the latest NVidia driver: LabVIEW works immediatly with it.

[fanthom]

@ahz
dependencies are static and not dynamic. it can't be like: labview depends on lib A on PC number 1 and does not depend on it on PC number 2.

please show me output of 'ldd /usr/local/bin/labview' when you boot into Porteus 64bit with nVidia driver activated.

it could be another thing:
labview depends on libGL provided by Mesa (included in Porteus by default) while nVidia provides it's own (and much better) libGL implementation which overrides standard libGL.
if this is really the case then you may want to restore original libGL link and check if labview works. be aware that you will lose 3D acceleration when starting with nVidia driver.
i'm also worrying that Xorg wont start at all when you change this link. not sure so please test it.

on the other hand i remember that beny reported similar problem (missing or wrong libGL symlink) when he was compiling E17 desktop.
other distros are dealing with this issue somehow (they have two libGL symlinks - one pointing to Mesa and one to nVidia library) so it should be possible to do the same in Porteus.

maybe i'm going to far with my thinking - please show me 'ldd /usr/local/bin/labview' first...

[ahz]

Here they are:

On Porteus 64 Bit, Nvidia activated:

Code: Select all

        linux-gate.so.1 =>  (0xf775b000)
        libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xf7757000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xf7749000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xf762c000)
        libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0xf7554000)
        libdfir.so.11 => not found
        libtdcore.so.11 => not found
        libni_traceengine.so.1 => not found
        libmgcore.so.11 => not found
        libstdc++.so.6 => /usr/X11R6/lib/libstdc++.so.6 (0xf744c000)
        libm.so.6 => /lib/libm.so.6 (0xf7426000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7422000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf7409000)
        libgcc_s.so.1 => /usr/X11R6/lib/libgcc_s.so.1 (0xf73ed000)
        libc.so.6 => /lib/libc.so.6 (0xf728a000)
        libxcb.so.1 => /usr/X11R6/lib/libxcb.so.1 (0xf7271000)
        libXau.so.6 => /usr/X11R6/lib/libXau.so.6 (0xf726e000)
        libXdmcp.so.6 => /usr/X11R6/lib/libXdmcp.so.6 (0xf7269000)
        libnvidia-tls.so.290.10 => /usr/X11R6/lib/libnvidia-tls.so.290.10 (0xf7265000)
        libnvidia-glcore.so.290.10 => /usr/X11R6/lib/libnvidia-glcore.so.290.10 (0xf5651000)
        /lib/ld-linux.so.2 (0xf775c000)

And for reference on Linux Mint 12 KDE, 64 Bit, Nvidia activated:

Code: Select all

        linux-gate.so.1 =>  (0xf77ce000)
        libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf77a8000)
        libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7795000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xf765f000)
        libGL.so.1 => /usr/lib32/nvidia-current/libGL.so.1 (0xf758d000)
        libdfir.so.11 => not found
        libtdcore.so.11 => not found
        libni_traceengine.so.1 => not found
        libmgcore.so.11 => not found
        libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf74a1000)
        libm.so.6 => /lib32/libm.so.6 (0xf7477000)
        libdl.so.2 => /lib32/libdl.so.2 (0xf7471000)                                                                  
        libpthread.so.0 => /lib32/libpthread.so.0 (0xf7456000)
        libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7438000)                                                                                      
        libc.so.6 => /lib32/libc.so.6 (0xf72be000)
        libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf729f000)                                                                                                        
        libnvidia-tls.so.280.13 => /usr/lib32/nvidia-current/tls/libnvidia-tls.so.280.13 (0xf729b000)
        libnvidia-glcore.so.280.13 => /usr/lib32/nvidia-current/libnvidia-glcore.so.280.13 (0xf598a000)
        librt.so.1 => /lib32/librt.so.1 (0xf5981000)
        /lib/ld-linux.so.2 (0xf77cf000)
        libXau.so.6 => /usr/lib32/libXau.so.6 (0xf597d000)
        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf5976000)

[fanthom]

@ahz

thanks for the info.
Seems that labview really depends on libGL so you need to add 32bit mesa to your multilib package and put all it's libs in /usr/lib folder. in that case you should be able to boot your system with 64bit nVidia driver activated and still use labview, which gonna use /usr/lib/libGL.so (32bit Mesa) and not /usr/lib64/libGL.so (64bit nVidia)

let me know in case it wont help so tomorrow i'll try to create multilib package myself and run labview on my PC.

Cheers

[ahz]

Hello fanthom,

now it works and the solution are the following three lines:

Code: Select all

cd /usr/lib
rm libGL.so.1
ln -s libGL.so.1.2 libGL.so.1

This means: Use standard "libGL.so.1.2" instead of the Nvidia library "libGL.so.290.10". No additional software installation necessary (except the multilib package I mentioned earlier). Thanks for your help!