[SOLVED] Building from source

bmarley83 · 01-18-2014, 08:48 PM

Quote:

Originally Posted by Richard Cranium

Great Goo, nobody has mentioned the excellent src2pkg program? If there isn't a slackbuild, src2pkg is the way to go.

Thanks, will give it a try! Definitely what I was looking for!

enorbet · 01-18-2014, 11:13 PM

Nice! thank you LQ

rob.rice · 01-19-2014, 01:17 PM

Quote:

Originally Posted by Alien Bob

Hint, if you are not so versed in compiling from source, try to find SlackBuild scripts.
The slackbuilds.org website has lots of them, and you can use the sbopkg tool to make the process a whole lot easier. Sbopkg knows the concept of building queues (of packages): http://sbopkg.org/queues.php . Basically, a queue is a recipe to build all requirements for the package first, and then the package itself, in the proper order. That page contains a link to a git repository which contains build queue files for every package on slackbuilds.org.
Download that whole git repository of queue files and you'll be able to compile most if not all of slackbuilds.org entries with a few clicks.

Interactive discussion can be had in the #slackbuilds channel on the FreeNode IRC network. A forum just is not that interactive. Be patient and hope that people come up with good advice.

Eric

---------- Post added 18th Jan 2014 at 00:06 ----------

Hint, if you are not so versed in compiling from source, try to find SlackBuild scripts.
The slackbuilds.org website has lots of them, and you can use the sbopkg tool to make the process a whole lot easier. Sbopkg knows the concept of building queues (of packages): http://sbopkg.org/queues.php . Basically, a queue is a recipe to build all requirements for the package first, and then the package itself, in the proper order. That page contains a link to a git repository which contains build queue files for every package on slackbuilds.org.
Download that whole git repository of queue files and you'll be able to compile most if not all of slackbuilds.org entries with a few clicks.

Interactive discussion can be had in the #slackbuilds channel on the FreeNode IRC network. A forum just is not that interactive. Be patient and hope that people come up with good advice.

Eric

the DOCs are not clear on where to put the queue files all they have to say is read the /etc/sbopkg/sbopkg.conf man page witch says nothing about the queue files the sbopkg.conf file sets the queue path to /var/lib/sbopkg/queue so that's where I put them
and
I can't get anything with dependencies to build

love the idea it would be just the thing for something like flight gear with tons of dependencies

bmarley83 · 01-19-2014, 01:34 PM

Yeah I just figured I'd try to install ardour and compile from the latest source but figured I'd check with slack-builds first to reference the deps. Well lets just say there are a "few" so then I did a ./waf configure in the extracted directory, and for the life of me I cant get libsigc++2.0 to compile (even thoguh a newer version is available it wont compile with it) which is listed as a dep for glibmm which is a dep for some other dep for ardour.

This is why I think sbopkg is a bad idea for slackware and why I don't use it. Many of the slackbuilds I have encountered don't compile. I'm not saying they won't with some tweaking but I have found three packages with deps that won't compile this week alone. I know everybodies got a day job so i'm not knocking slackbuilds cause they have plenty that work just fine. Just saying sbopkg isnt the ideal solution.

I'm sticking with src2pkg to make my own from now on and hey maybe I can even make some packages for slackbuilds once I get better at understanding how to deal with dependencies. I have only been using slackware for about 10 months and havent had to compile anything since redhat 95 days :P .

Alien Bob · 01-19-2014, 01:41 PM

Quote:

Originally Posted by bmarley83

for the life of me I cant get libsigc++2.0 to compile (even thoguh a newer version is available it wont compile with it) (...) This is why I think sbopkg is a bad idea for slackware and why I don't use it. Many of the slackbuilds I have encountered don't compile.

First, every package at SBo has been tested against the version of Slackware it was submitted for, with the version of the software that was submitted by the script's author. Something that does not compile on a stock Slackware system is not getting accepted at SBo.

So, somehow your system has become non-standard enough that some software does not compile any longer. One such cause can be adding multilib: http://slackbuilds.org/faq/#multilib

Perhaps you care to share your error messages?

And consider the use of sbopkg's queuefiles to build a complete dependency chain with a single command.

Do not just complain that "sbopkg is a bad idea for slackware". It is an extremely helpful tool. Show us your errors.

Eric

bmarley83 · 01-19-2014, 02:19 PM

