Re: Few notes&questions on NetBSD building and on wedges included by default
On Tue, Sep 24, 2013 at 07:33:45PM +0100, scft wrote: > Hi, NetBSD mailing lists. > > I'm intending to cross-build NetBSD to try it out. I very much liked project > goals, as well as emphasis on code clarity and portability. > Minimalism and perfectionism are attractive. > However, i have one practical question (which is 2.) and a few > suggestions\fixes on building process. > > 1. I'm actually do cross-building because installer fails with "wd0: device > busy" (googling for further info i found out that it's because of some thing > called wedges.). > Then why to include this unnecessary whistle by default? The goal of defaults > is by definition to fit to most users. Either fix sysinst, or kernel config! It is needed to support GPT partitions, which is needed to support > 2TB drives. What version of NetBSD are you trying to install ? I though this had been fixed ... > > 2. The only value for x86 architecture is i386. Which obviously means that > new features from >i486 are not included, sse is (i guess) not included, amd > k8 & opteron optimizations are not included... It is possible to fine-tune > these settings in FreeBSD (see: > http://svnweb.freebsd.org/base/head/share/mk/bsd.cpu.mk?view=co). Judging by > absence of such in /usr/share/mk of NetBSD, it is not possible to get this > without DIY there. Why not to implement and document this? Actually the system is built for i486. You can tune this with CFLAGS I guess. e.g. build.sh -V CFLAGS="-march=nocona" CFLAGS is documented in share/mk/bsd.README, with most other tuneable variables > It is not even explained anywhere, what's the difference between MACHINE and > MACHINE_ARCH. BUILDING says that MACHINE_ARCH should always be an exact > architecture, MACHINE may be not. And it says that by saying that first is > "architecture", second is "type" Very straightforward. You should'nt need to set theses, build.sh takes care of this for you. > > 3. I've also found a bug in BUILDING documentation file. It says that > HOST_CXX is a C++ compiler. Yet setting HOST_CXX to g++ makes build,sh fail > with messages like "C preprocessor fails sanity check". By setting HOST_CXX > to c preproc, i have no such messages. > > 4. There is no option to actually set c++ compiler then. Groff needs it and > fails without it. So i have a choice between hacking makefiles and setting > MKGROFF=no. I chose second - nobody loves to hack makefiles. Especially those > makefiles that are written by other people. > I suggest you to implement HOST_CPLUS feature. > CPLUS, not CPP. So that nobody'll be confused with cpp\cxx. Why do you need to set HOST_CXX at all ? build.sh does TRT for me, on both NetBSD and linux. > > 5. mk.conf is somewhat badly documented. E.g. i've found new mk.conf options > in makefiles, which are not listed in documentation. Some options listed in > mk.conf(5) are not listed in BUILDING or handbook, and vice versa. Be carefull, there are some variables used in Makefiles that are not intended to be set in mk.conf. > > 6. libc fails to build with MKPICLIB=no, saying that '-lgcc is not found'. > Even though i've found that i actually need MKPICLIB set to yes, seem as a > bug. (This happened when i tried to crossbuild it on both FreeBSD and on an > unpopular Ubuntu Linux derivative.) Maybe you should use MKPIC=no ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Few notes&questions on NetBSD building and on wedges included by default
> It is needed to support GPT partitions, which is needed to support > 2TB
> drives. What version of NetBSD are you trying to install ?
I tried 6.1.1 nightly, obtained from "ftp://nyftp.netbsd.org";
I'll use MBR then, my system isn't EFI one.
> Why do you need to set HOST_CXX at all ?
Didn't knew it can guess.
> Maybe you should use MKPIC=no ?
No luck. It fails again, and the solution is unknown contrary to -lgcc case.
(Seems that lgcc is an optional library with useless features, and NetBSD has
no GCC-dependent code, except for build.sh\makefiles, -lgcc flag could easily
be deleted. Also, lgcc errors actually do happen when LINKLIB=no, so the other
solution is to comment it out).
mk.conf configs are tricky and non-straightforward too - if i set MKPIC=no, i
surely will have problems with pkgsrc packages.
MKPIC sets not only the way of linking, but also the necessity to build shared
libraries.
I expected "MKLINKLIB=no" + "MKSTATICLIB=no" + "MKPIC=no" to:
1. do not neccessairly install static libraries, but to build them and use them
for linking
2. build shared libraries, then cp\mv them into the resulted system.
What i got: error, Nbmake lacks some .a library for something, That's because
MKSTATICLIB configures if the static libs are actually built or not, not only
if they are installed.
Too complexly made...
But still, even with MKSTATICLIB=yes, i've got errors.
Linking-related configs:
"""
MKDYNAMICROOT=no
MKLINKLIB=no
MKPIC=no
MKPICINSTALL=no
MKPICLIB=yes# it (+MKLINKLIB=no) may still generate shared libraries, if no
- we could make them on our own, without position-dependent-code difficulties
MKPIE=no
MKPROFILE=no
MKSTATICLIB=yes
"""
Part of build log:
"""
install ===> lib/../external/bsd/am-utils/lib/libamu
(cd "/usr/nbsrc/external/bsd/am-utils/lib/libamu" && HOST_SH=/bin/sh
AWK=/usr/nbtools/bin/nbawk /bin/sh /usr/nbsrc/lib/checkver -v
/usr/nbsrc/external/bsd/am-utils/lib/libamu/shlib_version -d
/usr/nbdest/usr/lib amu)
_makedirtarget() { dir="$1"; shift; target="$1"; shift; case "${dir}" in
/*)this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/usr/nbsrc/lib" ;; *) this="lib/${dir}/";
real="/usr/nbsrc/lib/${dir}" ;; esac; show=${this:-.}; echo "${target} ===>
${show%/}${1:+ (with: $@)}"; cd "${real}" && /usr/nbtools/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
../external/bsd/flex/lib install
install ===> lib/../external/bsd/flex/lib
nbmake: don't know how to make /usr/nbdest/usr/lib/libl.a. Stop
nbmake: stopped in /usr/nbsrc/external/bsd/flex/lib
*** Failed target: install-../external/bsd/flex/lib
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/usr/nbsrc/lib" ;; *) this="lib/${dir}/"; real="/usr/nbsrc/lib/${dir}" ;;
esac; show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /usr/nbtools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; };
_makedirtarget ../external/bsd/flex/lib install
*** Error code 2
Stop.
nbmake: stopped in /usr/nbsrc/lib
*** Failed target: do-lib
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/usr/nbsrc" ;; *) this="${dir}/"; real="/usr/nbsrc/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}"
&& /usr/nbtools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; };
_makedirtarget lib install
*** Error code 1
Stop.
nbmake: stopped in /usr/nbsrc
*** Failed target: build
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/usr/nbsrc" ;; *) this="${dir}/"; real="/usr/nbsrc/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}"
&& /usr/nbtools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; };
_makedirtarget . do-lib
*** Error code 1
Stop.
nbmake: stopped in /usr/nbsrc
ERROR: Failed to make build
*** BUILD ABORTED ***
"""
Apparently, it can't handle MKLINKLIB=no again.
Maybe (and probably) i'm doing something wrong. Having support for totally
static system with shared libraries for pkgsrc would be much apperciated.
Anyways, i've built (not without hacks) "static base"+"dynamic /usr" netbsd
successfully, and have no problems with building currently, Now i'm figuring
out how to do partitioning\labeling propertly and dual-booting with linux.
Re: Few notes&questions on NetBSD building and on wedges included by default
> Having support for totally static system with shared libraries for pkgsrc > would be much apperciated. Just found it, but didn't tried yet. # echo "LDSTATIC=\"-static\"" >> /etc/mk.conf
Re: Few notes&questions on NetBSD building and on wedges included by default
On Tue, Sep 24, 2013 at 2:33 PM, scft wrote: > Hi, NetBSD mailing lists. > > I'm intending to cross-build NetBSD to try it out. I very much liked project > goals, as well as emphasis on code clarity and portability. > Minimalism and perfectionism are attractive. > However, i have one practical question (which is 2.) and a few > suggestions\fixes on building process. > > 1. I'm actually do cross-building because installer fails with "wd0: device > busy" (googling for further info i found out that it's because of some thing > called wedges.). > Then why to include this unnecessary whistle by default? The goal of defaults > is by definition to fit to most users. Either fix sysinst, or kernel config! > I'm not sure this is necessarily the case, but why not? > 2. The only value for x86 architecture is i386. Which obviously means that > new features from >i486 are not included, sse is (i guess) not included, amd > k8 & opteron optimizations are not included... It is possible to fine-tune > these settings in FreeBSD (see: > http://svnweb.freebsd.org/base/head/share/mk/bsd.cpu.mk?view=co). Judging by > absence of such in /usr/share/mk of NetBSD, it is not possible to get this > without DIY there. Why not to implement and document this? > It is not even explained anywhere, what's the difference between MACHINE and > MACHINE_ARCH. BUILDING says that MACHINE_ARCH should always be an exact > architecture, MACHINE may be not. And it says that by saying that first is > "architecture", second is "type" Very straightforward. > You may not want to make so many assumptions about x86/i386. FreeBSD build system is not the same as NetBSD. The make files are different. > 3. I've also found a bug in BUILDING documentation file. It says that > HOST_CXX is a C++ compiler. Yet setting HOST_CXX to g++ makes build,sh fail > with messages like "C preprocessor fails sanity check". By setting HOST_CXX > to c preproc, i have no such messages. > > 4. There is no option to actually set c++ compiler then. Groff needs it and > fails without it. So i have a choice between hacking makefiles and setting > MKGROFF=no. I chose second - nobody loves to hack makefiles. Especially those > makefiles that are written by other people. > I suggest you to implement HOST_CPLUS feature. > CPLUS, not CPP. So that nobody'll be confused with cpp\cxx. > I'm willing to bet this is more of an issue with how you executed the build. > 5. mk.conf is somewhat badly documented. E.g. i've found new mk.conf options > in makefiles, which are not listed in documentation. Some options listed in > mk.conf(5) are not listed in BUILDING or handbook, and vice versa. > true > 6. libc fails to build with MKPICLIB=no, saying that '-lgcc is not found'. > Even though i've found that i actually need MKPICLIB set to yes, seem as a > bug. (This happened when i tried to crossbuild it on both FreeBSD and on an > unpopular Ubuntu Linux derivative.) how are you executing build.sh?
