This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: ld 2.9.5 and gcc 2.95.2 libstdc++-v3


> This issue seems generally applicable to everybody on this list, so I
> think it makes sense to just discuss it in public, if that's
> ok with you.
>

	Of course.

> Can you please provide specifics on the platform you are using, and
> versions and configure options for the various items in question.
> (g++, libstdc++, ld, as, binutils, os type and version.)
>

	Pardon the inaccuracy, but we're victims of time pressure.

	g++ 2.95.2 from source
	libstdc++-v3 release 8 (almost certain, maybe 9) from source
	binutils 2.9.5.0.22-6 (I think this covers ld nm and as, no?)
	RH 6.2 running 2.2.12-5.0 kernel from CD (we have seen the problems on RH
6.1)

	Everything was configured and built per the instructions on
surces.redhat.com, with the exception that we had to play with -fhonor-std
to get everything to build correctly.

	We're static linking libstdc++

> If you could provide example code, it would help clarify the issue.
>

	I have isolated the exception problem in a snippit, I will have to see if I
still have the code somewhere. It's not an isolated example, but all of
problems are reproducable using:

	http://opensource.zeroknowledge.com

	This is in the source for the Linux Freedom Client 2.0b1 per the sourceball
on our site.

	The exception problem is reproducable for almost any exception by removing
the --whole-archive -lfrcerrorhandling from our link line (I can provide
more detail if necessarry)

	The IO problem is reproducable in the file
freedom/client/zkbase/general/xp/file_hlp.h

	Again, if anyone goes to the trouble of investigating this, please ask if
you're interested in specific repro steps.

	We can not with 100% certainty remove the possibility of the later problem
being related to code, however we have a lot of evidence to support it being
a problem with the tool chain, most notably three rewrites of the same code
demonstrate the same problems which appear to go away when we remove
inlining.

	So this might be a wild goose chase, but we've dedicated a lot of time to
determining the source of these problems, and have little reason to question
the source. However, I'm really trying to see if anyone has experienced
similar problems, not report a bug.

>
> That being said, there has been some discussion of
> libstdc++-v3 ld issues
> on the binutils list. You might want to check out posts on
> binutils by
> both me, Ulrich Drepper, and Phil Edwards, and perhaps others.
>
> > - Exceptions missing catch blocks which should have caught
> them. Literally,
> > the exception in some builds will be caught be the default
> handler for no
> > apparent reason. Rebuilding the exact same sources can make
> this go away.
>
> ?
>
> No idea.
>

	My rushed and somewhat uninformed analysis have pointed to weak symbols
getting merged wrong. I can't really go into detail here since it's pushing
the limits of my knowledge about the toolchain, and, well, this is a hunch.

	Any clarification or help is appreciated more than you can imagine. This
isn't 100% in the domain of libstdc++, I posted this stuff here since I
figured you all would have experience with the config we're using.

Thanks,
~ol


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]