Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

BSD alternatives to coreutils (Developers)

posted by lmemsm Homepage, 22.01.2014, 14:33

marcov wrote:
>_on_ or _for_ ? Many issues can be avoided by crosscompiling I assume

As I mentioned, my preference would be for native DOS (although definitely with LFN support). One of my project goals is cross-platform portability. If I need to set up a djgpp build environment on Linux in order to build the Open Source applications I want, I might as well just build those applications for Linux and use them there. It's certainly less effort and less porting.

Toybox and Busybox are very similar to what I have in mind only I'm not sure if it really needs to be one monolithic program. Busybox has been ported to Windows (more recently than coreutils), but both Busybox and Toybox seem to be very POSIX oriented (as in, they expect standard POSIX functions as part of the C library). I agree with Ibidem's assessments. Based on some of Rob Landley's comments on the musl mailing list, I got the idea it wasn't a very good base for cross-platform work. I do like the goals of the project though. Sbase looks a lot more promising from a portability standpoint but, as Ibidem mentioned, it's a very minimal implementation without full POSIX compatibility support. I didn't want to start completely from scratch, so I'm currently considering starting with bits and pieces of the Minix utilities and some of the Obase/NetBSD/FreeBSD utilities along with some base libraries to factor out common functionality. Would like UTF-8 support so utilities like grep or wc can work on UTF-8 files. I'm using some of the data from files at http://www.unicode.org/Public/ and modeling parts of the utf-8 library on something similar to Plan 9's Rune library. Have functions like towupper, towlower and iswalnum working for utf-8/Unicode (32 bit), but the library is still a work in progress.

Georg wrote:
>As you are probably aware djgpp has autotools. However, these seem to be very old versions which do not work well (i.e.not) with current software packages.

I've been using GNU autotools with djgpp to some extent, but seems to fail with more projects than it succeeds. Thought perhaps I was missing something and that it worked better. Anyone else having good luck with it?

It would definitely be nice to have GNU autotools working reliably so one doesn't have to keep creating/editing makefiles every time a program has updates. The CoApps project is attempting to go from GNU autotools scripts to native Visual C++ build files so they don't have to continually create build files when Open Source projects update.

With djgpp, at first, I couldn't get past some of the configure files trying to find programs like sed and grep. I set the SHELL environment variable to bash and that got me farther. Now some of the configure scripts are failing when they run utilities like sed, ln, cp, mv. I think it's an issue with the file names using Unix style slashes rather than backslashes. On Windows, some C functions (although not all) work fine with slashes or backslashes in file names. Would like to add that type of support to the base utilities I'm working with. Hoping that will get things a little farther.

It would be nice to update some of the versions of the autotools programs, but it's certainly going to be a lot of work to update the entire autotools system. I have m4, autoconf, automake and make building natively on Windows. Haven't been able to test or debug the ports because you can't mix msys utilities with native ones. The paths get all messed up when you try. The djgpp environment, however, is completely native. So, if I can get some of these tools building and ported for DOS, might be easier to debug things there. I also did some experimenting with building Perl and micro-Perl on Windows, but getting a later version of Perl to work does not look like an easy goal for non-POSIX compatible systems. I do like the micro-Perl concept, but it's not enough to run GNU autotools. One needs several Perl scripts in the proper locations for GNU autotools to work. Rather than a complete update of GNU autotools and related utilities, I'd settle for just enough support to be able to build programs in a reliable fashion with minimal intervention from the developer. (Still not a small project though.)

I know where source code is for the djgpp programs/utilities, where Georg's Nano-x/FLTK programs are and a few other DOS code repositories. If there are any other good locations to find ports of Open Source programs and the patches to get them working on DOS, please let me know. I'd be very interested in looking at some of the patches needed for DOS. Thanks. On a more positive note, I am getting a little farther at getting some Open Source programs to build using my automated package management/build system and my current djgpp environment. It's still buggy, but I got Emilia Pinball building and working well enough to play pinball.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (2 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum