[RFC PATCH] Optionally use -mlong-double-128 by default on {powerpc{,64},s390{,x},sparc,alpha}-linux

[Jakub Jelinek]

On Fri, Jan 27, 2006 at 12:08:00PM -0500, Daniel Jacobowitz wrote:
> On Fri, Jan 27, 2006 at 11:58:08AM -0500, Jakub Jelinek wrote:
> > For libstdc++.so, the header __asm redirect stuff just won't work,
> > C++ doesn't allow that.  But that's not that big deal, I expect
> > all distros that switch to glibc 2.4 will switch to 128-bit long double
> > and mass rebuild everything.  If someone wants to compile/link a
> > -mlong-double-64 program, he can use some compatibility compiler,
> > or even just a contemporary gcc configured with --without-long-double-128
> > installed in a separate prefix or something.
> 
> Are you _trying_ to have a horde of Debian developers lynch you?  Many
> commercial distributions operate on the "it's OK to rebuild everything"
> principal, but Debian doesn't.

We are talking about an ABI switch, so some rebuilding is really necessary.
What makes it easier is that glibc has not changed SONAME and is thus
backwards compatible and this patch tries to do the same for libstdc++.so.6.
If glibc changed SONAME, then the switch would be a) mandatory b) you'd
need to rebuild everything.
So, Debian needs to decide if they want to use 128-bit long double or not.
If not, that means just configuring --without-long-double-128 compiler,
if yes, then a --with-long-double-128 compiler and then you just need
to ensure that whenever you rebuild some package that uses long double
in its exported ABI in interfaces to other package (e.g. long double
related functions in libraries etc.), then you also rebuild the related
packages together.  All I was saying is that for C++ the
--with-long-double-128 compiled compiler only ensures libstdc++.so.6
backward compatibility with already linked programs and shared libraries,
but if you want to be able to use sometimes -mlong-double-64 for C++ and sometimes
-mlong-double-128 for C++ with the same compiler, you need to add
mlong-double-64 multilibs.

> > But, with shared libraries we need just one library with a given SONAME
> > that is backwards compatible, DT_RPATH hacks would just lead to extreme
> > insanity and wouldn't really work.
> > So, I want to do the symbol versioning part of 1) in libstdc++ too
> > (but don't do any header redirections).
> 
> The ICC folks at last year's GCC summit talked about a more
> C++-friendly way to solve this sort of problem; is that suitable here?
> I don't remember whether it could be incrementally adopted.

I haven't been at last year's GCC summit, do you have any references
to that?

	Jakub