[SOLVED] X windows libraries error after upgrade to -current

Cultist · 12-24-2011, 09:09 PM

I bought a new computer and installed Slackware64 13.37, upgraded KDE to 4.7.4, and installed multilib. I've done nothing else in the way of customization, only installing stuff from Slackbuilds.org.

Something I've noticed with two packages I've tried to build: evas and gtkglext. When they're compiling, they error out with x11 libraries (libXext.so for gtkglext and libx11.so for evas), saying 'file in wrong format.'

I'm not really sure where to proceed from here. I don't know what part of what I did might have messed with these, but I'd like to fix it.

I tried compiling it in 32 bit just to see if maybe I messed up my multilib install, but it gives me an error about not finding eina (a dependency that I installed in 64 bit, I don't want to recompile the entire chain in 32 just to test this).

weibullguy · 12-25-2011, 10:06 AM

Maybe posting the actual error messages rather than your interpretation of them might help someone help you.

Cultist · 12-25-2011, 10:16 AM

I did post the error.

Quote:

When they're compiling, they error out with x11 libraries (libXext.so for gtkglext and libx11.so for evas), saying 'file in wrong format.'

But if you want the exact wording if you've never seen this error before (if that's possible), it is

Code:

libXext.so: file in wrong format

And it's not just 'my interpretation'. In my experience this error almost always points to the library being compiled for a different architecture than the application trying to reference it. My problem is that this shouldn't be the case in my install.

weibullguy · 12-25-2011, 10:54 AM

Usually posting the last 20 or 30 lines (if there are that many) of output from make is the general rule so people can see what the package is trying to do rather than just the error message.

Cultist · 12-25-2011, 11:27 AM

evas:

Code:

make[5]: Leaving directory `/tmp/SBo/evas-1.1.0/src/modules/engines/gl_common'
Making all in gl_x11
make[5]: Entering directory `/tmp/SBo/evas-1.1.0/src/modules/engines/gl_x11'
  CC     module_la-evas_engine.lo
evas_engine.c: In function '_sym_init':
evas_engine.c:493:4: warning: assignment from incompatible pointer type
evas_engine.c:493:4: warning: assignment from incompatible pointer type
  CC     module_la-evas_x_main.lo
  CCLD   module.la
/usr/lib/libX11.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[5]: *** [module.la] Error 1
make[5]: Leaving directory `/tmp/SBo/evas-1.1.0/src/modules/engines/gl_x11'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/tmp/SBo/evas-1.1.0/src/modules/engines'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/SBo/evas-1.1.0/src/modules'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/SBo/evas-1.1.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/evas-1.1.0'
make: *** [all] Error 2

gtkglext:

Code:

so -lrt -lm -Wl,--rpath -Wl,/usr/lib64 -Wl,--rpath -Wl,/usr/lib64/../lib64
/usr/lib64/gcc/x86_64-slackware-linux/4.5.3/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.so when searching for -lGLU
/usr/lib/libXext.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
Linking of scanner failed: 
make[4]: *** [scan-build.stamp] Error 1
make[4]: Leaving directory `/tmp/SBo/gtkglext-1.2.0/docs/reference/gtkglext'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/SBo/gtkglext-1.2.0/docs/reference'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/SBo/gtkglext-1.2.0/docs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/gtkglext-1.2.0'
make: *** [all] Error 2

Best thing I've been able to figure is that, since the referenced library is in /usr/lib and not /usr/lib64, its trying to use my 32-bit compatibility libraries to compile for x86_64. Not really sure how to force it to use the correct libraries if this is the case.

I'm using sbopkg for these without modifying the slackbuild at all, but I tried doing it manually and ran into the same errors.

phenixia2003 · 12-25-2011, 11:59 AM

Hello,

Quote:

Originally Posted by Cultist

Best thing I've been able to figure is that, since the referenced library is in /usr/lib and not /usr/lib64, its trying to use my 32-bit compatibility libraries to compile for x86_64. Not really sure how to force it to use the correct libraries if this is the case.

In some cases, building 64-bit softwares under Slackware-64+mutlilib can be tricky as explained in Slackbuilds.org's faq :

Quote:

18.I have problems compiling with my unofficial and unsupported multilib setup.

If you are using multilib packages from somewhere and also have some 32bit packages installed, then you might run into problems with the build process trying to link 32bit libraries instead of 64bit libraries. If this occurs, it can probably be solved by placing the following line:
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
after the lines for CFLAGS and CXXFLAGS passed to the configure script. In other words, make it look something like this:
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
./configure \
Beyond that, you are on your own. This is an unsupported setup.

Cheers and merry Christmas to all !

--
SeB

weibullguy · 12-25-2011, 06:29 PM

The first thing I would try is setting PKG_CONFIG_PATH to point to the metafiles for the 64-bit libraries. I don't know if evas and gtkglext use pkg-config, but it will be the easiest and correctest solution if they do. If not, then setting LDFLAGS to look in the 64-bit library paths should work.

Cultist · 12-25-2011, 09:12 PM

Quote:

Originally Posted by phenixia2003

Hello,

In some cases, building 64-bit softwares under Slackware-64+mutlilib can be tricky as explained in Slackbuilds.org's faq :

Cheers and merry Christmas to all !

--
SeB

Thank you for pointing this all out to me. I remember now that I had to do this when I installed Enlightenment on my old computer, its just been so long that I completely forgot about that little issue with multilib installs. Compiling and installing now, so thanks both of you!