Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: PingPing on June 02, 2009, 11:29:26 AM
-
I wanted to try my hand at compiling from source.
From a fresh install, what extensions do I need to install to be able to do so?
-
In tc 1.x, compiletc. In tc 2.x, gcc-binutils and all extensions mentioned in its info file.
Many apps need specific libs in addition to the compiler and base libs, so for those get the extension and if there's one, the -dev extension of it too.
-
gcc-binutils and all extensions mentioned in its info file.
I thought there were plans to create a compiletc extension for 2.x that would have all these files listed in the compiletc.tc*.dep file...is this still true?
-
There's no magic bullet, as every package has it's own requirements. Fortunately, it usually tells you what it needs when you attempt to compile.
-
A good idea to use a build script to create the package. It saves a lot of time when recompiling and helps not to miss steps late night. Also essential when later want to recompile it.
As an example see my script below. Please note, you need to make same changes depending on your source, but a good startup.
Regards,
Béla
#!/bin/sh
#
# Define package names and tmp directory
#
SRCNAM=hamlib-1.2.8.tar.gz
WRKDIR=hamlib-1.2.8
EXTNAM=hamlib
TMPDIR=/tmp/hamlib
#
# Export variables needed for compilation
#
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti"
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
#
# Remove dirs and files left from previous creation
#
rm -r -f $TMPDIR
rm -r -f $WRKDIR
#
# Crete temporary directory
#
mkdir -p $TMPDIR
#
# Unpack source in current directory
#
tar -xf $SRCNAM
#
# Configure it
#
cd $WRKDIR
#
./configure --prefix=/usr/local
#
# Compile
#
make install DESTDIR=$TMPDIR
#
# Adjust directory access rigths
#
find $TMPDIR/ -type d | xargs chmod -v 755;
#
# Strip executables
#
find $TMPDIR | xargs file | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded
#
# Delete compilation work directory
#
cd ..
rm -r -f $WRKDIR
#
# Create .tce extension in temp dir
#
cd $TMPDIR
find usr -not -type d > $EXTNAM.filelist
tar -czvf $EXTNAM.tcel --numeric-owner -T $EXTNAM.filelist
advdef -z4 $EXTNAM.tcel
#
# Create md5 file
#
md5sum $EXTNAM.tcel > $EXTNAM.tcel.md5.txt
#
# Cleanup temp directory
#
rm -r -f usr
rm $EXTNAM.filelist
#
# Create .tcz
#
mkdir $EXTNAM
cd $EXTNAM
tar zxvf ../$EXTNAM.tcel
cd ..
mkfs.cramfs $EXTNAM $EXTNAM.tczl
#
# Create md5 file
#
md5sum $EXTNAM.tczl > $EXTNAM.tczl.md5.txt
[^thehatsrule^: placed code tags]
-
In general, if you don't know exactly what you're compiling, it's better to avoid an automated script. First, make sure and read INSTALL inside the untared package, and then try ./configure --help to learn what options are available. Before moving on to 'make', look over the results of ./configure ....it will generally inform you if something important is missing. No sense building an extension that won't work the way you want it to. Sometimes there's a "make test" to check out the results of your 'make' build before installing.
Also, it seems to work better if you 'touch /tmp/mark and then 'make install' directly to /usr/local. You can then find with -newer /tmp/mark' -not -type d'. I think this is described in the wiki. Jason recommended this in a thread as a way of making sure links point to the correct directory.
We've already witnessed one psychotic break on the board caused by 'compile frustration disorder'. As Mikshaw noted, no sense making it seem easier than it really is. Also...don't expect everything to compile on TC
-
I think a build script is a good tool to employ when building/rebuilding packages, it takes more work at first but makes a rebuild much easier when time to upgrade the package. Of course, each build script must be hand tailored to each package as there is no such thing as a universal build script. bmarkus mentioned that you must make changes depending on the source at hand.
I remember having to rebuild all my extensions for i486 and it was livable since I had a build script for each extension at that time. Many complex tweaks, patches, and other things that are so easily forgotton can be documented and even automated in the script making reproducing the extension a breeze.
I don't automate my scripts anymore but rather just provide commands and build instructions, but either way it is valuable to have that information available. That way someone can rebuild extensions to the same specs if for some reason the original submitter is no longer around.
-
Sometimes they can really save lot of time. BLFS has one that get/builds/installs all the XORG libraries...one by one. You just cut/paste and go out for lunch.. done!
-
For sure the first step is to get it compiled manually and to understand the package requirements and the environment. It takes lot of time specially in the beginning. There are no generic way for sure, however most of the typical packages can be compiled nearly on the same way.
Read README and INSTALL or any other relevant docs in the sorce package.
I'm using build scripts as documentaion tool to record where the source comes from, what unique changes needed, etc. But we are different, with different working style.
One moe thing. Test the package carefully and also check the generated file structure, configuration files, etc.
Good luck!
-
For me the first step is looking at the dependencies. You want to avoid "dependency hell"...(Curaga, 2009) at all cost...(i.e, serious mental health hazzard)
-
Thanks everyone, your comments have been invaluable!
Does anyone have a suggestion for a package I should make first? Preferably it will be something that is (a) simple, and (b) is not currently in the TCL repos. I realise that most simple packages would already be in the repos (because they're simple to build!) but if anyone knows of something that they just haven't had the time to build that would be useful to people, then I could have a go at building that.
-
How about zile ( http://www.gnu.org/software/zile/ (http://www.gnu.org/software/zile/) ) - borrowing unashamedly from the dsl book...
-
x264 and xvid are pretty easy to build:
http://www.videolan.org/developers/x264.html
http://www.xvid.org/Downloads.43.0.html
-
Interesting to compare with/without stripping. With zile, it's quite a size difference.
strip --strip-unneeded /zile
-
OK I've built zile. I did it manually following bmarkus's script and then made my own build script. I've made the .tce and .tcz files but only for tinycore 1.x. I've tested them out and they seem to work (although I've never used emacs - strictly vi).
What do I do now?
Also, what does the 'strip' stuff do? (I don't have a background in development, in fact, I'm a chartered accountant).
-
Also, what does the 'strip' stuff do? (I don't have a background in development, in fact, I'm a chartered accountant).
When a lot (all?) of applications are compiled, debugging symbols are included to help developers find problems - the strip command removes these debugging symbols to make the compiled files smaller.
-
What do I do now?
You can submit it to tcesubmit to be put in the TC repository :)
create info, md5sum, and dep files as required
put the extensions, infos, deps, md5sums and source in a directory (ie ~/zile/) and bcrypt it. use commands like thesetc@box:~$ tar czvf zile.tar.gz zile
tc@box:~$ bcrypt zile.tar.gzuse "tinycore" as the password and send it into tcesubmit
-
How do I find out its deps?
-
some applications tell you what they depend on in their website or in the README or INSTALL files found in the source. you can also look up the package in debian and see what they have listed as dependencies to start.
once you have a list to start from, reboot TC with the base norestore boot options and load the list of dependencies that you have gathered so far. start the application from the aterm window...there may be errors but usually the error will tell you what is missing then load the extensions that are required and test again.
Once you get the application to start you can test some of the functionality. if there is still a problem with a missing dependency then it should show in the aterm window.
-
If you get stuck with a dependency - i.e. ./configure or make throws out an error about not being able to find xxx, I've found the debian packages site is very useful for finding which application xxx belongs to:
http://www.debian.org/distrib/packages#search_contents (http://www.debian.org/distrib/packages#search_contents)
As an example, ./configure says it cannot find "aplay"
1. Go to "Search the contents of packages"
2. Click "packages that contain files named like this"
3. Architecture: "Intel x86"
4. Keyword "aplay"
5. Answer "alsa-utils"
Note that I don't mean that you use the asla-utils deb package, but rather that you need to compile the alsa-utils tarball from the alsa site in order to install aplay.
-
Nice tip ....took about 4 attempts to get a connection, though.....
-
I've recently found that pand isn't included in the bluez tce package, so I'm going to try and compile it myself. Wish me luck.
If successful (or not) I'm sure you'll hear about it :D
UPDATE 1: I can get it to compile... but it skips some folders... in particular the compat folder (the only one I care about), so pand isn't compiled. I get something to the effect: make: nothing to do for 'all'.
UPDATE 2: I give up. I can't figure out how to compile pand, and I can't figure out how to connect to a PAN without it.
-
Were you trying to compile bluez-4.41?
-
Yeah... I got it to compile, kinda... it skipped some folders, including the compat folder which contained the source for pand... bummer.
This is the usual problem for me when trying to compile programs for linux... spend two days with nothing to show for it... which is why I gave up on LFS years ago :D