LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-31-2018, 04:07 PM   #1
phalange
Member
 
Registered: May 2018
Distribution: Slackware, Nixos, Arch, Centos
Posts: 150

Rep: Reputation: Disabled
Source or binaries, any guidelines for Slackbuilds?


I've noticed with slackbuilds there are some programs built from source, some from binaries. In certain cases it seems to be done in avoidance of lengthy build times, but in other cases I can't tell what the rationale was.

Are there any best practices, or notable situations where source is avoided?
 
Old 09-01-2018, 09:21 AM   #2
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
That depends 100% on each individual case. Sometimes there is only a binary. But when there is a choice, it's good to have a source build *and* a binary repack as two separate SlackBuilds.
 
1 members found this post helpful.
Old 09-01-2018, 09:21 AM   #3
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,542
Blog Entries: 2

Rep: Reputation: 358Reputation: 358Reputation: 358Reputation: 358
None that I'm aware of;
There seems to be some regularities however:
1. If the software comes in binary distributables (Firefox, Blender) build by the developers -it is likely at least one SBo will use that.
2. If there are some specially cumbersome steps in setting up the build environment, there will be at least one SBo using some binary packages of known reputable source(s).

3. If there are some particularly useful features that are omitted in the binary - there will usually be an SBo building it from the sources.
 
1 members found this post helpful.
Old 09-03-2018, 05:14 AM   #4
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 943

Rep: Reputation: 366Reputation: 366Reputation: 366Reputation: 366
I prefer build from source. Some programs such as Skype and Google Earth Pro, there isn't a choice, so I repackage the binaries. The only exception currently on my system is Blender. I repackage the binaries because I only want to play around with it. If I decide to keep it, I will probably go with building from source. Build times usually don't figure in my deciding to go with binary or source.
 
1 members found this post helpful.
Old 09-03-2018, 06:39 AM   #5
Lysander666
Senior Member
 
Registered: Apr 2017
Location: The Underearth
Distribution: Slackware
Posts: 1,480
Blog Entries: 3

Rep: Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498
I build everything from source because then the software is compiled for my hardware. It runs better, smoother, faster.

The only things I don't build from source are the big and complex packages, e.g. Chromium, Libreoffice, qt5. This is purely because of the time it would take to build, and Eric's binaries are great.

Last edited by Lysander666; 09-03-2018 at 06:42 AM.
 
1 members found this post helpful.
Old 09-04-2018, 03:17 AM   #6
elcore
Member
 
Registered: Sep 2014
Distribution: Slackware
Posts: 590

Rep: Reputation: Disabled
Rar archiver, nvidia firmware, and vmware. For these few I have no source, everything else I had to add is compiled from source code.
 
1 members found this post helpful.
Old 09-05-2018, 02:10 AM   #7
Delcaran
Member
 
Registered: Dec 2013
Location: ud.fvg.it
Distribution: Slackware64 14.2
Posts: 33

Rep: Reputation: 27
Building from source requires times and resources. For some software I don't have those. Also, I fail to see a difference in performance when building my own vs use someone else's build. I'd with sources if I can, and binary from a trusted source if I cannot.
 
3 members found this post helpful.
Old 09-05-2018, 07:59 AM   #8
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.2
Posts: 7,809
Blog Entries: 58

Rep: Reputation: Disabled
Quote:
Originally Posted by Lysander666 View Post
I build everything from source because then the software is compiled for my hardware. It runs better, smoother, faster.
Wouldn't that only apply if you used "march=native" as a build option?
 
3 members found this post helpful.
Old 09-05-2018, 08:09 AM   #9
Lysander666
Senior Member
 
Registered: Apr 2017
Location: The Underearth
Distribution: Slackware
Posts: 1,480
Blog Entries: 3

Rep: Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498Reputation: 1498
Quote:
Originally Posted by brianL View Post
Wouldn't that only apply if you used "march=native" as a build option?
I thought that a lot of SBo packages were compiled like this by default, apparently not. I suppose I may have to consider doing so in the future.
 
Old 09-05-2018, 08:41 AM   #10
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: MID-SOUTH USA
Distribution: Slackware 14.2 current / Linux Mint / Debian / Void Linux
Posts: 8,508

Rep: Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775Reputation: 1775
from my experience in creating a slackbuild for softwhere install. it all falls to the one that created the software, then finding out how they set it up to be compiled,then figuring out how to add the commands needed to do that in a script. Where the basic template is already pretty much set up, some fanaggling may be needed to modify some of the code within the software to make it compatible or updated to work in Slack, ie install properly etc...
 
