reassign 419742 libc6
thanks
The fails-to-build-from-source for quantlib-swig -- which has been an
isolated event for mips and mipsel for the last three quantlib-swig releases
(0.3.14, 0.4.0, and the pre-release of 0.8.0) -- is seen to be caused by an
architecture specific limitationin the toolchain. Hence the reassignment of
the bug. See below for details. I'll be glad to re-enable builds of ql-swig
on mips/mipsel (where quantlib itself builds) once this is taken care of. For
now, I will exclude mips and mipsel from the quantlib-swig builds.
Thanks, Dirk
On 30 May 2007 at 16:07, Thiemo Seufer wrote:
| Dirk Eddelbuettel wrote:
| >
| > MIPSers,
| >
| > I have an open FTBFS [1] again quantlib-swig, and I don't understand it.
The
| > package builds fine on a number of architectures, used to build on mips too,
| > has not changed its build instructions but now fails. For the newest from
| > today see [2]. Older logs are at [3] and we see that this started with QL
| > 0.3.14. Is there anything different that mips requires from QL?
| >
| > Upstream, CC'ed here, is also out of ideas.
|
| The thing is mips/mipsel and some other architectures are compiled with -O0.
| The resulting object file has quite a bit more than "a single C++ call", it
| is half a million symbols, with e.g. about ~64000 exception handler frames.
|
| The MIPS toolchain has a limitation on the number of symbols which triggers
| here.
|
| I removed the specialcase for mips/mipsel, and retried with version 0.8.0
| of the package (the old one doesn't build from unstable anymore). This gets
| me back to:
|
| /usr/include/unistd.h:270: error: declaration of 'int eaccess(const char*,
int) throw ()' throws different exceptions
|
| which is a soon-to-be fixed bug in libc. I believe the specialcase for MIPS
| was introduced back when the buildds were too memory limited. Since the
| system I tested on (a bcm91250a with 1GB RAM) is the same hardware as our
| current mips/mipsel buildds I believe it is safe to remove the special
| handling (it might need to stay for arm/m68k, though).
|
|
| Thiemo
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
