[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autoconf build targets

matthew green wrote:
Looked like a bourne shell to me. Default root shell is /bin/csh on FreeBSD, but I believe /bin/sh is basically the same as ash. Interestingly, MAKEDEV fails to work with bash but works fine with ash.

i'm not sure about freebsd, but netbsd has used ash in /bin/sh
for a Long Time.  i even thought the debian one was based on the
netbsd sources but i could be wrong on that point.

You are correct. FreeBSD has it's version of the same shell in /bin/sh. The Debian ash package is based on an old version of NetBSD's sh.

Unfortunately, Debian installs /bin/sh as a symlink to /bin/bash. Supposedly, /bin/sh is supposed to be "a Posix-compatible shell," but in practice Debian sources and scripts may fail when /bin/sh is changed.

FreeBSD sources fail to build with /bin/sh set to /bin/bash. I basically do s#/bin/sh#/usr/bsd/bin/sh#g right now. Later I may try using the ash package. I'd still have to change the sources.

>>Since bash is default /bin/sh, and >>since what exactly is /bin/sh is subject to change by the user, this >>must be patched in the source to use something other than /bin/sh. >>Either that or fix the scripts so they will work with bash. I don't have >>time to do the latter, and it'd be more work to maintain.
   > Agreed, I just say that something other should be a Debianised shell
   > like /bin/csh preferably to the /usr/bsd/bin/sh hierrachy.
sh is one of the tools it needs to build the source. There are several others: skaro:/# ls /usr/bsd/bin
   byacc       gcov        kas       kgdb      kranlib   make       patch  yacc
colldef gensetdefs kc++filt kld kreadelf mkdep sh yyfix
   compile_et  install     kcc       knm       ksize     mknod      tcsh
   csh         kaddr2line  kcpp      kobjcopy  kstrings  mktemp     tsort
   find        kar         kgasp     kobjdump  kstrip    objformat  xargs
And yes, all of these are things for which I can't presently substitute the regular versions of these from Debian packages. :( Several of the tools are there because they have incompatible options to GNU versions. find and install for example. Others are apparently BSD-specific, like gensetdefs or compile_et.

(dunno about gensetdefs, but compile_et is part of kerberos.)

There are several tools that I'm not precisely sure what they're for, but found that building FreeBSD sources without them fails. Basically I kept trying until I found all the tools wanted, and the build worked.

FWIW, in netbsd-current, basically everything is cross buildable from
several platforms (netbsd-current, netbsd 1.5, freebsd, linux,
solaris, maybe more...)  this is possible because we now build "native"
versions of all these tools before building the world.  i heard a
whisper that freebsd is starting to be interested in cross compiling
(it was a reason to ditch perl as part of the base) so maybe they'll
get to that point eventually.  in the netbsd source tree, see both
src/build.sh and src/tools... the former is a frontend script to building
stuff without having to know all the magic variables to set, etc., the
latter consists mainly of Makefile's to build native versions of tools,
eg, for lex we have:

They have a lot more to do. :(

#       $NetBSD: Makefile,v 1.3 2001/11/14 22:13:40 tv Exp $

HOST_SRCDIR=    usr.bin/lex

.include "${.CURDIR}/../Makefile.host"

	echo '#include <initscan.c>' >$@

(those ktools things scare me... i wonder why they need special
kernel wrappers/programs for all the toolchain bits...but i think i'd
be scared by the answer :-)

FreeBSD patched binutils and gcc and didn't merge upstream. Some of the patches are downright stupid, IMHO, like the one to binutils to set EI_OSABI.

The kcc, kas, ksize, etc. aren't wrappers, they're actually gcc, as, and size from the FreeBSD source tree. I renamed them and stuck them in a different directory to try to make sure that they don't get used by mistake instead of the system ones. Unfortunately, I haven't tracked down all the things that have been done to them yet, so I have to use the FreeBSD versions to make sure my kernels work...


To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: