LinuxQuestions.org
Register a domain and help support LQ
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 09-05-2012, 03:08 PM   #31
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,276
Blog Entries: 15

Original Poster
Rep: Reputation: 876Reputation: 876Reputation: 876Reputation: 876Reputation: 876Reputation: 876Reputation: 876

I was wondering how you guys created Slackware64, either from scratch or an import, but because a lot of the packages seemed on par or minor updates to Slamd64, it might have been unnoticed what was done.

The thing is Ottavio, is existing SlackBuilds can be rewritten to use the same source, yet also use different patches, build flags, optimizations, etc. specifically for ARM. This way, the source can be self-contained across all platforms with only needing one script for one source, yet patches and architecture specifics kept reserved as needed.

Last edited by ReaperX7; 09-05-2012 at 03:13 PM.
 
Old 09-05-2012, 03:46 PM   #32
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,254

Rep: Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635
Quote:
Originally Posted by ottavio View Post
I am actually a bit disappointed. I actually rooted for a complete fork of the ARM tree. Why? Because Slackware was born for the PC. ARM devices are different beasts. If you plan for an unified source tree you either sacrifice the PC port or the ARM port.
That already exists in slackwarearm aka ARMedslack. I would prefer Alien Bob's integrated solution -- while I realize ARM is a different beast (and though I am very far from an expert in the matter I have used embedded Linux on ARM devices), slackwarearm really is a different project. You cannot apply your knowledge of Slackware to slackwarearm and work as usual -- (re)building official packages demands that you learn a whole other process, which although efficient to maintain from Stuart Winter's point of view (and possibly the only way to maintain such a project as a single person), becomes a frustration from not being able to use Slackware in the same way just because of an architecture difference. Obviously ARM's kernel requirements make a catch-all distribution impossible but a unified Slackware ARM port would be highly desirable, at least to me. Note that I do not intend to diminish the ARMedslack project, which is and has been fantastic.
 
Old 09-05-2012, 05:42 PM   #33
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,270

Rep: Reputation: Disabled
Quote:
Originally Posted by ottavio View Post
I am actually a bit disappointed. I actually rooted for a complete fork of the ARM tree. Why? Because Slackware was born for the PC. ARM devices are different beasts. If you plan for an unified source tree you either sacrifice the PC port or the ARM port.
I don't understand a word of what you are saying here.

Eric
 
Old 09-05-2012, 06:17 PM   #34
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
Quote:
Originally Posted by Alien Bob View Post
I will also release my scripts to build the cross-compiler and mini rootfs containing the native toolchain. The scripts are created in such a way that adding another architecture should be fairly trivial. What I have based my scripts on is http://fedorapeople.org/cgit/djdelor.../bootstrap.git
I need an arm cross compilation environment to do some work on an embedded device. Previously I'd use code-sourcery's lite g++ toolchain, or build one using Open Embedded.

If I understand correctly these scripts would build a Slackware package containing an arm cross-compilation toolchain I could use on an arm9 embedded device? If so that would be awesome!
 
Old 09-06-2012, 06:08 AM   #35
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,270

Rep: Reputation: Disabled
The script first creates a subdirectory structure with a suite of cross-compilers (i.e. compilers running on the x86_64 host but capable of creating arm binaries) and the second stage is to use those cross-compilers to compile a mini root filesystem which can be installed on the ARM machine. This rootfs contains a U-Boot kernel, so it could even be used to boot the ARM computer if you know how to configure U-Boot. The rootfs contains the necessary tools you need to build all the rest of Slackware from scratch on ARM.

I'll have to consider creating a github repository for this. The scripts are not secret, it's just that my port is incomplete and I wanted to wait. It is pretty rough at the edges still.

Eric
 
Old 09-06-2012, 06:10 AM   #36
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,270

Rep: Reputation: Disabled
Quote:
Originally Posted by D1ver View Post
I need an arm cross compilation environment to do some work on an embedded device. Previously I'd use code-sourcery's lite g++ toolchain, or build one using Open Embedded.

If I understand correctly these scripts would build a Slackware package containing an arm cross-compilation toolchain I could use on an arm9 embedded device? If so that would be awesome!
Should I upload a ZIP with the crosscompilers so that you can test? I have one for Slackware64-13.37 - since that is the version I run on my development box. I can rebuild one for Slackware-current but that may take a little while to check the newer package versions.

Eric
 
Old 09-06-2012, 07:56 AM   #37
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
Quote:
Originally Posted by Alien Bob View Post
Should I upload a ZIP with the crosscompilers so that you can test? I have one for Slackware64-13.37 - since that is the version I run on my development box. I can rebuild one for Slackware-current but that may take a little while to check the newer package versions.

Eric
If you've got time I'd be pretty interesting in playing around with it. Current would be ideal but I've got a SW64-13.37 laptop which I could use. I pretty much just need a arm-gcc toolchain so I can compile some homegrown programs and run them on a little ACME board running emdebian.
 
Old 09-10-2012, 09:18 AM   #38
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 154

