[SOLVED] X windows libraries error after upgrade to -current
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
X windows libraries error after upgrade to -current
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).
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.
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.
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.
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.
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.
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.