Re: libstdc++.r4.so

On 2004-07-28 at 10:39:27 [+0200],=20
Axel D=F6rfler <[email protected]> wrote:
> Oliver Tappe <[email protected]> wrote:
> > I have been wrestling with the OBOS^H^H^H^HHaiku-provided
> > libcppunit.so for
> > several days only to find out that the crashes I observed were in
> > fact
> > caused by the buggy std::string implementation living in libstdc++
> > .r4.so.
> > If anyone is interested, I have a small testprogram that exposes the
> > bug(s)
> > (on my machine).
>=20
> Sure, that would be nice to have! Can you add it to our tests?

Yes, but where to add it? This kind of test doesn't seem to fit in the=20
existing structure under src/tests, as it really is a test for a library=20
which doesn't exist yet (whoa). How about creating src/tests/libs/libstdc=
++=20
and putting the test there (others will have to go in there once we have=20
the lib)?

> > Someone mentioned that the source for the
> > R5-version isn't available, but I wonder if this really is true. I
> > (maybe
> > naively) think that libstdc++.r4.so is just a collection of template
> > instantiations, so the source is actually found in the headers...
>=20
> I'm afraid it's a bit more, looking at the symbols it exports.

Yes, you are right. I've just checked and it's not just templates of cour=
se=20
>:o/

> > During my tests, I have found out that Zeta (maybe Dano, too)
> > provides a
> > different libstc++.r4.so, which contains a fixed std:string
> > implementation.
> > Surprisingly, the Zeta-version seems to contain a different set of
> > template-instantiations, as I needed to relink to get my testprograms
> > started.
>=20
> Hm, do you mean you had to recompile with Zeta headers, or that you
> couldn't run your executable on Zeta?

What I meant to (but didn't) say is that after I copied the zeta-libstdc+=
+=20
over to r5 (replacing the native one), my program wouldn't start anymore,=
=20
missing some symbols. Doing a recompile fixes this (I suppose this has to=
=20
do with weak symbols or the like[?]). On a sidenote: the recompiled progr=
am=20
wouldn't start with the R5-lib, missing some other symbols...

> I thought that we could take the most up-to-date libstdc++ from GCC and
> compare it's headers with the Be version. If they are reasonable
> similar, it might be a good idea to take that GCC version and transform
> it to a compatible one.

Hm, I am not sure just how *similar* these libs will be, as gcc is well=20
over 3.4 by now and we are still using 2.9. If at all possible, I'd like =
to=20
avoid the risk of our (broken) gcc failing to compile the current version=
=20
in (perhaps not so) subtle ways. Judging from the fun Ingo had with our g=
cc=20
and templates, I'd say we better leave that for later...

It just came to my mind that all the code contained in libstdc++.r4.so is=
=20
GPLed, so maybe I should just ask Alan Westbrook for the source. Using th=
at=20
would have two advantages, I think:
	- the code is tested to work with our gcc
	- any changes that Be might have applied to get things working=20
	  are actually in there >;o)

That being said, I still believe that Haiku should probably switch to=20
another STL-lib, be it the current gcc-one or STLport or whatever. But=20
taking into account the size of such a task and the pressure to get the l=
ib=20
working soon, I suggest we should trust the existing code.=20

I am still a Haiku-newbie, of course, so any other opinions on this are=20
greatly appreciated!

> If you need any more help, please shout, too :)
> Do you already have access to our CVS repository? Do you want one?

No, I haven't, but yes, I'd like CVS-access. I promise to be well-behaved=
=20
(for the first couple of days >;o)

cheers,
	Oliver