Rep: Reputation: 122Reputation: 122
Quote:
Originally Posted by T3slider View Post
[..]demands that you learn a whole other process, which although efficient to maintain from Stuart Winter's point of view (and possibly the only way to maintain such a project as a single person), becomes a frustration from not being able to use Slackware in the same way just because of an architecture difference. Obviously ARM's kernel requirements make a catch-all distribution impossible but a unified Slackware ARM port would be highly desirable, at least to me. Note that I do not intend to diminish the ARMedslack project, which is and has been fantastic.
Slackware ARM/ARMedslack started as an unofficial port, so I had to out of necessity have a separate tree, that was easy to maintain (which is still is, at least in terms of keeping up with x86 development). There's now over ten years of development history there which even now is still quite useful for me when developing.

For those who are saying how it'd be easier for *them* - I'm the only one who develops Slackware ARM, so it has to be the easiest for me to maintain. Since Slackware is not a 'from source' distribution such as is Gentoo, there's no need for everyone to understand how to use my build system up front. However, I have made ample effort to document it - and the Slackware ARM source tree and build scripts are sometimes more verbosely documented than x86 (mostly for my own benefit in the first instance, but for those of you want to read and learn, it's there in the open). On the other hand, did anybody really try using the x86 scripts? From some of the posts it doesn't sound like it. If you did, you might find that many of them are perfectly fine on Slackware ARM as is, with no modification -- since a while ago, Pat took the auto arch detection & CFLAG settings from my scripts and added them into the x86 tree. The CFLAGS are for armv4t in there at the moment, but it's no big deal to change it if you so wished.

None of us apart from Pat are able to make changes to the source tree, so it's *far* easier and less time consuming to have a separate tree in order to fix bugs and apply patches quickly. Obviously if I fix something for ARM that applies also to x86 then I give Pat a heads up.

As anybody who's programmed or scripted -- you develop your own style. As some of you who've perused Slackware ARM's source tree will see, the build scripts are somewhat different (although the main sections are the same). Part of my enjoyment (albeit only a small bit) is coming up against something in the x86 scripts that I'll optimise or just re-style to my own taste, but still achieve the same resulting package.

Finally, the current SlackBuild scripts need further work more than just setting some CFLAGS. There are some obvious ones that spring to mind such as using gzip to compress packages rather than LZMA; since many ARM devices don't have much RAM so I foresee trouble with LZMA on ARM. There are a few other points to consider (which I've discussed briefly with Eric & Pat but don't recall them off the top of my head), but until such a time that my interest wavers in maintaining my own scripts or we're able to make changes to the source tree, and figure something else out with regard to how packages are built, then it's definitely best to keep the projects separate. If I found it too tiresome having a unified tree (as at present it'd essentially be a case of bugging Pat to replace or apply a patch to an existing script), I'd just stop working on it and do something else.
At the moment since I've been building the ARM port for a long time, I know when to batch up my updates as I have developed a sort if inner compass for knowing when an x86 batch will be 'buggy' -- so I tend to just leave the ARM packages for a few days and this way it saves me having to rebuild them 2 or 3 times before I upload them and they're listed in the changelog. For large packages such as QT this is essential since that one takes about 1.5 days to compile. However, this approach means that if we *did* have a unified tree, then the build numbers would be out of sync. I like having sequential build numbers which you can track in the changelog, rather than say jumping from 1 to 4. Given that the build/queuing system is manual (unlike Fedora, Debian etc) and is done in spare time, what I am saying in a nut shell is that the system has to benefit the person who uses it, not the other way around :-)

Phew. Anyway, I don't think I could ever lose my library function names. Who wants to reduce a changelog with some heading and tailing when you can call "slackliposuction". I just imagine a big machine sucking all the text out of a file ;-)

Last edited by drmozes; 09-10-2012 at 09:21 AM.
 
5 members found this post helpful.
Old 09-10-2012, 05:30 PM   #39
chemfire
Member
 
Registered: Sep 2012
Posts: 73

Rep: Reputation: Disabled
Stuart,

I have been using your arm port for a couple years now on some of the plug computers. You have done a fantastic job with it and produced an excellent distribution. I am really just posting to say thank you so much for all your hard work on the project.
 
1 members found this post helpful.
Old 09-11-2012, 08:11 AM   #40
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
Quote:
Originally Posted by chemfire View Post
Stuart,

I have been using your arm port for a couple years now on some of the plug computers. You have done a fantastic job with it and produced an excellent distribution. I am really just posting to say thank you so much for all your hard work on the project.
I would like to associate myself to this comment of gratitude for Stuart's port, although I haven't tested it that much and only on Qemu, but I am planning to buy the latest Genesi iMX.6 device whenever it comes out.
 
  


Reply

Tags
init, slackware from scratch


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
Installing Slackware from scratch. glore2002 Slackware 16 09-03-2008 06:44 AM
Installing Slackware 10.2 from scratch dfresh Slackware - Installation 9 11-10-2005 01:44 PM
Slackware from Scratch? dhave Slackware 10 02-07-2005 04:04 PM
ali aladdin v agp stinks :scratch: :scratch: :scratch: Mr Marmmalade Linux - Hardware 1 07-08-2003 05:11 AM


All times are GMT -5. The time now is 05:49 AM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration