seamonkey upgrade => 2.9.1

Volodymyr Kostyrko c.kworr at gmail.com
Wed Jun 6 12:34:27 UTC 2012


H wrote:

Could you please hit "Reply all" button? I'm not the best one around to 
help you, there are others on the list that can give you better hints.

>> Maybe it fail only when it touches required functionality somewhere in
>> gtk or cairo which in turn was compiled with older libpcre and there
>> demands other calling conventions?
>
> I can not say that for sure, my system was up to date and before
> yesterday I upgraded the portstree and upgraded kde to 4.8 as well as
> all other ports
>
> I do not have enough insight but I believe there was no lib version bump
> between seamonkey 2.9 and 2.9.1, so I wonder why the former versions was
> working fine.
>
> I could force an upgrade on all ports seamonkey depends on, I think I
> will do that but start with all x11 stuff first and see

There are multiple ways to narrow your search.

  1. First one is to use pkg_libchk from sysutils/bsdadminscripts as it 
should list all packages missing any libraries. This is exactly your case.

  2. You generally can do almost the same by issuing "ldd -a 
/usr/local/lib/seamonkey/seamonkey-bin" and identifying port to rebuild 
by "pkg_info -W library_name".

3. You can rebuild only packages that require libpcre and was build 
before it. Here's how:

cd /var/db/pkg/pcre-*
cat +REQUIRED_BY | xargs -n1 -Ifoo find ../foo/+DESC \! -cnewer '+DESC' 
| sed -e 's|^\.\./||' -e 's|/+DESC$||'

>
> backtrace below
>
> thanks
> Hans
>
>>
>> You can take another route.
>>
>>   1. Force seamonkey to freeze.
>>   2. Obtain core dump with gcore (1).
>>   3. Open core dump with "gdb /usr/local/lib/seamonkey/seamonkey-bin
>> seamonkey-bin.core".
>>   4. Take backtrace with "bt full".
>>
>> However it would not provide clearly useful information unless all
>> binaries wouldn't be stripped. To install unstripped binaries you
>> should rebuild seamonkey and everything it depends on WITH_DEBUG and
>> this will take much more time then fixing linkage the way I explained
>> before.
>>
>> Try posting backtrace anyway. Maybe this clears things a bit.
>>
>
> the problem I see with the former method is portupgrade -a, since all
> are up to date I need something more specific, portupgrade -af make not
> so much sense to me
>
> also my small knowledge makes me thinking that there are certainly other
> binaries using the same libs and no one fails and everything is working
> fine but firefox and seamonkey
>
>
> well, seems not so very conclusive but have a look:
>
> (gdb) bt full
> #0  0x2a2b57bf in pthread_kill () from /lib/libthr.so.3
> No symbol table info available.
> #1  0x2a2b4ee2 in pthread_kill () from /lib/libthr.so.3
> No symbol table info available.
> #2  0x2a2b7d69 in pthread_cond_signal () from /lib/libthr.so.3
> No symbol table info available.
> #3  0x29e929cf in PRP_NakedNotify () from /usr/local/lib/libplds4.so.1
> No symbol table info available.
> #4  0x29e937ee in PR_WaitCondVar () from /usr/local/lib/libplds4.so.1
> No symbol table info available.
> #5  0x29e938e7 in PR_Wait () from /usr/local/lib/libplds4.so.1
> No symbol table info available.
> #6  0x292fdb46 in nsStopwatch::Release () from
> /usr/local/lib/seamonkey/libxul.so
> No symbol table info available.
> #7  0x292fdd93 in nsStopwatch::Release () from
> /usr/local/lib/seamonkey/libxul.so
> No symbol table info available.
> #8  0x2957a68a in XRE_AddStaticComponent () from
> /usr/local/lib/seamonkey/libxul.so
> No symbol table info available.
> #9  0x2953c7db in mozilla::hal_impl::GetCurrentNetworkInformation ()
> from /usr/local/lib/seamonkey/libxul.so
> No symbol table info available.
> #10 0x2957a412 in XRE_AddStaticComponent () from
> /usr/local/lib/seamonkey/libxul.so
> No symbol table info available.
> #11 0x29e999da in PR_CreateThread () from /usr/local/lib/libplds4.so.1
> No symbol table info available.
> #12 0x2a2ad4ea in pthread_getprio () from /lib/libthr.so.3
> No symbol table info available.
> #13 0xbd4d9fec in ?? ()
> No symbol table info available.

/usr/local/lib/libplds4.so.1 is part of security/nspr but it doesn't 
link to libpcre. In turn /usr/local/lib/seamonkey/libxul.so depend on a 
lot off glib/gtk stuff that in turn depends on libpcre.

-- 
Sphinx of black quartz judge my vow.


More information about the freebsd-gecko mailing list