Starting a thread on discussion of building parts of Linux, LFS and various packages from source code. This is a spot to compare notes on building from source. We can also discuss pros and cons of various packages/projects to figure out which might be most useful to build from source and which might have less dependencies.
4 Likes
OK, where do we start? I currently have a base LFS booting from a i7CPU from a 120GB SSD, on a PC that solely dedicated for this project. I do most of the building, via ssh from a PC that is running Gentoo. I am now working with BLFS and the, maze of dependencies, in hopes, of getting Xorg, up and running!!! Today is rebuild “rustc” day!!!
3 Likes
I built xorg a while ago and was just recently trying to get it to build on a 64 bit system. I’m using older versions of the source. I was hitting some compiler/errors warnings with the switch to 64 bit. Checked the newer source and was surprised some of the issues still hadn’t been fixed there. I really like the idea of TinyCore’s tinyx drive based on the kdrive. Would like to try it out at some point, but it probably won’t work with certain video cards. Have you been able to get Xorg libraries to build as is or have you had to patch anything?
2 Likes
You may want to look at
There is another done by a student for his end of term paper
1 Like
Apart from trying Gentoo, and compiling kernels years ago in BSD, I really only have experience with
- writing standalone programs in C, Fortran and R
- setting up a makefile
- using git and other older version control systems like RCS, SCCS
- porting packages to BSD
- minor patches to some linux apps
- I have recently experimented in Julia
What I know is that you need to understand the build tools thoroughly.
The more a piece of software interacts with the system, the more difficult it will be to build, and the less likely it will be to be portable.
A standalone program, with no dependencies and no system calls is perfectly portable… lots of scientific software is like that… it just does calculations and elementary I/O.
I said in the discussion in the other post… I think containers can help with buiding packages by providing a special build and run environment… containers are portable too.
1 Like
I’m following this topic but can’t give much because I only use portage (and earlier AUR) to compile from source. Is the Gentoo’s way to make ebuilds familiar? Maybe Laura’s own package manager is different but if it has a file “how to build ” then it’s similar to ebuild.
Here’s the wiki link:
My LFS is on hold. Just got bored to copy+paste all the packages (also didn’t have motivation to go on because I wouldn’t use LFS for anything after first boot).
1 Like
I have never directly used an ebuild file in Gentoo.
I assume you only need that, if you want to modify the build that portage does.
1 Like
It’s also useful if there’s some package you need but it’s not available for Gentoo. I also haven’t used own ebuilds because I haven’t found any need for it yet. But it’s interesting and I’m learning it from wiki.
2 Likes
Will let you know in a few days if Xorg works!!!
1 Like
I’ve been writing new build scripts/makefiles for projects that I might have trouble building. Instead of using cmake or configure, I’ve been moving some of them over to CDetect and I also use GNU make and pkgconf with it. It might take a while to rewrite the build system, but it makes some programs a lot more portable. It’s usually been pretty quick to update when new versions of a program come out too. I have some FLOSS programs I’ve actually managed to get working on FreeDOS. Haven’t seen SDL programs ported to it yet unfortunately, but a lot of FLTK applications will work in FreeDOS with some minimal patching.
3 Likes
Would also be curious to know what packages and drivers were required on your system to get it to build.
I’m still building an older version of X which I’ve patched extensively but I got the steps off an older version of BLFS. Not sure if it’s still in the same order it was in the BLFS book. My list of dependencies looks something like this: libz, freetype, libressl instead of openssl, xproto, util-macros, inputproto, xextproto, kbproto, libxdmcp, bigreqsproto, xcmiscproto, libxau, pixman, glproto, fixesproto, damageproto, randrproto, renderproto, fontsproto, compositeproto, recordproto, scrnsaverproto, resourceproto, xineramaproto, libfontenc, xtrans, libx11, libxext, libxkbfile, freeglut, khronos-opengl-registry, font-util, libxfont, mkfontdir, mkfontscale, bdftopcf, libxml2, fontconfig, font-bitstream-75dpi, font-bitstream-100dpi, font-bitstream-type1, font-misc-misc, font-cursor-misc, font-xfree86-type1, font-alias, xkbcomp, intltool, pciaccess, xorg-server
I’m missing some drivers in that list. The following aren’t Xorg specific: libz, freetype, freeglut, khronos-opengl-registry, libxml2
3 Likes
Most of my experience is with configure.
I regularly build R from source and it uses configure and make.
cmake is a beast.
2 Likes
Has anyone used linuxkit.?
It is meant for building Linux images that run in containers.
1 Like
Keep wondering why it’s so popular when everyone I talk to doesn’t seem to like it. It does work without requiring extra languages like Perl and m4 be on your system. Plus, it can work without a bash shell. That’s the only advantage I see to it. I just feel like it tries to do too much. I’ve never been able to bootstrap build it so forget trying to build from source for a project like LFS. It’s always looking in the wrong directories for my libraries and include files and it’s a nuisance to try to correct for that.
2 Likes
What exactly do you mean by a build script? … of course it means a bash script that does a build… but why use that rather than a Makefile?
I am sure you have a good reason… am I missing something here?
1 Like
According to its history, one of its big selling points was cross-platform support. Not just a little bit, but in the order of using the same script to build on any platform supported by cmake.
Integration is another of its big selling points. It’ll cheerfully work with Visual Studio on Windows, KDevelop on Linux, and XCode on MacOS. Vim and Emacs probably have some integration plugin available for it as well. I remember seeing sublime text integration as well.
However, it has a huge problem: the age-old adage “the code is your documentation” goes especially for cmake as its documentation is absolutely horrible. Yes, it explains the basics, but that frequently isn’t enough.
I guess Kitware draws one of its income streams from people needing to learn cmake.
2 Likes
While some systems use make to do everything in their builds, I typically use make just for compiling the source. I use a shell script to download the source, do checksum checks, unpack it, run configure, make, make install or whatever instructions are needed to compile and to package the results in a tarball that can be installed on the system. It’s a lot like Slackware handles building packages with a slackbuild script. The biggest difference between my scripts and Slackware slackbuild scripts is that I use templates to create my scripts. So, if common parts change, I can programmatically regenerate the scripts with the changes rather than having to edit each slackbuild script by hand and make the change manually in each.
2 Likes
I built libX11 with musl a while ago. Going to try building it again with my scripts and musl on a current version of Debian and see how it goes.
1 Like
LFS uses Cmake to install a lot of packages but more and more packages are using Ninja.
About all Python packages are using pip3.
I now have over 200 BLFS packages installed, and am working on Mesa and all the dependencies plus working on updating my wife’s flower beds!!! Always something to do!!!
1 Like
OK, thank you, I understand.
I have always done all those steps by hand.
Yes, I think using make to do any more than the compile is a bad move.
You are a long way ahead of me
When configure finds missing dependencies, how do you deal with the installs needed in your script? That must be affected by which package system your distro uses.
1 Like