Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jun 2006 19:05:03 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        John Hay <jhay@meraka.org.za>
Cc:        current@freebsd.org
Subject:   Re: libpthread.so.2 compatibility
Message-ID:  <Pine.GSO.4.64.0606041902230.10482@sea.ntplx.net>
In-Reply-To: <20060604191000.GA67836@zibbi.meraka.csir.co.za>
References:  <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <Pine.GSO.4.64.0606041043350.8207@sea.ntplx.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041156020.8602@sea.ntplx.net> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041423260.9199@sea.ntplx.net> <20060604191000.GA67836@zibbi.meraka.csir.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jun 2006, John Hay wrote:

> On Sun, Jun 04, 2006 at 02:26:51PM -0400, Daniel Eischen wrote:
>> On Sun, 4 Jun 2006, John Hay wrote:
>>
>>> Actually one does not even need a big complex app to see the problem.
>>> Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you
>>> will see it happen:
>>>
>>> #######
>>> angel:~ > uname -a
>>> FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28
>>> 11:06:16 SAST 2006
>>> jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL  i386
>>> angel:~ > ssh zibbi "uname -a"
>>> FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May
>>> 25 06:11:44 SAST 2006
>>> jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI  i386
>>> angel:~ > scp -p zibbi:/sbin/ggatec /tmp/
>>> ggatec                                        100%   16KB   8.1KB/s   00:02
>>> angel:~ > /tmp/ggatec
>>> Segmentation fault (core dumped)
>>> #######
>>
>> It is probably the networking ABI changes in libc.  There was a short period
>> of time when there were ABI changes in libc.so.6 in -current -- before libc
>> was bumped to libc.so.7.  What happens when you try moving a -stable
>> libc.so.6
>> to the -current machine?
>
> Ok, I did that but it still core dump in pthread_setcancelstate()

I don't know then.  If recompiling it fixes the problem, then
something in /usr/include changed.  All the pthread_foo_t types
are pointers to things allocated by the library, and I don't
think any of them changed anyways.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0606041902230.10482>