1 members found this post helpful.
Old 09-05-2018, 09:09 AM   #11
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.2
Posts: 7,809
Blog Entries: 58

Rep: Reputation: Disabled
Quote:
Originally Posted by Lysander666 View Post
I thought that a lot of SBo packages were compiled like this by default, apparently not. I suppose I may have to consider doing so in the future.
Don't think it would make any significant difference in most cases.
 
3 members found this post helpful.
Old 09-05-2018, 10:24 AM   #12
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
Yep, I'm with BrianL, unless somebody can produce convincing benchmarks about the benefit of "-march=native" etc, SlackBuilds.org will continue to use the normal Slackware flags:

Code:
if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
else
  SLKCFLAGS="-O2"
fi
(Some upstream builds make it difficult to set those flags, or override our -O2 with -O3 or -Os, or use assembler code for SSE3 and beyond. If that's the case, we assume that upstream's build is well tested, and therefore we don't strive to impose our normal flags on the build. But we normally prefer the stability and portability of those flags over the ricer flags on other distros, and if some maintainer tries to sneak something else into the repo, we zap it.)
 
3 members found this post helpful.
Old 09-05-2018, 07:08 PM   #13
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 548

Rep: Reputation: 334Reputation: 334Reputation: 334Reputation: 334
Apart from software with only binary releases, I think it's hugely important for the Slackware user community to have the ability to build every possible project from source. Slackware is one of the founding Linux distributions, one of the first distros to show how things could be done - including how source code can be built, packaged and distributed. I think it's incumbent on those of us who can to maintain that tradition with the "non-core" software we use. If instead we were always just to repackage some others' work - always deriving from some other distro, then we'd become a derivative of that distro - Arch, Debian, Redhat etc.

I'm not suggesting that everyone of us must build everything from source (we don't do that for Slackware itself), just that we should have the ability to do so. We are already provided with SlackBuilds for the Slackware core software and SlackBuilds.org is probably the best source of ready made SlackBuilds to build additional software from source (some binary repackages too) and Alien Bob's repo provides binaries built the "Slackware way" (or at least built from source by a reputable community member).

Another consideration for the security conscious is that you can't be absolutely sure what an arbitrary binary may contain.

Anyway, apart from the build time issues already mentioned, I can't really think of any notable situations where source should be avoided if it is available.

chris
 
2 members found this post helpful.
Old 09-07-2018, 05:43 PM   #14
phalange
Member
 
Registered: May 2018
Distribution: Slackware, Nixos, Arch, Centos
Posts: 150

Original Poster
Rep: Reputation: Disabled
I'm marking this thread as solved since it seems to have runs its course.

Thanks for the feedback; all helpful.
 
Old 09-08-2018, 04:42 AM   #15
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 969

Rep: Reputation: 537Reputation: 537Reputation: 537Reputation: 537Reputation: 537Reputation: 537
Quote:
Originally Posted by 55020 View Post
Yep, I'm with BrianL, unless somebody can produce convincing benchmarks about the benefit of "-march=native" etc, SlackBuilds.org will continue to use the normal Slackware flags:

Code:
if [ "$ARCH" = "i586" ]; then
  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
else
  SLKCFLAGS="-O2"
fi
(Some upstream builds make it difficult to set those flags, or override our -O2 with -O3 or -Os, or use assembler code for SSE3 and beyond. If that's the case, we assume that upstream's build is well tested, and therefore we don't strive to impose our normal flags on the build. But we normally prefer the stability and portability of those flags over the ricer flags on other distros, and if some maintainer tries to sneak something else into the repo, we zap it.)
some half a year ago, I had to use CodeML from PAML and decided to compile the package with -march=native, since the computations are really CPU heavy. Well, I did not observe any significant difference. Maybe I should run it with some more time consuming models. Longest I have had it running was for over 5 days, maybe then it will make a difference of couple of hours...
 
3 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: A template for creating open source contributor guidelines LXer Syndicated Linux News 0 03-17-2016 07:31 PM
LXer: UK government open source guidelines ignored, says Ingres LXer Syndicated Linux News 0 09-28-2009 12:21 AM
LXer: European open-source guidelines spark debate LXer Syndicated Linux News 0 09-27-2008 04:20 AM
LXer: European open-source guidelines spark debate LXer Syndicated Linux News 0 09-26-2008 09:00 PM
LXer: Proteus Clinical Guidelines to go Open Source LXer Syndicated Linux News 0 12-19-2007 01:20 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:34 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration