Date: Wed, 06 Jun 2012 10:20:32 -0300 From: H <hm@hm.net.br> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: gecko@FreeBSD.org Subject: Re: seamonkey upgrade => 2.9.1 Message-ID: <4FCF5920.1090907@hm.net.br> In-Reply-To: <4FCF4E30.8040305@gmail.com> References: <4FCE7044.5060308@hm.net.br> <4FCF082B.2050904@gmail.com> <4FCF198C.1040703@hm.net.br> <4FCF1C7C.2020708@gmail.com> <51da39fbe03c8f0c30b0fe9846eb0169.squirrel@wm.matik.com.br> <4FCF2394.2020303@gmail.com> <353659e8a9859572fac4ea556a76ecb5.squirrel@wm.matik.com.br> <4FCF2982.5070107@gmail.com> <4FCF3A5F.80505@hm.net.br> <4FCF43A3.3030603@gmail.com> <4FCF4876.8090705@hm.net.br> <4FCF4E30.8040305@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF47ABF7B1E2A3458E677F261 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/06/2012 09:33, Volodymyr Kostyrko wrote: > 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 hint= s. > sorry, it slipped my attention that you where posting top gecko as well later I will follow your instructions below and come back then with the results thanks so far for your friendly help Hans >>> Maybe it fail only when it touches required functionality somewhere i= n >>> 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 bu= mp >> between seamonkey 2.9 and 2.9.1, so I wonder why the former versions w= as >> 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 no= t >> so much sense to me >> >> also my small knowledge makes me thinking that there are certainly oth= er >> binaries using the same libs and no one fails and everything is workin= g >> 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. > --=20 H +55 (17) 4141.2222 --------------enigF47ABF7B1E2A3458E677F261 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PWTQACgkQvKVfg5xjCDxBpACgjdHqxdb+cQ0nwGu5WmmFeESt o2AAn1u5ccxvSZa30mDMXBbDW8fLe4LA =9r+q -----END PGP SIGNATURE----- --------------enigF47ABF7B1E2A3458E677F261--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FCF5920.1090907>