similar to: Instructions for using klibc

I get this error: ============================================================================= KLIBCCC usr/kinit/resume.o usr/kinit/resume.c:15:66: linux/config.h: No such file or directory make[2]: *** [usr/kinit/resume.o] Error 1 make[1]: *** [all] Error 2 make: *** [klibc] Error 2 ============================================================================= There is no linux/config.h in

After doing a fresh extraction of the source for 2.6.0, I execute ./configure and it enters a loop with no output before or during. I let run 20 minutes just to see if it would ever do anything and it did nothing else. Host system has: Linux: 2.4.23 Slakcware: 9.0 bash: 2.05b.0 gcc: 3.2.2 glibc: 2.3.1 I have a big (huge) strace of it here:

I'm trying to set up a machine which will be running multiple instances of NSD to serve different sets of zones from different interfaces. What I'm running into is that I can't specify different PID files to refer to on the command line. Are there any shortcuts or do I need to go write a patch? Any other implications of multiple instances? --

I was under the impression that --include and --exclude worked by matching patterns in the order given, and whichever matched first, whether that was an include or exclude determined the action for that file. I have a big directory from which I am attempting to transfer selected files. I want all files where the first level directory is anything, the second level directory is "2005"

I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have more than one daemon with separate executable images). After upgrading from 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing over the existing image), I do SIGHUP and get this message logged: Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting. Sep 16 15:07:36 vega

How hard would it be to have rsync do the file recursion scan on both the source tree and the destination tree at the same time in parallel? Would that require a protocol change, or could just a program change be enough? I have some very large directories I'd like to syncronize. Total time to scan through these millions of files is a substantial portion of an hour or even exceeds it. It

It guess I still haven't figured out the entire sematics of the --include and --exclude options. From reading the man page, it seems to say that what happens is that each file being checked is tested against each pattern in order, and when one matches the tests end, and whether it is --include or --exclude determines if that file is included or excluded. So I have on my server a big file

The cause is, of course, that the tree being syncronized ie getting larger, so of course rsync is slowing down. But in the case of my particular file tree, there is a way it could be speeded up, but this would obviously also need a change in the rsync protocol to accomplish it. Any tree that has major unchanged subbranches would benefit from this. The file tree I'm syncronizing in this case

A while back, I asked if there had been any consideration in making rsync support direct ssl (as opposed to just ssh). I've been looking around for a secure way (e.g. encrypted, so passwords are never in the clear, and even content is obscured from sniffers) to allow a set of limited-trust users (limited-trust being defined as mostly customers, whom you trust with their own data, but not with

Under certain circumstances (repeatable with a workaround) the client in openssh-2.1.1p3 and p4 closes file descriptors and then calls select() with the stderr one in the write fd_set. The circumstances which cause this appears to be that the closing of stdin/stdout/stderr occurs before the last of the stderr data is written to stderr. This occurs when a tty is not allocated, but the error

I would like to specify an entry in /etc/rsyncd.conf such that it operates on a --one-file-system basis always. The path will point to a filesystem mount point, but there is another filesystem that is mounted in a subdirectory. I want to back up only those files in the pointed to filesystem, and not the one mounted within (in that run, anyway). I do not see such an option in man rsyncd.conf. Is

Package: klibc Version: 1.5.20-1 Severity: normal Tags: patch User: ubuntu-devel at lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch Hi maks, Since the Ubuntu linux-libc-dev is now installing its asm headers to the multiarch /usr/include/<triplet>/ directory to allow co-installability, I've pushed the attached patch to Ubuntu so klcc knows to include this path when searching

This problem has persisted for as long as I've used rsync. When the --delete option is used, not all files are deleted from the target, even though said files are not present in the source. The particular cases that cause this are when the target has a directory with files, and the source is something else, at least a symlink (this is the case I have seen). I'm taking a guess to say that

Are there any version compatibilities between linux and klibc? I tried to compile the latest klibc (1.5.18) with the latest linux (2.6.32.15) and there is miserable compile failures. It looks like klibc wants some headers to be in include/asm (linked in my case to include/asm-x86) but they are instead in include/asm-generic (it seems all headers but one are in there). I put together this script

Le 22/08/2013 14:36, Thorsten Glaser a ?crit : > leroy christophe dixit: > >> If I set prefix to / and INSTALLROOT to /opt/klibc, klcc is not able to find >> the include files >> If I set prefix to /opt/klibc and SHLIBDIR to /opt/klibc/lib, it is the target >> that tries to load klibc.so from /tmp/klibc-install/lib instead of /lib > INSTALLROOT is some sort of

Le 22/08/2013 07:43, leroy christophe a ?crit : > Le 22/08/2013 00:59, Thorsten Glaser a ?crit : >> leroy christophe dixit: >> >>> Also you can see that it does try to create /lib instead of >>> /tmp/klibc-install/lib hence my second patch. >> That actually seems to be by design. I always set >> SHLIBDIR on the make command line, so it overrides that.

We currently use KLIBCKERNELSRC and KLIBCKERNELOBJ variables which used to be required to point to a kernel source and object directories. However the kernel headers were reorganised starting in Linux 3.7 such that that doesn't work properly. This series removes KLIBCKERNELOBJ and changes the use and documentation of KLIBCKERNELSRC to be consistent. Ben. Ben Hutchings (4): [klibc]

My understanding of the man page description of --exclude vs. --include is that the list of these is kept in order, and file names are searched against these parameters in that order for the first that matches and that one makes the decision. It doesn't seem to be working exactly as expected. But there is a factor involved that's making it unclear, which is whether or not *'s should

On Sun, 2019-01-20 at 14:18 +0000, Thorsten Glaser wrote: > Hi Ben, > > *massive* thanks for picking up klibc work. This might motivate > me to pick up some of the TODOs for it that have piled on in my > TODO (but only after the freeze, I?m sorry to say, I have more > to do for other packages). > > >And I spotted another test program that has this property >

Hi Currently I am trying to get device-mapper and dmraid ported to compile against klibc. So far there was no real issues, as the only thing they used was fscanf and feof not available presently in klibc (but easy to work around). Other than that there are really no way to easily check for installed klibc's other than trying to mangle the output of klcc (from adjusted configure.in): -----