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

Re: QL-Swig failed again on mips



Hi Thimo,

Thanks for the feedback -- much appreciated.

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

If I wrote 'one call' , I probably meant 'one function'. Sorry.

This is swig-generated code from a __large__ c++ project that takes more than
an hour to build on my reasonably beefy x86 box with 2gb ram.  It may not be
appropriate for mips/mipsel.

| is half a million symbols, with e.g. about ~64000 exception handler frames.

Yup. See above.

| 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).

Could we possibly have a discussion on whether we should exclude the three
related packages

	quantlib
	quantlib-swig
	rquantlib

from building on mips/mipsel and arm?  They are already excluded on m68k (but
then m68k is sort-of a moot point anyway).

Please don't misunderstand my point of view. I like mips. I think I'll get a
'slug' box, and I run a linksys router.  It's just that QuantLib is really
meant for decent-size workstations. 

Thanks for the feedback,  Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison



Reply to: