From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Staal To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Mon, 24 Dec 2012 06:56:49 +0100 Message-ID: <1498360.O0VUOEfXsy@krypton> User-Agent: KMail/4.9.4 (Linux/3.7.1-1-ARCH; KDE/4.9.4; x86_64; ; ) In-Reply-To: <366355C9-583C-4112-B8F8-8D0778257529@corpus-callosum.com> References: <20121218210257.374b3c1e@zinc.9fans.fr> <366355C9-583C-4112-B8F8-8D0778257529@corpus-callosum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [9fans] ape/errno.h Topicbox-Message-UUID: f95025e2-ead7-11e9-9d60-3106f5b1d025 fredagen den 21 december 2012 12.38.01 skrev Jeff Sickel: > Given all the Plan 9 spinoffs that still include APE, it might > be worth the effort at some point to bring APE up to SUSv3 or > SUSv4 to ease in porting code that's heavily POSIX-dependent. > > Though there might not be enough time or energy to take on > such an endeavor. > > -jas Just recently, I copied a few files from the newlib libc into an application to make it compile under APE. I guess that the "low road" to take might be to basically do the same but to generate a temporary "APE extension library" with kernel-independent libc code copied from other projects (basially similar to what gnulib does). Newlib and Musl libc are both permissively licensed so they should not be a problem to use. Musl is currently linux-specific but perhaps there are kernel- independent parts that could be used. I guess the most important thing is to make sure that the things included in the extension library does not overlap with the APE libraries. The advantage with this approach could be that the real APE keeps clean and can be developed at its own pace depending on what the needs are (and stuff found useful from the extension library could be merged back to real APE after being re-written according to the standards of Plan9).