Bug#1054921: [Quantlib-dev] Build error for quantlib-swig on mips64el
Hello Dirk, unfortunately I have no idea what can cause this — do you think it possible that the size of the wrappers crossed some threshold and relocations started to occur that weren't there before? Luigi On Sun, Oct 29, 2023 at 2:32 PM Dirk Eddelbuettel wrote: > > The Debian package fails to build now on mipsel, a log is at [1]. The gist > seems to be a relocation error: > >g++ -shared -Wl,-O1 -Wl,-Bsymbolic-functions -O0 -g0 -mxgot --param > ggc-min-expand=20 -DBOOST_NO_AUTO_PTR > build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o > -L/usr/lib/mips64el-linux-gnuabi64 -L/usr/lib -lQuantLib -o > build/lib.linux-mips64-cpython-311/QuantLib/_ > QuantLib.cpython-311-mips64el-linux-gnuabi64.so -fopenmp >build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in > function `virtual thunk to > QuantLib::HimalayaOption::arguments::~arguments()': > > > quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption9argumentsD1Ev[_ZN8QuantLib14HimalayaOption9argumentsD1Ev]+0x104): > relocation truncated to fit: R_MIPS_GOT_PAGE against > `.text._ZN8QuantLib14HimalayaOption9argumentsD1Ev' > > Luigi, and idea if that is a known swig-on-mips64el issue and if we can > addres it with particular flag? As the Debian bug report at [2] states, > "this > used to work" and I didn't change anything for the 1.32 pair of quantlib > and > quantlib-swig. > > For quantlib-swig, and for a few years now, I set some exotic compiler > flags: > >ifneq "$(findstring $(cpu), mipsel mips mips64el)" "" >compilerflags = -O0 -g0 -mxgot --param ggc-min-expand=20 > -DBOOST_NO_AUTO_PTR >endif > > but that mostly came from trying to keep the build with time or ram limits. > > Any hints would be most welcome. > > Cheers, Dirk > > [1] > https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=mips64el=1.32-1=1698321785=0 > [2] https://bugs.debian.org/1054921, also in CC for this email > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > ___ > QuantLib-dev mailing list > quantlib-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/quantlib-dev >
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
On Oct 27, 2007, at 4:36 PM, Dirk Eddelbuettel wrote: | | the correct fix is to make the code chunks which swig generates, smaller. I'll let upstream know (CC'ed, hi Luigi :). Hi, Dirk. There's someone working on that. I don't have an estimate for when it's done, though. It will be for next release anyway---I don't think we'll backport the thing. Luigi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425923: quantlib: FTBFS with new boost libraries
Dirk, I've just released QuantLib 0.8.1. It took a while to figure out the autoconf/automake magic I needed, but now it should work with Boost 1.34. Let me know if there are any problems. Later, Luigi There is no opinion so absurd that some philosopher will not express it. -- Marcus Tullius Cicero, Ad familiares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425923: quantlib: FTBFS with new boost libraries
On Fri, 2007-05-25 at 15:14 -0500, Dirk Eddelbuettel wrote: On 25 May 2007 at 22:04, Luigi Ballabio wrote: | Not yet. The Boost 1.34 release was exceptionally bad timing for us, | since we were finalizing release 0.8.0 when it was made. Instead of | installing 1.34 and restarting the tests (which I did suspect would | fail---see http://thread.gmane.org/gmane.comp.lib.boost.devel/159278) | I chose not to further delay 0.8.0. In fact, the release notes suggest | to use 1.33.1 on Linux systems. If this makes things difficult for you, | I'll try and make a 0.8.1 release to add Boost 1.34 compatibility; but | at this point 0.8.0 is frozen. I think we simply need to work the configure script. From my casual glance at it, boost doesn't seem to have change file locations so I am confused as to what could have caused this to break. As reported in the cited thread, the API of the Boost unit-test framework changed somewhat. In particular, the shared library we link against used to define a main() function, but no longer does so---which is the probable source of the error (what does config.log say? It should include a log of the failed test with the exact compilation or linker error.) In short, we'll probably have to change the test sources to make it work with the new framework. As soon as I get 0.8.0 out, I'll make the changes and release 0.8.1 to add 1.34 support and fix your build. But please let me release 0.8.0 first. It's finalized now, and I rather not reopen it and restart a release cycle because Boost made a release. [ Oh, and while I have you here: we have a really weird build bug with QL-Swig on a few more obscure arches. I didn't bug you with that as it build on all other version -- but see how 0.4.0 failed on a view. From the errors I see on the failed attempts, it looks to me as if gcc et al are to blame. We'll see. Source URLs are http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419742 and http://buildd.debian.org/build.php?pkg=quantlib-swig ] Weird. But as I don't know anything about mips, I'd check the suggestion of the developer who reported the bug. Do you have the log of the main QuantLib compilation? Is it possible to check that it did include -fPIC at each g++ invocation? Later, Luigi When all else fails, pour a pint of Guinness in the gas tank, advance the spark 20 degrees, cry God Save the Queen!, and pull the starter knob. -- MG Series MGA Workshop Manual -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425923: quantlib: FTBFS with new boost libraries
Hi Dirk, On May 25, 2007, at 6:28 PM, Dirk Eddelbuettel wrote: | checking for Boost development files... yes | checking Boost version... yes | checking for Boost unit-test framework... no | configure: WARNING: Boost unit-test framework not found | configure: WARNING: The test suite will be disabled And I see the same with the 0.8.0 (pre-)release snapshot of May 25. Luigi -- looks like configure needs some help. Are you still developing on Debian? Almost. I switched to Ubuntu a few months ago when I got a new laptop. Do you have our Boost 1.34 installed? Not yet. The Boost 1.34 release was exceptionally bad timing for us, since we were finalizing release 0.8.0 when it was made. Instead of installing 1.34 and restarting the tests (which I did suspect would fail---see http://thread.gmane.org/gmane.comp.lib.boost.devel/159278) I chose not to further delay 0.8.0. In fact, the release notes suggest to use 1.33.1 on Linux systems. If this makes things difficult for you, I'll try and make a 0.8.1 release to add Boost 1.34 compatibility; but at this point 0.8.0 is frozen. Later, Luigi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
