[SOLVED] multilib mess

business_kid · 09-14-2012, 02:58 PM

I'm coming to the conclusion linux lacks in the multilib area, because I can't specify where things are too well. Here's an example:

Quote:

(kicad:15482): Gtk-WARNING **: /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so: wrong ELF class: ELFCLASS64

A check revealed I have the library on board

Quote:

bash-4.1$ ls /usr/lib64/gtk-2.0/2.10.0/engines/
libpixmap.la libpixmap.so libsvg.la libsvg.so libxfce.la libxfce.so
bash-4.1$ ls /usr/lib/gtk-2.0/2.10.0/engines/
libpixmap.la libpixmap.so libxfce.la libxfce.so
bash-4.1$ file /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so
/usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
bash-4.1$ file /usr/lib/gtk-2.0/2.10.0/engines/libxfce.so
/usr/lib/gtk-2.0/2.10.0/engines/libxfce.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

What's the *correct* way to handle this sort of thing?

Alien Bob · 09-14-2012, 03:14 PM

It looks like you are using a 32-bit version of an open source software on Slackware64. That is not making sense.
The only reason for needing a multilib setup is if you have proprietary 32-bit software that you can't live without, or if you want to run 32-bit MS Windows programs under Wine.

For all other cases, you should just compile a 64-bit package out of the sources.

Eric

kingbeowulf · 09-14-2012, 03:18 PM

I've been runnning Slackware64 multilib for ages with no problems, including installing 32-bit packages, compiling 32-bit packages, etc.

Did you install the 32-bit compatibility onto Slackware64 properly? You can't just install a 32-bit package and expect it to work
Are you trying to compile a 32-bit software on Slackware64?
Are you trying to run both arch of a package at the same time? If so, why?

See also:
http://alien.slackbook.org/dokuwiki/...kware:multilib
http://slackware.com/~alien/multilib/

kingbeowulf · 09-14-2012, 03:19 PM

Dang, too slow. Alien BOB is quicker in the draw!

animeresistance · 09-14-2012, 04:57 PM

Hey Kingbeowulf ...
It is hard to beat Alien Bob's speed ...

business_kid · 09-15-2012, 03:46 AM

Ah! kicad is a major,major PITA to compile, certainly in 64 bit. That kind of rules it out. It relies tetotally on wxwidgets, and you get compile errors in kicad which originate in wxwidgets, so I spent an afternoon farting with this (fortunately making .txz packages so I could retreat with dignity)recompiling both. Then I did what they told me to, installed precompiled binaries.

So whoever compiled that had his 32bit libs in /usr/lib64?

32 bit compatibility should be taken more seriously. Another example of it is mesa, which even has a --enable-64bit-libs and --enable-32-bit-libs type switches, but specify both, and you're snookered.

jtsn · 09-15-2012, 05:37 PM

Quote:

Originally Posted by business_kid

(kicad:15482): Gtk-WARNING **: /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so: wrong ELF class: ELFCLASS64

The problem is caused by /etc/X11/xinit/xinitrc.xfce by overriding the built-in defaults of GTK:

Code:

# Export GTK_PATH so that GTK+ can find the Xfce theme engine
export GTK_PATH="$GTK_PATH:/usr/lib64/gtk-2.0"

Comment it out and voila: GTK loads the correct theme engine for every ABI.

BTW: The GLADE-Stuff in xinitrc.xfce looks also very bogus. It sets GLADE_MODULE_PATH and others to ":" and breaks LIBGLADE_MODULE_PATH for multilib in the same way as GTK. Scripts like this trying to do fancy stuff should be inspected. There environment variables aren't needed at all.

business_kid · 09-16-2012, 03:11 AM

Thank you Sir!

That's the sort of thing that sorts a problem once and for all. Will grok that xinit.xfce for unwanted stuff.

I worked around it by
removepkg wxwidgets* kicad* :-)