Re: Uncoordinated quantlib transition
On Sun, May 27, 2012 at 09:08:35 -0500, Dirk Eddelbuettel wrote:
>
> On 27 May 2012 at 09:55, peter green wrote:
> | >| At least for s390 the problem is not buildd resources. s390 has a 31bit
> | >| address space, which g++ manages to exhaust compiling this insane source
> | >| file. That can't be fixed by rescheduling.
> |
> | >So what do we do?
> |
> | My suggestion would be to drop the optimisation level to -O1 (and if that
> | fails -O0) on the problem architectures. Dropping the optimisation is not
> | ideal but it's better than losing the package completely IMO.
>
> That is a good idea.
>
> And we already do this for QuantLib itself
>
>
> ## edd 18 May 2002 no optimisation or debugging on baby systems
> ## edd 14 May 2005 don't do it on mipsel or mips either
> ## edd 26 Jun 2007 use cpu test, not arch test -- thanks to Riku via #430709
> ifneq "$(findstring $(cpu), m68k arm armeb mipsel mips)" ""
> compilerflags = -O0 -g0 -D_REENTRANT -fpermissive
> endif
>
>
> so I may as well do it for RQuantLib which has to build the massive SWIG C++
> file again the same QuantLib headers.
>
> I guess that'll lead to a debian/rules modification and new a package
> revision rather than a bin-NMU?
>
Right. Though for the s390 issue building without -g may be better than
disabling optimisations.
Cheers,
Julien
Reply to: