Re: portseal - tools to locate port management bugs
On Sun, Mar 30, 2014 at 07:40:50PM +0200, Justus Winter wrote: here is another prototype of mine, also employing a source-transformation, that can detect port leaks: Well, that's impressive, once more. Excellent job. -- Richard Braun
problem on shut-down
Hi, my box hangs when shutting down. When it comes to stopping the internet superdaemon inetd it just hangs. Riccardo
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 31 Mar 2014 22:35:08 +, a écrit : I came across on some issues in the building procedure which are not solved in the debian patches so I think I should report them, ask for comments on them and be as solid as possible in my descriptions. First there are 2 definitions of sigset_t One in (path_to_glibc)/libpthread/signal/signal.h typedef uint64_t sigset_t; and one in (path_to_glibc)/misc/sys/select.h typedef __sigset_t sigset_t; The build procedure fails if I don't comment one of them out. This is actually fixed by the Debian patch libpthread_clean.diff That being said, are the files in signal/ really useful at all anymore? Secondly the building procedure was looking for the header files located in (path_to_glibc)/libpthread/sysdeps/generic/bits in the (path_to_glibc)/bits so I had to copy them there manually. Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should have made the build system take the libpthread/sysdeps path into account (at least in the Debian package it does). And finally I get the error collect2: error: ld returned 1 exit status in this part here make[4]: Entering directory '/../source/hurd' /../build/libc_pic.a(sigsetops.os): In function `__spin_unlock': /../source/signal/../sysdeps/mach/i386/machine-lock.h:44: multiple definition of `__spin_unlock' /../build/libc_pic.a(spin-lock.os):/tmp/ nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/ i386/machine-lock.h:44: first defined here I also wonder how that can be. _EXTERN_INLINE is precisely meant to avoid this issue: either the definition is inlined in the caller, or an external definition is emitted. Maybe you should check what _EXTERN_INLINE gets defined to, it should be extern inline in the end. Samuel
Re: problem on shut-down
Quoting Riccardo Mottola (2014-04-01 09:24:21)
my box hangs when shutting down. When it comes to stopping the internet
superdaemon inetd it just hangs.
:/
As a workaround, using {reboot,halt}-hurd is safe (filesystem-wise)
even when using sysvinit. Using those commands avoids such problems.
Then again, you should try to debug this. See what the init script
does. Inject a set -x to see where it hangs, etc.
Justus
Re: Trying to solve file lock problem with /etc/sudoers
Hello, Peter Baumgarten, le Thu 13 Mar 2014 18:46:30 -0500, a écrit : I figured out why sudo was not building, unless I explicitly state a umask in my .profile that is NOT umask 000, which it seemed like it was. sudo will fail some permission checks. If put either umask 002 or 022 in .profile sudo will build. So is there another bug with default file permissions then? Having umask as 000 is very odd indeed. How do you log into your system? Samuel
Re: Glibc building procedure error report.
As I said in the irc I managed to bypass the previous error by deleting #define _EXTERN_INLINE in signal/sigsetops.c I am now getting the error /../build/libc_pic.os: In function `__fork': /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to `__start__hurd_atfork_prepare_hook' /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: /../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ../Makerules:614: recipe for target '/../build/libc.so' failed make[2]: *** [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so] Error 1 make[2]: Leaving directory '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf' Makefile:233: recipe for target 'elf/subdir_lib' failed I searched the source files in posix and sysdeps/mach/hurd/ and I can't seem to find any reference to `__start__hurd_atfork_prepare_hook'. Any ideas? Manolis
Re: Glibc building procedure error report.
Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit : /../build/libc_pic.os: In function `__fork': /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to `__start__hurd_atfork_prepare_hook' /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: /../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ../Makerules:614: recipe for target '/../build/libc.so' failed make[2]: *** [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so] Error 1 make[2]: Leaving directory '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf' Makefile:233: recipe for target 'elf/subdir_lib' failed I searched the source files in posix and sysdeps/mach/hurd/ and I can't seem to find any reference to `__start__hurd_atfork_prepare_hook'. Any ideas? In such cases, look for subparts of the name, here atfork_prepare, and you'll see sysdeps/mach/hurd/fork.c:DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); The symbol is supposed to be defined automagically by the linker. I don't know how exactly. A workaround is to add lines in Makerules just like there are for *__libc_thread_subfreeres, but it'd be very good to investigate what is not working in your environment. Samuel
