signal is determined by the build environment, but the next part seems
to contradict that. Is this just a wording problem (the first sentence
missing a not?) or something more subtle?
Build environment of used eglibc (MIN_KERNEL_SUPPORTED),
but not build environment of your binary.
Plain FreeB
On Sun, 15 May 2011, Petr Salinger wrote:
signal is determined by the build environment, but the next part seems
to contradict that. Is this just a wording problem (the first sentence
missing a not?) or something more subtle?
Build environment of used eglibc (MIN_KERNEL_SUPPORTED),
but not bui
signal is determined by the build environment, but the next part seems
to contradict that. Is this just a wording problem (the first sentence
missing a not?) or something more subtle?
Build environment of used eglibc (MIN_KERNEL_SUPPORTED),
but not build environment of your binary.
Plain FreeB
Petr Salinger writes:
>>> There is no way, signal is determined by eglibc compiled for.
>>> Lets assume that your binary is compiled under squeeze.
>>> Under squeeze eglibc, it will receive SIGBUS,
>>> under sid eglibc it will receive SIGSEGV.
>>
>> I don't understand this part. Your first sentenc
On Wed, 11 May 2011 07:10:41 +0200 (CEST), Petr Salinger
wrote:
>
> Build environment of used eglibc (MIN_KERNEL_SUPPORTED),
> but not build environment of your binary.
>
Got it, thanks. I guess there is some good reason why this doesn't
change the soname of libc, since it seems to break the
There is no way, signal is determined by eglibc compiled for.
Lets assume that your binary is compiled under squeeze.
Under squeeze eglibc, it will receive SIGBUS,
under sid eglibc it will receive SIGSEGV.
I don't understand this part. Your first sentence seems to say the
signal is determined by
On Tue, 10 May 2011 22:13:45 +0200 (CEST), Petr Salinger
wrote:
> What about catching both signals ?
I proposed this to upstream. I'm not sure what they will think about
that idea.
> There is no way, signal is determined by eglibc compiled for.
> Lets assume that your binary is compiled under
While working on getting the racket garbage collector working on
kFreeBSD, I (well, really upstream) noticed mprotect was sending
SIGBUS. Recently this changed so that it is sending SIGSEGV. I'm not
sure what exactly changed, except that catching SIGBUS works on squeeze
and catching SIGSEGV works
While working on getting the racket garbage collector working on
kFreeBSD, I (well, really upstream) noticed mprotect was sending
SIGBUS. Recently this changed so that it is sending SIGSEGV. I'm not
sure what exactly changed, except that catching SIGBUS works on squeeze
and catching SIGSEGV works
9 matches
Mail list logo