Changing default C compiler and C libraries

[Someone]

After reading the opinions in www.suckless.org/sucks and www.suckless.org/rocks i would like to change the default compiler for ports from clang to tcc (tiny c compiler), also the default c libraries to musl. I am willing to get down and dirty with configuration,even code while doing so, and even forfeit the use of programs that refuse to work. I have already purged bloated and really unneeded stuff like dbus. So how could start going on using my compiler and c libraries of choice for ports? Thanks.

PS: i dont mind my system being unusable until fixing it, doing nothing critical on it. I also see this as a learning experience.

 

[resora]

I understand you, I'm also for complete minimalism, while everyone is demanding GIT, I'm talking about FOSSIL SCM, I'm also writing about the cross-platform pkgsrc package system, but everyone still wants to create their own "crutches", I wanted to compile pkgsrc in termux

 

[tembun]

While I understand the disire (I had something similar myself), I think I would still suggest you not doing this, at least probably not now; as I decude from you post, right now you don't have very much experience with all this stuff. Why? Well, because it will likely be a tremendous amount of work and will take a looota time. It took FreeBSD team several years to switch the default compiler from gcc to clang(1) (for both the base and the ports tree). The problem is - compilers are complicated pieces of software. And even though the standards exist, they still behave differently. They can produce code differently, or optimize code differently, or treat errors and warning differently. The ports tree is huge. The base system is relatively huge too. A lot of source code involved. Changing the compiler for this amount of source code will inevitably break things. I mean, stuff will likely not even compile in the first place. By even if it compile, how do you know this didn't affect the program behaviour? I'm now even talking that some programs are written with a specific compiler in mind (that is, the author thinks that gcc (or any other) is the only compiler in the world), and using this compiler-specific features.

All this and other factors I perhaps forgot to mention make it a PITA. A REAL PITA. Of course, I didn't even remotely do such work myself, so I can't say this is a PITA, because I didn't feel it myself However, I can imagine it, and I believe people being involved in this, and who succeeded doing it. Being a gcc user (when I was using Linux distros back then) for quite some time, I love LLVM toolchain (including clang(1)), to me, it's much better.

Speaking of people involved: there are two great bsdtalks (interviews) with FreeBSD committers about switching the default compiler for FreeBSD base and ports from gcc to clang:
-first
-second
Check out especially the first one - it's 1 hour long and it's very interesting: it explains in great details how that process was going (like what I was describing above, but in more details and with more examples). It's a great talk and I love it! It's one of my favorite bsdtalk's one, actually.

But still, like a said, I don't object and I can't tell you what to do: perhaps, you are able to do it yourself (and I believe everybody can do anything if they want it), however, I just to warn that probably the result in your case won't worth the effort. I mean, it did make sense to change the compiler for a whole FreeBSD project (see (or 'listen') bsdtalk above), but I don't think you will actually benefit from doing it yourself. Don't forget you'll have to maintain a whole host of software with every update or a compiler change. It can break at any moment.

Hoo, that's getting too long, I'll wrap up Hope that helps!

 

[SirDice]

i would like to change the default compiler for ports

There isn't a single default compiler besides the one that comes with the OS (which will be different with each version). Ports can request various different ones.

Chapter 17. Using USES Macros

USES macros make it easy to declare requirements and settings for a FreeBSD Port

docs.freebsd.org

freebsd-ports/Mk/Uses/compiler.mk at main · freebsd/freebsd-ports

FreeBSD ports tree (read-only mirror). Contribute to freebsd/freebsd-ports development by creating an account on GitHub.

github.com

 

[drhowarddrfine]

I just to warn that probably the result in your case won't worth the effort. I

Agree and it might be pointless cause nothing is to be gained except the size of the compiler but nothing is stopping one from switching compilers for personal programming. Even then, what's to be gained? And what is lost?

Personally, I despise git, and also like Fossil, and always complain that the only reason--THE ONLY REASON--everyone is using it now is because Linus made it and uses it so everyone else on Linux had to use it which forced that pile of developers and programmers had to use it despite there being better things out there for years before.

 

[Someone]

