[SOLVED] Slackware64 14, problems with compiling packages from slackbuilds.org
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
GCC 4.7.x changed in a few significant ways, mostly in becoming more strict with compiling. Also glibc changed the way includes are handled. The latest ffmpeg has changed too, anything dependent upon that needs rebuilding. All of those types of build issues need to be resolved upstream or patched in the build scripts. Etc., etc.
So patience will be required with the slackbuilds scripts for 14.0.
I thought I'd piggy-back onto this comment some more specifics about gcc 4.7.x. One of the issues is actually well documented (if you know where to look) on the gnu/gcc site:
Many of the standard C++ library include files have been edited to no longer include <unistd.h> to remove namespace pollution.
As such, C++ programs that used functions including truncate, sleep or pipe without first including <unistd.h> will no longer compile. The diagnostic produced is similar to:
error: ‘truncate’ was not declared in this scope
error: ‘sleep’ was not declared in this scope
error: ‘pipe’ was not declared in this scope
error: there are no arguments to 'offsetof' that depend on a template
parameter, so a declaration of 'offsetof' must be available
Fixing this issue is easy: just include <unistd.h>.
Unfortunately, this isn't something you're going to work around with a configure option or environment variable. You'll need to find the particular file in the source and add the include line. Fortunately, this has actually fixed the few instances I've found where this was a problem.
I'll usually rebase SBo-git/current on slackbuilds.org's git master (the delay is some hours at max) so you will have that stuff plus the needed updates for -current for the stuff I use, so it's safe to use that if you use -current.
As an alternate to editing /etc/sbopkg/sbopkg.conf, you can change the version sbopkg uses with
# sbopkg -V SBo/14.0
This will prompt you to create the repository directory in /var/lib/sbopkg/SBo/14.0 and take you to the ncurses dialog, where you can start to sync the archive to your local repository and check/build and install updates.
Yes, but using like this (with the -V option) it's only for temporary use: if you don't specify the "-V SBo/14.0" also the next time you launch it, it will default to the repository set in /etc/sbopkg/sbopkg.conf (or ~/.sbopkg.conf, if you save your options from the dialog interface).
Last edited by ponce; 10-03-2012 at 11:21 AM.
Reason: added .sbopkg.conf
I would think that sbopkg is feature complete, so a slow development cycle has to be expected. It works fine here, the only thing that bother me a bit is that the queue files are not adapted yet. I have to look into how to maintain them and then maybe volunteer for that. Well, and I have to learn how to work with git, in the first place.