* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support
that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version
set will never change again. Each platform will either change by the
Roland McGrath wrote:
* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support
that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version
set will never change again. Each platform will
I hope I can clarify the situation. Planning and communication surely
could have been much better, and as the person who coordinated the efforts
that were made, I can be blamed for what we did and when we did it. glibc
has lacked the manpower to be as organized as we would like to be, and
given
Roland McGrath wrote:
I told those maintainers that glibc 2.4 would not support a new long double
ABI for each platform unless GCC 4.1 as released could compile that glibc.
The glibc sources make it easy enough to switch a platform down the line
(for the glibc 2.5 ABI, whenever that next
I would like to understand better why and how this GCC 4.1 requirement
for adding 128bit long double support came about. Maybe better
understanding how this mistake came to happen will better understand
why GCC 4.1 will be delayed because of this change?
What I am looking for is the dicussion
I would like to understand better why and how this GCC 4.1 requirement
for adding 128bit long double support came about. Maybe better
understanding how this mistake came to happen will better understand
why GCC 4.1 will be delayed because of this change?
What I am looking for is the
I would like to understand better why and how this GCC 4.1 requirement
for adding 128bit long double support came about.
Although the lack of 128-bit long-double support has been discussed
on and off for sometime on the parisc-linux list, I hadn't realized
this was now a requirement for GCC
