Re: The build...
Locked
 
|
Thanks for your efforts. Greatly appreciated.
There doesn't seem to be a point in building quantlib-python on m68k. The compiler messages warrant examination, though. /Either/ this is an issue with Swig [ I was recommended to use Swig 1.3.9, was that wasn't available, and I did rebuild the .cpp with an older Swig ] /or/ with plain old g++. Should we investigate this. I'm CC'ing quantlib-dev as I had provided a heads-up on the build issues on several arches; I guess we can scrap m68k. Dirk -- Good judgment comes from experience; experience comes from bad judgment. -- F. Brooks |
|
|
Sorry, one day I will have learned that mutt doesn't forward attachments
unless explicitly told. So here is Wouter's mail again in full. Dirk From: Wouter Verhelst <[hidden email]> To: [hidden email] Subject: The build... Date: Sat, 8 Dec 2001 14:43:53 +0100 (CET) ... failed, unfortunately. It took about three days(?) to reach this point. I don't have a build log; however, I attached a file containing everything that was still on quickstep's screen when I arrived. Since I manually typed this over, I could've made a typo, though (Yes, I checked things, but one never knows). I have no clue as to why g++'s exit state was 1. As you can see, the last compiler message before the mentioning of the exit state was a warning, so it should work. I must note, though, that during the compilation, lots of warnings were issued. I've put a tarball containing the build-directory at klecker.debian.org:~wouter/quantlib-python-build.tgz... if you don't need it anymore, please let me know and/or remove it ;-) On another note: I severely underestimated the time quantlib-python would need to build; and seen the fact that it still didn't finish after a few days, I'm not really favourizing a retry. That, and the fact that I now know why the 300 minutes-timeout for sbuild didn't work (had to touch buildd.conf after modifying .sbuildrc) imply that the next build will be through the "usual" channels... Rg, -- wouter dot verhelst at advalvas dot be "Human knowledge belongs to the world" -- From the movie "Antitrust" onst vector<double,allocator<double> > &, int, const vector<double,allocator<double> > &, bool, const QuantLib::Handle<QuantLib::DayCounter> &, int, const QuantLib::Handle<QuantLib::Index> &, const vector<double,allocator<double> > &, const QuantLib::RelinkableHandle<QuantLib::TermStructure> &, const string & = "", const string & = "") /usr/include/ql/Instruments/simpleswap.hpp:75: Quantlib::Instruments::SimpleSwap::SimpleSwap(const QuantLib::Instruments::SimpleSwap &) QuantLib/quantlib_wrap.cpp: In function `struct PyObject * _wrap_new_SimpleSwap(PyObject *, PyObject *, PyObject *)': QuantLib/quantlib_wrap.cpp:31633: cannot allocate an object of type `QuantLib::Calendar' QuantLib/quantlib_wrap.cpp:31633: since type `QuantLib::Calendar' has abstract virtual functions QuantLib/quantlib_wrap.cpp:31449: warning: `class SimpleSwapHandle * result' might be used uninitialized in this function QuantLib/quantlib_wrap.cpp: In function `double SimpleSwapHandle_fixedLegBPS(SimpleSwapHandle *)': QuantLib/quantlib_wrap.cpp:31662: no matching function for call to `QuantLib::Instruments::SimpleSwap::fixedLegBPS ()' QuantLib/quantlib_wrap.cpp:31668: warning: control reaches end of non-void function `SimpleSwapHandle_fixedLegBPS(SimpleSwapHandle *)' QuantLib/quantlib_wrap.cpp: In function `double SimpleSwapHandle_floatingLegBPS(SimpleSwapHandle *)': QuantLib/quantlib_wrap.cpp:31707: no matching function for call to `QuantLib::Instruments::SimpleSwap::floatingLegBPS ()' QuantLib/quantlib_wrap.cpp:31713: warning: control reaches end of non-void function `SimpleSwapHandle_floatingLegBPS(SimpleSwapHandle *)' error: command 'g++' failed with exit status 1 make: *** [build-stamp] Error 1 -- Good judgment comes from experience; experience comes from bad judgment. -- F. Brooks |
|
|
Hi all,
At 08:21 AM 12/8/01 -0600, Dirk Eddelbuettel wrote: >From: Wouter Verhelst <[hidden email]> >Subject: The build... > >... failed, unfortunately. > >I have no clue as to why g++'s exit state was 1. As you can see, the last >compiler message before the mentioning of the exit state was a warning, so >it should work. I must note, though, that during the compilation, lots of >warnings were issued. Here is the problem: >QuantLib/quantlib_wrap.cpp:31633: cannot allocate an object of type >`QuantLib::Calendar' >QuantLib/quantlib_wrap.cpp:31633: since type `QuantLib::Calendar' has >abstract virtual functions for some reason gcc displays a few more cascading errors/warnings after this error, which makes the exit message a bit confusing. However, the above makes no sense---QuantLib::Calendar used to have virtual functions, but this isn't true in the current release. Maybe you are trying to compile QuantLib-Python with an older version of QuantLib installed in /usr/include/ql? Bye, Luigi |
|
|
"Luigi" == Luigi Ballabio <[hidden email]> writes:
Luigi> Here is the problem: Luigi> >> QuantLib/quantlib_wrap.cpp:31633: cannot allocate an object of type >> `QuantLib::Calendar' QuantLib/quantlib_wrap.cpp:31633: since type >> `QuantLib::Calendar' has abstract virtual functions Luigi> for some reason gcc displays a few more cascading errors/warnings Luigi> after this error, which makes the exit message a bit confusing. Luigi> However, the above makes no sense---QuantLib::Calendar used to have Luigi> virtual functions, but this isn't true in the current release. Luigi> Maybe you are trying to compile QuantLib-Python with an older Luigi> version of QuantLib installed in /usr/include/ql? I cannot exclude it, but I don't think this is likely. A build requires a set of packages that are "essential for this build" to be installed. For quantlib-python, this includes libquantlib0-dev. The build environment is then constituted based on the most current packages (from the "unstable" branch) and we do indeed have 0.2.1 in there as the last line here shows: edd@auric:~> madison libquantlib0-dev libquantlib0-dev | 0.1.9-2 | unstable | mips, mipsel libquantlib0-dev | 0.2.0-1 | testing | alpha, arm, hppa, i386, ia64, m68k, powerpc, s390, sparc libquantlib0-dev | 0.2.0-1 | unstable | hurd-i386 libquantlib0-dev | 0.2.1-1 | unstable | alpha, arm, hppa, i386, ia64, m68k, powerpc, s390, sparc Dirk -- Good judgment comes from experience; experience comes from bad judgment. -- F. Brooks |
|
|
At 07:33 AM 12/10/01 -0600, Dirk Eddelbuettel wrote:
> "Luigi" == Luigi Ballabio <[hidden email]> writes: > Luigi> Maybe you are trying to compile QuantLib-Python with an older > Luigi> version of QuantLib installed in /usr/include/ql? > >I cannot exclude it, but I don't think this is likely. A build requires a set >of packages that are "essential for this build" to be installed. For >quantlib-python, this includes libquantlib0-dev. The build environment is >then constituted based on the most current packages (from the "unstable" >branch) and we do indeed have 0.2.1 in there as the last line here shows: Maybe in some other conflicting place, then? Wouter, could you make a search for calendar.hpp on your disk? Bye, Luigi P.S. Dirk: I'm not forgetting the SSH thing :) |
|
|
At 11:00 PM 12/10/01 +0100, Wouter Verhelst wrote:
>On Mon, 10 Dec 2001, Luigi Ballabio wrote: > > Maybe in some other conflicting place, then? Wouter, could you make a > > search for calendar.hpp on your disk? > >A search for that filename in the chroot ('find chroot-unstable/ -name >"calendar.hpp"') reveals nothing. Are you sure it's correct? Yes, I am. It might be /usr/include/ql/calendar.hpp if you installed QuantLib. I assumed that you had 0.2.1 installed and was in doubt that you could have some other version lying around. But since you tell me that you have 0.2.0, that explains the compilation error. Thanks, Luigi |
|
|
In reply to this post by Dirk Eddelbuettel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 On Mon, 10 Dec 2001, Dirk Eddelbuettel wrote: > I cannot exclude it, but I don't think this is likely. A build requires a set > of packages that are "essential for this build" to be installed. For > quantlib-python, this includes libquantlib0-dev. The build environment is > then constituted based on the most current packages (from the "unstable" > branch) and we do indeed have 0.2.1 in there as the last line here shows: I just checked the chroot, and the installed version of libquantlib0-dev during the build attempt was 0.2.0-1 (haven't done anything with that chroot since last weekend). - -- wouter dot verhelst at advalvas dot be "Human knowledge belongs to the world" -- From the movie "Antitrust" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD4DBQE8FS43WgZ1HEtaPf0RAhiZAJYthh2fDx/UWPwbIceQOvXkSWYtAJ9APhSu 3Wg8SIWt/lArdgdwE6gR1Q== =Rn2L -----END PGP SIGNATURE----- |
|
|
In reply to this post by Luigi Ballabio-4
On Mon, 10 Dec 2001, Luigi Ballabio wrote:
> Maybe in some other conflicting place, then? Wouter, could you make a > search for calendar.hpp on your disk? A search for that filename in the chroot ('find chroot-unstable/ -name "calendar.hpp"') reveals nothing. Are you sure it's correct? -- wouter dot verhelst at advalvas dot be "Human knowledge belongs to the world" -- From the movie "Antitrust" |
|
|
On Mon, Dec 10, 2001 at 11:00:07PM +0100, Wouter Verhelst wrote:
> On Mon, 10 Dec 2001, Luigi Ballabio wrote: > > Maybe in some other conflicting place, then? Wouter, could you make a > > search for calendar.hpp on your disk? > > A search for that filename in the chroot ('find chroot-unstable/ -name > "calendar.hpp"') reveals nothing. Are you sure it's correct? Well, we found the problem: when building 0.2.1 (note .1), the 0.2.0 header package (note .0) is loaded. As Luigi said, there were quite some changes in teh C++ classes. Turns out that Build-Depends need to versioned the old-fashioned way, so I just added (>= 0.2.1) for quantlib-ruby and quantlib-python. Dirk -- Good judgment comes from experience; experience comes from bad judgment. -- F. Brooks |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |