Things That Won't Run in -Current (21 April 2015).
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.
yes, because the one he suggested fixes the version of boost included in the mkvtoolnix tarball, while the one I posted changes the forced including of that version letting the build system use the version of boost we have already installed.
libebml and libmatroska are updated for the same reason (to use the system ones instead of the ones in the mkvtoolnix tarball).
For VLC users with segfault in -current and using SBo's SlackBuild, i tried to rebuild VLC but getting this same error [1] with respect to libkate and flex. According to freebsd the solution is to '--disable-shared' to flex or downgrading to flex-2.5.37. I have not testing any of the proposed solutions.
At the same time, i am using ffmpeg-2.6.2-x86_64_custom-1_hba and, if i can get around libkate issue, then test vlc-2.2.1
claws-mail won't run complaining of some icu dependency or something. Recompile fails complaining that libpng14.la is missing. Symlinking from libpng16.la fixes the compile issue.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,105
Original Poster
Rep:
Quote:
Originally Posted by Alien Bob
Libreoffice will get a new package specifically targeting slackware-current because it nbeeds a recompilation thanks to the icu4c upgrade. There are unannounced version 4.4.3 sources at libreoffice.org that I an using.
I am compiling 64-bit, then the 32-bit needs to be done and then it will be uploaded.
Virtual machine based package building... not as fast as an octacore with 16 GB of RAM of course.
Your new 64-bit Libreoffice-4.4.3 packages are working like a charm!
Thank you very much!
And, thank you for all the "heavy lifting" you do for Slackware!
Your new 64-bit Libreoffice-4.4.3 packages are working like a charm!
Thank you very much!
And, thank you for all the "heavy lifting" you do for Slackware!
Technically when glibc gets updated this can sometimes affect a host of packages. However, due to the amount of updates we got, rather than a small few, reverting back to defaults, or even a reinstall of the system to refresh things can help avoid breakages.
Since this thread exists I thought I would post in it.
I'm running a -current multilib setup with the Apr. 21st updates.
32-bit mesa seems to be somewhat of an oddity on my particular setup.
When I use:
Code:
export LIBGL_DEBUG=verbose
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:0166, driver i965
libGL: OpenDriver: trying /usr/lib64/xorg/modules/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib64/xorg/modules/dri/i965_dri.so
Which is the expected output for my particular setup, nothing weird there.
However, when I try to use 32-bit glxgears with the same environment variable:
Code:
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:0166, driver i965
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i965_dri.so
libGL: dlopen /usr/lib/xorg/modules/dri/i965_dri.so failed (/usr/lib/xorg/modules/dri/i965_dri.so: undefined symbol: __sync_val_compare_and_swap_8)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/swrast_dri.so
libGL: dlopen /usr/lib/xorg/modules/dri/swrast_dri.so failed (libLLVM-3.6.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
I should also point out that a different previous error message said another file was missing which from a simple search is provided by the libva-intel-driver package so I created a compat32 package out of the 32-bit libva-intel-driver package and installed that for this system.
I'm quite busy for the next 3 weeks so I wasn't able to spend time debugging this myself, but I thought this might be enough information to assist others with debugging it if interested.
Edit 1: I should mention according to lscpi -k, my machine uses the i915 kernel module (and a /usr/lib/xorg/modules/dri/i915_dri.so exists for the 32-bit mesa and 64-bit variant of mesa has it as well under /usr/lib64/xorg/modules/dri). The relevant lscpi output is shown here:
Code:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
Subsystem: Hewlett-Packard Company Device 1819
Kernel driver in use: i915
Kernel modules: i915
I get that when doing verbose debug while running 32bit glxinfo. It's an issue with multilib gcc as far as I can tell but I'm getting out of my depth at this point.
I found it useful to redo the entire multilib setup rather than just update the multilib packages that were on the system already (for example using "slackpkg upgrade-all" with slackpkg+ wasn't enough). Initially I had been missing some multilib packages that were newly added, although they hadn't caused me issues yet. I also use some stuff from slackbuilds.org as well, I'd just been hunting them down with ldd and recompiling anything that ran into issues. One of these days I'll have to work out dependency chains for those slackbuilds and script these sorts of updates.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.