This is the mail archive of the libstdc++@gcc.gnu.org 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]
Other format: [Raw text]

Re: [v3] Provide Solaris 2 libstdc++ baseline files


> >> > * What to do with TLS symbols (std::__once_call and
> >> >   std::__once_callable)?  When using pvs on Solaris, I cannot
> >> > easily exclude them from the the baseline_symbols.txt files, but
> >> > it might be appropriate to include them on other systems that use
> >> > readelf, too, since they effectively form part of the ABI.
> >
> > Yeah. Why are they missing from the current readelf list on linux?
> 
> Easy: in readelf --symbols --wide output, they show up with type TLS
> 
>   1920: 00000000     4 TLS     GLOBAL DEFAULT   16
> _ZSt11__once_call@@GLIBCXX_3.4.11 536: 00000004     4 TLS     GLOBAL
> DEFAULT   16 _ZSt15__once_callable@@GLIBCXX_3.4.11
> 
> while extract_symvers currently only handles FUNC, NOTYPE, and OBJECT.

Ah. I just fixed this. Thanks for pointing it out.

> That's what I'd suggest as well, and it was my plan to regenerate the
> Solaris baselines shortly before 4.6.0 is released.

Sounds good.
 
> > I confess I don't much see the point of doing it for minor releases
> > (ie 4.5.1 to 4.5.0). Can you elaborate on this?
> 
> No, not really.  I'm not even sure if minor (or micro?) releases
> should add new symbols at all.

We try not to do this, as the release and trunk have to be in sync. 
That said, 4.4.0->4.4.1 and 4.4.1->4.4.2 added new symbols, so it is
possible. 
 
> > Also, what do you think about adding a prerequisite section to
> > http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
> >
> > that explains what is expected for GNU and now Solaris systems to be
> > versioned? I think this would be very helpful.
> 
> Right, seems like an excellent idea, though I've had a very hard time
> fightying with DocBook (and getting some printable output). 

Sorry to hear this. I'll work on the doc part and request more
concrete feedback from you.

There was another person trying to build the docs. This is his web page:
http://gcc.gnu.org/wiki/BuildingLibstdCppDocs
vs.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_style.html

Perhaps this is helpful?

I was going to wait for that wiki page to be stable, and then move some
of the wiki content into the manual. Perhaps it's that time....

> At the
> moment, the libstdc++ manual seems to be a well-kept secret: it isn't
> even mentioned in Installing GCC.  I'd prefer to move some sections
> relevant to the installation of libstdc++ (like the configure options
> and maybe such a prerequisites section) to install.texi, though, to
> have all GCC-related installation documentation in one place.

Eh. I would rather have links to libstdc++ from the gcc docs and keep
libstdc++ related stuff in one place.

I'm still waiting on the gcc doc maintainer to tell me how to proceed
with generating and the placement of 4.5.x libstdc++ docs on
gcc.gnu.org. There appears to be some controversey WRT doxygen
generated docs. Dunno the state of that FSF soap opera storyline.

-benjamin


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