similar to: 0.205 released

Signed-off-by: Gilles Espinasse <g.esp at free.fr> --- scripts/Makefile.host | 2 +- usr/klibc/CAVEATS | 2 +- usr/klibc/README.klibc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/Makefile.host b/scripts/Makefile.host index d8ab687..6a6b949 100644 --- a/scripts/Makefile.host +++ b/scripts/Makefile.host @@ -5,7 +5,7 @@ # # Both C and C++ is

This changes the RPM spec file to have -devel and -utils packages; the klibc main package is now only the runtime (plus libc.so and interp.o to avoid version skew; someone who is better at RPM than I am might be able to do the right thing with Requires and Provides to make sure there is a 100% binary match between files, using the hash code.) I'd like to let this stew for a bit, to smoke

Hopefully I should be up to date with all patches; haven't integrated the module-init-tools, and some of Erik's patches didn't make it for different reasons, which hopefully can be resolved soon. If you have sent another patch which I haven't applied, please do let me know. -hpa

please pull git://charm.itp.tuwien.ac.at/mattems/klibc/.git maks for the change: maximilian attems: [klibc] simplify nuke fixes boot failures due to unexpected error returns usr/utils/nuke.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/usr/utils/nuke.c b/usr/utils/nuke.c index 01b300f..9470bcf 100644 --- a/usr/utils/nuke.c +++

Kay Sievers wrote: > Hi, > this simple program compiled with klibc: > > #include <stdio.h> > int main(int argc, char* argv[]) > { > setenv("TESTENV", "happy", 1); > printf("TESTENV='%s'\n", getenv("TESTENV")); > } > > prints: > > ./env > TESTENV='(null)' > >

I gather from reading the back-issues of r-help that it should be possible (modulo a number of caveats) to read an excel (yuck!) file into R using RODBC. I have obtained and installed ODBC and the RODBC package, but cannot for the life of me figure out how to go about it. Can anyone give me a simple recipe? I have an excel file on cdrom, say: /mnt/cdrom/melvin.xls I have started R and loaded

I looked through the git repository, and it had some bug fixes since 1.1.16, but nothing that should affect stability. Thus, I have pushed out 1.2 as new stable release. Next up will be (a) integration work, and (b) work to eliminate klibc.git vs klibc-renamed.git trees. -hpa

Commit-ID: c3110b853f667d544717a9cdd6d96b1a2a7365bf Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c3110b853f667d544717a9cdd6d96b1a2a7365bf Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Thu, 24 May 2012 07:43:31 -0700 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Thu, 24 May 2012 07:43:31 -0700 [klibc] sys/sysmacros.h: match glibc and

It's checked in, it seems to work, it didn't bloat the system significantly, but it makes life a lot easier... I just released klibc-0.124 with the 64-bit off_t and statfs64 changes. The API shouldn't have changed, but the ABI is now 64 bits in (hopefully) all the right places. It's probably buggy... beat me up or (better) send a patch... -hpa

I have released klibc-1.0.9. This version fixes signal handing on x86-64, and on i386 with Red Hat's execshield patch. There might be other architectures affected (ppc is known to *not* be affected), but right at the moment I don't have a good way to test those. The architectures affected are ones for which signal handing *without* SA_RESTORER set is broken. This is also the first

On 11/08/2013 10:35 AM, maximilian attems wrote: > On Fri, Nov 08, 2013 at 05:12:13PM +0000, Steve Capper wrote: >> >> I've rebased the work from Neil Williams and Anil Singhar into the >> following three patches. Most of the code changes are due to new >> syscall implementations being needed for arm64 as a only a minimal set >> of syscalls are defined in the

Hi all, I have pushed out an klibc 1.5.16 release. Many thanks to everyone who contributed patches, and very special thanks to Max Attems for organizing the patches posted to this mailing list. This hopefully should include most or all of the outstanding issues. With this release, I'm officially giving up the fiction that two-digit releases are stable and three-digit releases are

fix subject and added warning to patch mail, thanks for review. ----- Forwarded message from "H. Peter Anvin" <hpa at zytor.com> ----- Date: Mon, 29 Mar 2010 15:07:01 -0700 From: "H. Peter Anvin" <hpa at zytor.com> To: maximilian attems <max at stro.at> Cc: Colin Watson <cjwatson at ubuntu.com>, klibc at zytor.com, Herbert Xu <herbert at

I'm thinking it's time to release klibc-1.5; however, before releasing klibc-1.4.31 as klibc-1.5, I wanted to give a call to see if there is anything that either really needs to be done, or any bug reports I've missed... -hpa

On 09/08/2014 05:57 AM, Dejan Latinovic wrote: >> From: H. Peter Anvin [hpa at zytor.com] >> Sent: Friday, September 05, 2014 7:13 PM >> To: Dejan Latinovic; YunQiang Su; klibc at zytor.com; maximilian attems >> Subject: Re: [klibc] [PATCH] add mips64 support > >> Why copy the files rather than share them? > > Hi Peter, > here is new version of

I have just pushed out a git tree which actually has the root-mounting code removed from the kernel. Since there are any number of strange boot configurations out there, I would really appreciate any help in testing this stuff out. I have *NOT* implemented support for the following, which I'm hoping has fallen out of use by now: -> Setting boot flags via rdev, as opposed to on the

Gah, I meant to send this to the list ... -------- Original Message -------- Subject: Re: [klibc] kinit Date: Tue, 26 Oct 2004 21:05:47 +0200 From: Daniel Thaler <daniel@dthaler.de> To: H. Peter Anvin <hpa@zytor.com> References: <417DF200.5070105@zytor.com> H. Peter Anvin wrote: > I think the main bit of the puzzle that's missing for klibc integration > at this

I finally got some time to work through the klibc patch queue... however, since I have been AWOL so long I might have dropped patches. If someone could take a quick look at the git tree before I push a new version out that would be great. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Hello all, I really want to support vfork() in klibc, mostly because uClinux *has* to use it. Unfortunately vfork() isn't allowed to use the stack *at all* across the system call -- including return address -- which means it needs an assembly wrapper on most architectures. I have tried implementing wrappers for most architectures, but I don't know parisc or s390/s390x well enough,

please pull from git://charm.itp.tuwien.ac.at/mattems/klibc/.git branch maks. arch/mips/klibc/archconfig.h | 3 +++ klibc/sysconfig.h | 10 ++++++++++ sys/vfs.h | 17 +++++++++++++++++ 3 files changed, 30 insertions(+)