I suppose I was to hasty in my dismissal of sbopkg, I'm sure the developer worked very hard on it, and I certainly didn't mean to articulate any resentment toward any of the slack-builds maintainers as I am just a student and quite new to Slackware in general.

I will take my time to build the package in question with all its sources (as I will do with all packages from slackbuilds from now on) and report back with a new thread if I encounter any problems in an attempt to gain some insight.

The support from this community has been unprecedented and proven invaluable. I will try my best from now to be as constructive as possible.

enorbet · 01-19-2014, 02:36 PM

Ok I need to ask right now why I am reading about "Packages", "Management" and "Dependencies" in the same sentence on a Slackware forum. Aren't you concerned that if this keeps evolving Slackware will become an "also ran" and something less? For me the system is sacrosanct. I'd much rather sacrifice a new app that won't run because of a dependency that I missed or that I have yet to get to compile right, than risk the system. Am I missing something?

bmarley83 · 01-19-2014, 02:49 PM

Quote:

Originally Posted by enorbet

Aren't you concerned that if this keeps evolving Slackware will become an "also ran" and something less? For me the system is sacrosanct. I'd much rather sacrifice a new app that won't run because of a dependency that I missed or that I have yet to get to compile right, than risk the system.

Also a good point. I guess that's why I started using Slackware in the first place.

Alien Bob · 01-19-2014, 02:53 PM

Quote:

Originally Posted by enorbet

Ok I need to ask right now why I am reading about "Packages", "Management" and "Dependencies" in the same sentence on a Slackware forum. Aren't you concerned that if this keeps evolving Slackware will become an "also ran" and something less? For me the system is sacrosanct. I'd much rather sacrifice a new app that won't run because of a dependency that I missed or that I have yet to get to compile right, than risk the system. Am I missing something?

You lost me there.
Slackware uses packages from day one. Package management is what you do from day to do to keep your computer safe and up-to-date.
The Slackware package tools and the package manager that ships with it (slackpkg) do not perform any kind of dependency resolution or management. That does not mean that the word "dependency" does not exist on Slackware, it's just that you have to take care of fulfilling them when installing new software. With slackbuilds.org, one of the ways to work with dependencies a bit easier is to use sbopkg and its queuefile support. Someone took the effort to document (in queue files) how packages need to be built in order. What's so devlish about that? How different is it from the way a SlackBuild script is an abstraction of the "configure && make && make install" routine you probably are still using (like me, and there is nothing wrong with that either).

Eric

enorbet · 01-19-2014, 03:33 PM

Whew! Thank you for the clarification, Alien Bob. <big sigh of relief>

First off, sorry I didn't embolden "Dependencies". Of course I know about the pkgtool package management suite. It's just that Slackware seems the last remaining Linux that does not try to auto-resolve dependencies, and I want it to stay that way. I am aware that there have been some attempts to create such a monster for Slack and I mistakenly thought that "slackpkg" was becoming one of those, like "swaret". I'm probably just a little hyper from feeling like my access to control is slipping,forced to deal with what appears to be some udev insanity, and jumping at shadows now :P

bmarley83 · 01-19-2014, 03:45 PM

LMAO at your last post enorbet. I guess what I can say we all learned from this post was that having a "Can Do" attitude is important for the sake of learning and contributing! With that said nobody "Can Do" everything by themselves, and the support of all members of the community is the most important point, when attempting to maintain the idealistic philosophy of the distribution.

Alien Bob · 01-19-2014, 03:50 PM

Last time I looked, slackpkg and Slackware were not going to get automatic adependency resolution.

Eric

enorbet · 01-19-2014, 05:30 PM

#freakhalt.sh
#/bin/sh
cat /brain |grep stress |sed 's/adrenaline/endorphin'
killall stress
sleep
#EOF

@BMarley83

Quote:

Originally Posted by C.Peppers

Bob Marley poet and a prophet
Bob Marley taught me how to off it
Bob Marley walkin' like he talk it
Goodness me can't you see I'm gonna cough it

I'm a low brow but I rock a little know how
No time for the piggies or the hoosegow
Get smart get down with the pow wow
Never been a better time than right now

narz · 01-19-2014, 07:12 PM

Quote:

Originally Posted by bmarley83

Thank you MannyNix that was helpful, but I guess i'll just search the web for more stuff on debugging make errors, thanks everyone.

My experience is errors will either be easy to fix (such as disabling a feature you don't have or need, or changing a library path), or they will be more GCC cryptic and require a knowledgeable programmer to fix/patch the culprit.