Tuesday, June 16, 2015

On Building World - First Pass with FreeBSD 10 amd64/core2

With apology to the reader, though avoiding to develop an outline of a thesis about designs and implementations of operating systems, or either the difficulties before understanding the non-trivial sciences of systems in information processing and communications -- as when the schools are not even teaching from the sciences -- but simply, as a note of some text printed by the FreeBSD 'clang' compiler, this morning, I've noticed some of an error output like the following when building FreeBSD from the releng/10.1 branch., the source code from the FreeBSD repository at GitHub.
/usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:17:8: error: register %rdi is only available in 64-bit mode
 movl (%rdi),%eax
My not being a great aficionado about compiler toolchains, then after that message was produced and the build halted, I discovered the availability of the the stable/10 branch, in the same FreeBSD Project's source code repository. I've now made a local freebsd_10 branch drawing from the same upstream branch, and will proceed to....
make buildworld DESTDIR=/usr/local/myworld
...hoping that perhaps it may build, this time. I'm compiling the FreeBSD source code, with /etc/make.conf containing the following
COPTFLAGS?= -O -pipe

Albeit, those were somewhat some arbitrary selections, but it seems to have worked out, so far.

Why would I be enjoining myself to this perhaps seemingly masochistic task, this morning? Initially, I'd thought that it could make a nice result tree for a compiler jail for Poudriere's build automation, such that I might then apply -m null -M /usr/local/myworld for re-using the built objects when applying the poudriere jail command. If the packages could be built against a compiler-optimized core system -- as I'd thought might this morning's make may have produced -- then if that would work out, to apply the compiled world in a process of build automation with Poudriere, then I'd thought, I would consider installing the same /usr/src world onto my host's own root partition, perhaps  then even trying to package it up for installation onto my own amd64 laptop.

Later, I'd thought, I might be able to trust if I've understood how the FreeBSD build process works, well enough that I might then endeavor to build an ARM world -- that, as for applying FreeBSD with BeagleBone Black single-board computers in my own LAN. So far as the LAN design, that much would be trivial, pending the successful installation of a stable, trusted, and uncluttered operating system for the LAN's appliances. I've certainly selected FreeBSD at that -- no more to find interference from NetworkManager about the contents of /etc/resolv.conf -- but, so to speak, the Pokemon ball is just staying welded shut.

Personally, I think that I'm wishing now that the whole build process could be more modularized, in FreeBSD, but not to leverage any kind of an agenda about it. I only wish that I would not have to rebuild the entire FreeBSD local world  if to simply rebuild a component that had failed in the previous build process.

There is one positively simple thing that I've learned, in this morning's effort thus far, namely: That rather than
/bin/fie 2>&1 | tee /some/fum.log
There's a much simpler syntax available with the script shell command:
script /some/fum.log
/bin/fie ...
...such that the script command conveniently receives text printed to both of the standard output and standard error streams, prints the text to the console, then also prints the text to the log file.

So clearly, there are some real reasons for reading the FreeBSD handbook. I believe it's all something to do with knowledge.

No comments:

Post a Comment