[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: manipulating FPU rounding modes on alpha

On my machine (the machine where Joachim tested the build) the kernel module
math_emu is loaded. Could it be the case that the test do not fail on my
machine because of that? In older mails from this list I recognize a problem
that code linked against the new libc needs math_emu enabled?

Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Joachim Reichel [mailto:joachim.reichel@gmx.de]
> Sent: Thursday, September 06, 2007 9:42 PM
> To: debian-alpha@lists.debian.org
> Subject: manipulating FPU rounding modes on alpha
> Hi,
> I'm maintaining cgal (non-free), a package for computational geometry
> that requires manipulating the FPU rounding mode for some math
> operations. I need some help concerning an alpha specific problem.
> It turned out that the FPU rounding macros in 3.3-1 didn't work on alpha
> (search for ERROR in [1]). Uwe Schindler kindly allowed me to use his
> alpha machine to debug the problem. I found out that the software
> contained #ifdef's with specific macros for alpha. These macros didn't
> work (I don't know whether they never worked or don't work any longer).
> The generic macros from glibc worked.
> Based on this I uploaded 3.3-2 using the generic macros from glibc. But
> when the package was build on the buildd, the test failed again [2].
> Unfortunately, it went unnoticed.
> Now upstream released 3.3.1 also using the generic glibc macros. And
> again, the test failed [3].
> I just build the package manually, and the test succeeds!
> I have no clue how to debug this problem. The test works if the package
> is build manually, but fails on the buildd (ds10). I have no experience
> with alpha and don't know how to track this down.
> Could someone try to build the package manually and see if it fails?. It
> would be helpful to have a machine where the build fails when the
> package is build manually.
> One difference is that Uwe's machine runs current testing (libc6.1-dev
> 2.6.1-1), while the buildd uses older versions (libc6.1-dev_2.6-2 for
> 3.3-2 and libc6.1-dev_2.6-5 for 3.3.1-1) [4]
> Has someone a chroot environment with libc6.1-dev 2.6 (not 2.6.1)? A
> build failure in such a environment would indicate that the older glibc
> might cause the problem.
> Let me know if you need further information.
> Kind regards,
>   Joachim
> P.S.: Please CC: me on replies.
> [1]
> http://experimental.ftbfs.de/fetch.php?&pkg=cgal&ver=3.3-
> 1&arch=alpha&stamp=1183155884&file=log&as=raw
> [2]
> http://experimental.ftbfs.de/fetch.php?&pkg=cgal&ver=3.3-
> 2&arch=alpha&stamp=1184861686&file=log&as=raw
> [3]
> http://experimental.ftbfs.de/fetch.php?&pkg=cgal&ver=3.3.1-
> 1&arch=alpha&stamp=1189034249&file=log&as=raw
> [4]
> Shouldn't buildds build the packages in a current sid chroot?
> --
> To UNSUBSCRIBE, email to debian-alpha-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org

Reply to: