Re: Build.sh support for GuixSD & NixOS (Thorough HOST_CPPFLAGS support)

[christos%astron.com@localhost (Christos Zoulas)]

In article <ad9467c5-6eb3-c97b-06d4-bb6f0db5fb9b%arctype.co@localhost>,
Ryan Sundberg  <ryan%arctype.co@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hello NetBSD toolchain devs,
>
>While experimenting with rumprun and building rump kernels, I had some
>patches I wanted to test to verify they did not cause any regressions in
>NetBSD proper. Unfortunately but unsurprisingly the build.sh crashed
>like nobody's business when trying to build NetBSD from a GNU Guix
>System Distribution host. Guix (and it's sister OS, Nix) are unique in
>that they do not use the traditional filesystem layout with
>/usr/include, /lib, etc., preferring to manage dependencies in new ways.
>
>
>I spent plenty of time over the last week patching build.sh and the
>Makefiles to ensure adequate support for HOST_CPPFLAGS and HOST_CXXFLAGS
>throughout the toolchain build process. Care was taken not to cross
>HOST_CPPFLAGS with standard CPPFLAGS where they don't belong.
>
>Combined with LIBRARY_PATH environment support, this makes the build
>system compatible with GNU Guix hosts. I have not tested NixOS, but I am
>sure it should support it as well.
>
>Regarding LIBRARY_PATH, I tried HOST_LDFLAGS="-L..." instead and
>unsetting LIBRARY_PATH from the make env, but this breaks in one special
>case for linking with crti.o, where it tries to resolve _lib_crti.o
>which does not exist. I think this is a gcc bug in the different
>treatment between LIBRARY_PATH=<path> and -L<path>, but I settled to use
>LIBRARY_PATH here which does not do any improper linking in the build
>output when it is present.
>
>Please take a look at the attached patch and try it out to make sure it
>does not break any of your work flows! Thank you
>
>--
>Sincerely,
>Ryan Sundberg

Thanks Ryan,

Have you tried this on a native build (building NetBSD on NetBSD). Well,
I just did and it does not work because LIBRARY_PATH is not set by default,
and when it is set to empty, it becomes "./:/usr/lib" and that seems to
break things (first thing that breaks is the gcc tools build). To wit:

[5:12pm] 1988>cc -v hello.c |& grep LIBRARY_PATH
LIBRARY_PATH=/usr/lib/
[5:12pm] 1989>env LIBRARY_PATH= cc -v hello.c | & grep LIBRARY_PATH
LIBRARY_PATH=./:/usr/lib/

I think avoiding LIBRARY_PATH is the way to go :-)

Best,

christos