Agree and it might be pointless cause nothing is to be gained except the size of the compiler but nothing is stopping one from switching compilers for personal programming. Even then, what's to be gained? And what is lost?

Personally, I despise git, and also like Fossil, and always complain that the only reason--THE ONLY REASON--everyone is using it now is because Linus made it and uses it so everyone else on Linux had to use it which forced that pile of developers and programmers had to use it despite there being better things out there for years before.

Basically at this point i have significant free time and messing with c compilers and libraries looks like fun instead of a chore

 

[Maturin]

PS: i dont mind my system being unusable until fixing it, doing nothing critical on it. I also see this as a learning experience.

Basically at this point i have significant free time and messing with c compilers and libraries looks like fun instead of a chore

As tembun already explained,
writing C programs yourself - being already pretty versed in C programming is a given before one even thinks of such a stunt - and compiling the one or the other port with a different compiler - for which you pretty well know why you're doing that - is a huge difference to changing the pillars your world stands on.

Of course, this will teach a lot about C programming and the system, of course.
Question is, are you aware of the scale of this job you have in mind?
If this is really what you want to dive into, my recommendation was: Build your own system. Don't get me wrong: I do not want you to leave FreeBSD. For sure not. In contrary. But IMO that task was better to achieve bottom-up instead top-down - start by scratch on an empty sheet, instead of ripping down a large, coherent, complete and complex system to its foundation, and then rebuild it again. That's putting the cart before the horse. If you want to learn how aeroplanes work, you start building simple gliders first, then attach motors, etc. But replacing the wings of an airliner just to see what happens will not teach you much, except that thing will either not even take off or crash, Duh!
Particulary before you start messing and risking your system - naturally you already have a bullet proof backup routine, of course. Nothing really ever can happen, except you spend some time to restore, right? - You need at least one reliably running system.
So, build a second system parallel: on another machine's hardware, in some VM.
Get some kernel sources (some old FreeBSD kernel, maybe NetBSD, maybe an old Linux kernel, if available maybe minix... - what you can get, what you like - the smaller and simpler, the better. Start small - bottom-up.
See to get it compiled with the C compiler of your choice. Then pick a bootloader (again, compile it.) Then see to get a running system: the bootloader you compiled loads the kernel compiled by yours. It will be not much to use, but that's not your point anyway - you wanna learn how the things work. But it was a crucial start anyway. Next will be the software packages you need and want to make the system useful: Those also need to be compiled with the compiler of your choice and get them running under your system.

I believe, this way will teach you more, better and faster, what you want to learn, with way less trouble.
Start some journal/blog to write down what your goals were you gave yourself, what you did, how it came out, and what your conclusions are for each step, was not only interesting to others, but above all very helpful for yourself. And anyway it will record your successes, no matter how far you get.

 

[resora]

It would be possible to create a separate branch in FreeBSD Ports or pkgsrc called "litepack". It would contain lightweight software packages that are built using:
USES+= tcc
The idea is similar to what is often done in the Linux world, where people create lightweight distributions for older or low-end laptops. However, many of those distributions don't see long-term use because, aside from Linux itself, they don't offer much that is unique. A litepack repository would take a different approach. Instead of creating yet another operating system, it would provide a curated collection of lightweight applications that can be installed on existing FreeBSD or NetBSD systems.
For example, in one Linux distribution I counted roughly 7,000 installed packages, while only about 2,500 were actual applications. The remaining packages were mostly libraries and dependencies. A lightweight package collection built around TinyCC and minimal dependencies could significantly reduce that overhead for software where this approach is practical.

 

[kent_dorfman766]

Basically at this point i have significant free time and messing with c compilers and libraries looks like fun instead of a chore

Then I would suggest spending your time learning about the build systems and understanding how sane build systems use macros to define the chosen compiler, linker, and options. If you want to mess with default compiler options then going this route will give you more bang for the buck.

 

[bakul]

i would like to change the default compiler for ports from clang to tcc (tiny c compiler),

Note that while tcc is much faster at compiling, it has some limitations. For instance it doesn't understand __attribute__, a nonstandard feature introduced by gcc and adapted by clang and have leaked into /usr/include files. Language V for instance uses tcc by default and it has issues on freebsd.