Date: Thu, 21 Dec 2000 00:42:21 +0200 (IST) From: Roman Shterenzon <roman@harmonic.co.il> To: Daniel Eischen <eischen@vigrid.com> Cc: obrien@FreeBSD.ORG, Max Khon <fjoe@iclub.nsu.ru>, freebsd-stable@FreeBSD.ORG Subject: Re: mozilla and 4.2-RELEASE Message-ID: <977352141.3a4135cd3f8fa@webmail.harmonic.co.il> In-Reply-To: <977175292.3a3e82fcc5d68@webmail.harmonic.co.il> References: <200012172336.SAA02002@pcnet1.pcnet.com> <977175292.3a3e82fcc5d68@webmail.harmonic.co.il>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I repost this, since I've seen no reply from any of you.
I'll summarize the situation:
Problem: Mozilla-M18 built under 4.2-RELEASE and 4.2-STABLE (as of two weeks
ago) crashes on startup because of libgcc_r / listdc++ incompatibilities.
Solutions: The one obrien posted (probably works, I didn't try it)
; the one Daniel posted - I tried it, and it works well.
Problem with Daniel's solution: 4.2-X libstc++ binaries are broken, but 4.x for
x<2 binaries work well. So, something in 4.2 release cycle made them break.
(I rebuilt my binaries, I didn't have much to recompile).
The questions are:
Are there any plans of merging any of the solutions into RELENG_4 ?
Do you need some additional information that I can give ?
Quoting Roman Shterenzon <roman@harmonic.co.il>:
> Quoting Daniel Eischen <eischen@vigrid.com>:
>
> > > I tried the following, applied the patch (it applied cleanly),
> checked
> > that it
> > > really applied (yes it did).
> > > did: cd /usr/src/gnu/usr.bin/cc ; make all && make install && make
> > clean
> > > cd /usr/ports/www/mozilla
> > > pkg_delete mozilla-M18 ; rm -rf /usr/X11R6/lib/mozilla (it wasn't
> > there)
> > > make install
> > > several hours later it produced the binary which dumped core on
> > startup (again).
> > > for the sake of it, I took a package I made on my 4.1-STABLE some
> time
> > ago,
> > > and did pkg_add -f mozilla-M18.tgz (it had older dependencies, so I
> > needed -f).
> > > And, it DOES work. (All needed libs were installed from ports, e.g.
> > ORBit,
> > > gtk,glib).
> > > Perhaps I needed buildworld after I applied the patch, and make all
> in
> > cc
> > > directory wasn't enough?
> > > If it was enough, then I don't have any idea which change make
> mozilla
> > break.
> > > Whatever broke mozilla didn't break ORBit and friends.. Weird.
> > Probably
> > > something C++ related.
> >
> > I think I found the "mysqld: lots of lost connections" bug. It might
> > be related to this also.
> >
> > What happens, is that linking C++ apps that need libstdc++ causes the
> > wrong version of libgcc to be linked. It seems that libstdc++
> includes
> > libgcc, so that when you link a threaded app that needs libstdc++, all
> > the libgcc symbols are already present. This prevents the linker from
> > linking to libgcc_r{_pic}. A quick fix is to manually link the
> > application
> > with -lgcc_r. Doing this will pick up the correct libgcc_r and
> prevent
> > libgcc from being included. Another fix that requires you to rebuild
> > libstdc++ and rebuild your app is:
> >
> > Index: Makefile
> > ===================================================================
> > RCS file: /opt/b/CVS/src/gnu/lib/libstdc++/Makefile,v
> > retrieving revision 1.25
> > diff -u -r1.25 Makefile
> > --- Makefile 2000/06/04 06:56:22 1.25
> > +++ Makefile 2000/12/16 21:05:38
> > @@ -14,7 +14,7 @@
> > CXXFLAGS+= -I${SRCDIR}/stl -I${SRCDIR} -I${SRCDIR}/../gcc/cp/inc -I.
> > CXXFLAGS+= -nostdinc++ -fno-implicit-templates
> >
> > -LDADD+= -lm
> > +LDADD+= -lm -nostdlib
> > DPADD+= ${LIBM}
> >
> > HDRS= cassert cctype cerrno cfloat ciso646 climits clocale cmath
> > complex \
> >
> >
> > It would be interesting to see if this fixes the Mozilla problem
> > also.
>
> I backed out obrien's patch (I don't know yet if it works with it),
> then, I merged Daniel's patch, buildworld, installworld, and now mozilla
> works (after I recompiled it).
> *BUT* c++ binaries compiled on 4.2 fail, for example, starting xfstt
> gives me:
>
> lancelot:/home/roman% xfstt
> /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol
> "__ti9exception"
>
> However, I verified, 4.1 (perhaps 4.1.1?) c++ binaries, for example -
> mozilla,
> work ok with this patch in place.
>
> I.e. I believe that only c++ binaries built under 4.2 will be broken.
>
> Where do we go from here? Anything else I can try?
>
--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?977352141.3a4135cd3f8fa>