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

[email protected] (Christos Zoulas)
Newsgroups gmane.os.netbsd.devel.toolchain
Message-ID <[email protected]>
In article <[email protected]>,
Ryan Sundberg  <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.