[Aboriginal] GCC - messed up search dirs

Paul Onyschuk blink at bojary.koba.pl
Sun Jan 22 07:37:00 PST 2012


This may very well lead to offtopic, but I feel that I need to explain
myself better.  Sadly my writing in English isn't on the level I would
like it to be.  This message ended up much longer than I planed,
apologies for that.

What is Pkgsrc?  In short portable ports-like system for building
software and handling dependencies (it works on some weird platforms, I
will go into that later).  Descriptions like that can be found
everywhere, although most of the times they don't provide informations
about pkgsrc technicalities.

Pkgsrc is pretty much a big bag of makefiles and nothing else.  Those
makefiles aren't GNU make compatible, instead NetBSD bmake is used.
Makefile of cp(1) from NetBSD source tree is a good example how bmake
is used:

> 
> PROG=	cp
> SRCS=	cp.c utils.c
> 
> .include <bsd.prog.mk>
> 

As a side note FreeBSD is using currently pmake, which is similar to
bmake, but has some different subtleties.  OpenBSD is also using bmake,
it was inherited when Theo de Raadt forked off from NetBSD.  Since then
OpenBSD bmake was maintained independently, so right now it isn't the
same compared to NetBSD version.

Second side note.  This isn't related to Aboriginal Linux, but could be
interesting for toybox project (or not).  Some time ago MINIX project
started replacing their userland tools with NetBSD counterparts.  It
got me thinking if *BSD userland can be ported to Linux (uclibc based
to be specific).  I started with OpenBSD tools, but it quickly turned
out that those were heavily using OpenBSD libc specific features (I will
not go into the details).

On other hand porting NetBSD tools was in most cases trivial.  Some
informations about this effort can be found in my github repository
[1].  This link leads to wiki page with some details about porting
software from NetBSD, some tools can be found in the same repository.
I used brute force, especially when it comes to macros. Also makefiles
are ad-hoc solution.  I was going to start from scratch and make it
right, but that never happened.

Back to Pkgsrc.  Pkgsrc is released every quarter, which makes it
easier to use for external projects and not only NetBSD (release timing
and so on).  Currently pkgsrc is used also by DragonFly BSD, SmartOS
from Joyent (Solaris based system) and there are big efforts in MINIX
project to use it as official solution for providing third party
software.  It isn't perfect solution, Pkgsrc has own quirks, but it
gets job done and BSD license makes it even more attractive.

I introduced some confusion in previous message, when speaking about
Pkgsrc bootstrapping, so I will describe the process.  It starts with
fetching tarball "full of makefiles" [2], typically it is unpacked
under /usr (/usr/pkgsrc is main tree in this case).  Alternatively It
can be unpacked under user home directory and bootstrapped without
privileges (nice feature, because you can keep more than one Pkgsrc
version e.g. with different settings).  I pointed out dependencies in
previous message.

Then bootstrap script (it can be found under /usr/pkgsrc/bootstrap, it
just a shell script) is used to build some common tools used by Pkgsrc,
bmake is one of those.  Because Pkgsrc is designed to support so many
systems, some additional tools can be built e.g. if system only
provides old awk or sed isn't compatible enough and so on.  The same
goes for Busybox awk (one of the tools built by bootstrap is using long
awk script - I don't remember which one), but fix for that is trivial:
change "need_awk" to yes on line 596 in bootstrap script.

Another side node.  I "ported" (ported is too big word to describe that
in my opinion) some software from one to another system and I can say
that awk is one of the biggest offenders there.  Some software provides
GNU awk specific scripts in their build system (command line flags and
other features).  This creates problems, when porting software to *BSD,
because those are using "One True AWK" by Brian W. Kernighan aka
bawk/nawk.  In most cases this is just build dependency, so it is
easier to provide gawk than fix awk scripts in every 3rd party
software.  Scripts written for nawk, work just fine with gawk, but not
with Busybox awk in some cases.

Of course I could fix awk script in Pkgsrc bootstrap case, but I have
been there and I know that using Busybox awk with Pkgsrc will hit you
later, when building other software.  Pkgsrc already distinguishes
software that uses GNU awk - it is listed as make dependency in
makefiles.  As for everything else, it easy to specify if Pkgsrc should
use version provided by system or use own version: 

> 
> TOOLS_PLATFORM.awk= /usr/pkg/bin/nawk
>

This is good example of Pkgsrc properties.  Where other solutions are
integrated heavily with system, Pkgsrc is quite opposite.  Pkgsrc
coexist with existing system infrastructure, but should never mess up
system libraries and other things (in the end /usr/pkg can be removed
without worries).  This opens also interesting options e.g. you can
bootstrap pkgsrc-2011Q4 under /usr/pkg prefix and have another version
let say pkgsrc-current (non-stable version, moving target)
under /home/user_name/pkg.  It is easy to specify what libraries Pkgsrc
should use: ncurses provided by system or Pkgsrc?

> 
> PREFER.pkgsrc= ncurses
> TOOLS_PLATFORM.nroff= /usr/bin/mandoc
> 

In first case Pkgsrc will build own version of ncurses and use it when
compiling packages - this can be also done for other libraries and even
compiler.  Wrappers are used to "hide" everything else in build process.

As for second one, I'm not big fan of Groff (I could provide long list
of reasons).  Mdocml (aka mandoc) [3] isn't a full blown replacement
for troff/nroff formatter.  Instead it supports only man and mdoc
macros, which makes it very small and fast for this purpose.  Other
than that, HTML output is high quality. Groff in OpenBSD base system
was replaced by Mdocml some time ago.  This projects provides also by
far the best guide [4] for writing man pages and history of man pages
is pure gold, if someone is interested in "computer archeology".

Back on track.  When it comes to CPP error, configure script used by
bmake has some sanity checks for environment.  It checks if compiler
and preprocessor are usable and rest is the story.  I could change
configure script, but I don't see a point in fixing something that
isn't broken.  I appreciate fast response and I'm looking forward for
using Aboriginal.

After writing all of this, one thing left is explanation for using
Pkgsrc under Aboriginal.  For anything beside basic software, tracking
dependencies can be pain in the ass.  There is no point of writing
another system just for that, when you can use existing solution like
Pkgsrc.  Moreover I would like to investigate if there is a easy way to
force Pkgsrc to use only static linking.  Pkgsrc is already used by
MINIX in some degree and this system as of time being doesn't have
support for shared libraries at all.

btw. I'm regular reader of your blog, keep it up. Thanks for all your
work.  I'm subscribed to Aboriginal and to toybox mailing lists.


[1] https://github.com/blinkkin/netbsd-coreutils/wiki/Porting
[2] http://ftp.netbsd.org/pub/pkgsrc/pkgsrc-2011Q4/pkgsrc.tar.bz2
[3] http://mdocml.bsd.lv/
[4] http://manpages.bsd.lv/

 1327246620.0


More information about the Aboriginal mailing list