Extension Development :: gnu-utils

I played around with coreutils.uci - as said, it could use findutils, sed, wget, etc in order to be a gnu-utils (less xlibs) replacement.

To avoid path errors, it would be good if there were a loader script to move the busybox symlinks to /tmp and then move them back again on unloading (assuming the coreutils apps were linked to /opt/bin)...

Thanks for the pointers on alsa - I didn't try yet, but I guess using alsa-init once coreutils.uci is loaded would probably do the trick.

I just compiled the latest wget and procps yesterday, using compile-3.3.5.uci + term.h and the ncurses headers from gcc1-with-libs. They'll be submitted as uci extensions soon, but I'm about to do coreutils and findutils and hopefully upload them all together.

Quote

To avoid path errors, it would be good if there were a loader script to move the busybox symlinks to /tmp and then move them back again on unloading (assuming the coreutils apps were linked to /opt/bin)

The existing coreutils.uci was made long before /opt/bin was added to PATH. Even after it was added, though, I'd thought about this and decided to stick with the current arrangement for future releases. The /opt/bin directory is at the end of PATH, as you are apparently aware, so those files would not be used without removing the original symlinks (as you said). However, I don't personally like this idea for two reasons: it's simpler to just modify the PATH variable (The process is stated in the info file), and the directories containing the busybox symlinks may be read-only (as they almost always are on my system).

Quote

...using compile-3.3.5.uci + term.h and the ncurses headers from gcc1-with-libs.

- is there are problem with the ncurses headers in compile-3.3.5?

To be honest, I simply assumed it wasn't there because this was the second application I'd tried to build that said it couldn't find ncurses.

Now that I think of it, with procps I eventually had to look into the Makefile and discovered that ncurses was set using an absolute path for some silly reason. At that point I should have thought to double-check if the headers were in compile-3.3.5.

I can't remember right now what the first curses app was...may have been htop, since I know that's one I've recently failed to build. I just know that twice in the last week or so I've had a compile failure due to a missing ncurses.h
I'll try to find another to test sometime soon.

Keep in mind that I'm no wiz when it comes to understanding how the whole compiling thing works. All I do is export CFLAGS, CPPFLAGS, and LDFLAGS and then try the build.

I've had a few compile errors due to issues over ncurses - doing the following sometimes fixes it:

Code Sample

export LIBS=" -lncurses"

To see if there was a problem using compile-3.3.5 with procps, I tried with procps-3.2.7 and got the following error:

Code Sample

$ make SHARED=0
...
pwdx.c: In function `main':
pwdx.c:38: error: `PATH_MAX' undeclared (first use in this function)

- fixed by adding the following to pwdx.c:

Quote

#include <sys/param.h>

- but I didn't get any errors involving ncurses (without the export LIBS= mentioned above)?

Note (I think) the ncurses headers in gcc1-with-libs are for a later version of ncurses than that in dsl (libncurses.so.5.3), but that probably doesn't change anything...

Next Page...
original here.