Re: Bug#584610: [mips] gcc-4.4 build failure after upgrade to eGLIBC-2.11
reassign 584610 gcc-4.4
tag 584610 + pending
thanks
On Mon, Jun 07, 2010 at 02:08:20PM +0200, Aurelien Jarno wrote:
> Matthias Klose a écrit :
> > On 06.06.2010 00:51, Aurelien Jarno wrote:
> >> On Sat, Jun 05, 2010 at 03:50:51AM +0200, Matthias Klose wrote:
> >>> Package: eGLIBC
> >>> Version: 2.11.1-2
> >>> Severity: serious
> >>>
> >>> gcc-4.4 and gcc-4.5 fail to build after the upgrade to eGLIBC-2.11:
> >>>
> >>> https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4;ver=4.4.4-4;arch=mips;stamp=1275677666
> >>>
> >> This FTBFS is caused by the following change:
> >>
> >> |2009-11-20 Jakub Jelinek<jakub@redhat.com>
> >> |
> >> | PR libc/10103
> >> |
> >> | * math/math.h: Provide *l long double prototypes redirecting
> >> | to double functions even when __NO_LONG_DOUBLE_MATH and not
> >> | __LDBL_COMPAT.
> >> | * math/complex.h: Likewise.
> >>
> >> These functions were present before in the library, but not exported
> >> in the headers. This has been changed as it is required by ISO C99.
> >>
> >> GCC tries to find these functions in the GLIBC by compiling a program,
> >> so it was failing before, and is successful now. When they are already
> >> present in the GLIBC it does not re-export them.
> >>
> >> Strangely this should also affect ARM, but it seems to build correctly.
> >> I haven't investigated why.
> >>
> >> While these functions are strictly not needed in libstdc++6 anymore, we
> >> have two options:
> >> - revert the GLIBC change, which means we break the C99 compatibility
> >> (as before)
> >> - patch GCC to export these functions anyway.
> >>
> >> What's your opinion?
> >
> > For ARM I did choose the second option, but didn't get any feedback about it.
> > So maybe it's time to ask the mips and arm porters?
> >
> > The patch applied for armel is:
> > http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/libstdc%2B%2B-arm-ldbl-compat.diff?view=log
> >
>
> I think we should go for the same patch on mips, it's probably better to
> be ISO C99 compliant on the glibc side.
>
As we discussed, this bug has to be fixed on the gcc side. I have just
checked-in a patch in the SVN to do that on both gcc-4.4 and gcc-4.5.
I am therefore reassigning this bug on gcc-4.4 and tagging it pending. I
don't think it is worth cloning this bug to gcc-4.5 as the bug is fixed
in the SVN and the package is in experimental.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: