acpid in 1.16.2 doesn't build on SLES 10.
Denys Vlasenko
vda.linux at googlemail.com
Tue Jul 20 02:58:36 UTC 2010
On Tuesday 20 July 2010 02:27, Rob Landley wrote:
> > However, if you need NC_110_COMPAT off, it means that you are using
> > bbox extensions in your build system, which makes it less portable.
>
> Less portable than busybox is?
I operate on the presumption that nc-1.10 is _the_ authoritative
netcat as far as compat is concerned. GNU, BSD and nmap all
screwed it up. I can't fix that, but I can do the right thing:
not screw it up myself.
> There's no portable way to launch an ftp daemon on a specific port on the
> loopback interface, providing anonymous FTP access out of a specific directory.
> There are four or five different ftp servers and their command line arguments
> are all different.
>
> The busybox ftp server doesn't have a daemon mode, it _must_ be run from
> inetd. Running inetd is only really support for root to do it, and requires a
> config file. However, you can use netcat's server mode as a poor man's inetd to
> launch a single program, which lets busybox netcat host busybox ftpd without
> require root access or a config file.
There is a "standard" tool for running inetd-like tools
without inetd: tcpsvd.
No need to invent incompatible magic netcat extensions.
ftpd even tells you how to run it under tcpsvd:
# ftpd --help
BusyBox v1.17.0 (2010-07-06 15:21:06 CEST) multi-call binary.
Usage: ftpd [-wvS] [-t N] [-T N] [DIR]
Anonymous FTP server
ftpd should be used as an inetd service.
ftpd's line for inetd.conf:
21 stream tcp nowait root ftpd ftpd /files/to/serve
It also can be ran from tcpsvd:
tcpsvd -vE 0.0.0.0 21 ftpd /files/to/serve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Anything else which precludes 1.17.1 release?
>
> Let's see:
>
> GEN include/usage_compressed.h
> od: invalid option -- 't'
> BusyBox v1.17.0 (2010-07-19 18:45:16 CDT) multi-call binary.
>
> Usage: od [-aBbcDdeFfHhIiLlOovXx] [FILE]
>
> Write an unambiguous representation, octal bytes by default, of FILE
> (or stdin) to stdout
>
> od: invalid option -- 't'
> BusyBox v1.17.0 (2010-07-19 18:45:16 CDT) multi-call binary.
>
> Usage: od [-aBbcDdeFfHhIiLlOovXx] [FILE]
>
> I.E. busybox no longer wants to build with itself, because you used an od flag
> that busybox hasn't got. (Or isn't in defconfig.) It seems to have continued
> on regardless, but it's a little distrubing.
>
> Ah, I see:
>
> #if ENABLE_DESKTOP
> /* This one provides -t (busybox's own build script needs it) */
> #include "od_bloaty.c"
>
> So your definition of "desktop" is a build system capable of rebuilding
> busybox.
Yes. applets/usage_compressed script uses od -t. There was an alternative
which meant to work without, but it broke big-endian builds.
!DESKTOP od needs to be taught -t... when ther's time.
> And you've picked up a habit of bolting an entire second alternate
> implementation of a given command on to busybox with a config switch to choose
> which one you want.
Out of about 340 applets, there are perhaps four such
duplicate applets: od, ps, nc, ping. I am guilty of three of them.
But ping isn't mine, and I even collapsed ping6 into ping.
> I'm not sure having two code paths to maintain is the path of simplicity and
> maintainability.
You are correct. When I will have time, I'll fix them one by one.
> I _do_ know it means that no matter what .config I choose, I
> can never test the full set of busybox functionality, so running nightly test
> suites is pointless.
Now "make randomconfig"-built busybox is expected to pass testsuite,
not only "make defconfig" one. Thus, it _is_ possible to test
both DESKTOP and !DESKTOP configs.
> Similarly, the linux build does this:
>
> find "$STAGE_DIR/include" -name ".install" -print0 -or -name "..install.cmd" -
> print0 | xargs -0 rm
>
> Which results in this:
>
> find: unrecognized: -or
> BusyBox v1.17.0 (2010-07-19 18:45:16 CDT) multi-call binary.
>
> Usage: find [PATH]... [EXPRESSION]
>
> I'm pretty sure that used to work. Not sure why it isn't doing so now...
>
> #if ENABLE_DESKTOP
> "-and\0"
> "-or\0"
> IF_FEATURE_FIND_NOT( "-not\0" )
> #endif
>
> Because of that. Right, I need to ENABLE_DESKTOP in order to allow my build
> system to work, because find -or is considered a desktop feature, and defconfig
> doesn't enable that. And even though find literally has 21 seperate config
> options, which is a bit much if you ask me,
It evolved into that.
> you have to enable _another_ config
> option out of another menu entirely in order to get the obscure "-and" and "-
> or" options...
>
> Right.
Do you propose to make it 22th FEATURE_FIND_FANCY_AND_OR option,
or do you want it supported unconditionally?
> Path of least resistance is to add ENABLE_DESKTOP to defconfig, I expect.
I think yes. Building kernels and toolchains is not a thing people
are expected to do on embedded platform.
If you select !DESKTOP config, it means *you* are responsible
to ensure your system doesn't use "unnecessary" things.
Like find -or, because you can use find -o, and you can make
your system smaller by abstaining from find -or and removing
that code from busybox binary.
But if you are building kernels, you *cant* guarantee* that.
Who knows what fancy things are added in kernel build machinery
tomorrow? Therefore, !DESKTOP is not a good idea for this use case.
Trying to make !DESKTOP busybox to build kernels and gcc
will basically erase all difference between DESKTOP and !DESKTOP.
I switched DESKTOP to Y by default in updated
busybox-1.17.0-build_system.patch
Please let me know whether now it builds for you.
--
vda
More information about the busybox
mailing list