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