Date   

Welcome and status

Dirk Eddelbuettel
 

Howdy,

Thanks for accepting the invitation to congregate here. It may make it
easier for lurkers to observe than if we continued with private email --
which is also difficult once multiple conversations happen.

We all need one initial message "approved" before unfiltered posting can
happen. So allow for a little delay on your first post.

I posted the R and C++ file we used as starting points in the files section
of this group, see https://groups.io/g/rquantlib/files/.

I am also open to going to git{hub,lab} or another site but so far the scope
may be limited enough as we "just" try to squash this bug.

So to summarize, I think we all are in agreement that

- the R file works on platforms other than Windows, but leads to segfault on
Windows

- the C++ file replicates this, without involving R, so this may be a
QuantLib issue, likely tied to the (for upstream Quantlib) somewhat
non-standard build

- it could be the std::shared_ptr vs boost::shared_ptr issue but I am not
convinced it is as this works "elsewhere"

- so we have to dig in QuantLib, via gdb (on Windows? does it exists for
MSys?) or via old-fashioned boat loads of printf()

- Josh is trying to see if the Boost unit_test library can be built so that
we can try the library build

- the library, for anyone new here, is at https://github.com/rwinlib/quantlib

- the C++ file can be built (taken from my reply to Shrektan with one
correction, untested, paths need adjustments dependning on how you
installed)

c:/Rtools/mingw_64/bin/g++ -static -std=gnu++11 -I"quantlib-1.14/include" \
-L"quantlib-1.14/lib/x64" -l:libQuantLib.a windows_bug_redone.cpp \
-o windows_bug_redone

and the resulting windows_bug_redone should then go belly-up at the end
when the discountcurve hits the bondcalc constructor.

That's it so far. Pipe in with anything I forgot or needs correcting.

Thanks again for coming here. I think we can squash this damn bug (or nest of
bugs).

Dirk


--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: Welcome and status

shrektan
 

Thanks, Dirk, for putting us all together.

However, the build code for the C++ file doesn't work for me. It takes a long time to run (5 to 10 minutes?) ending up with huge amounts of errors like (I've attached the log file)

```
C:\Users\amc038\AppData\Local\Temp\ccA9zPn3.o:windows_bug_redone.cpp:(.text+0x7c): undefined reference to `QuantLib::Date::Date(int, QuantLib::Month, int)'
```

I have no idea why a intermediate step is necessary but the below code works.

```
c:/Rtools/mingw_64/bin/g++ -std=gnu++11 -I"quantlib-1.14/include" -c windows_bug_redone.cpp -o windows_bug_redone2.o
c:/Rtools/mingw_64/bin/g++ -static -o windows_bug_redone2 windows_bug_redone2.o -L"quantlib-1.14/lib/x64" -l:libQuantLib.a
```

Regards,
Xianying


Re: Welcome and status

Dirk Eddelbuettel
 

My bad on the bad instruction.  On linux one step works, and I also should have added the compile time flags `g++` prefers to not yell too much about Boost options...

D.


I can confirm Rtools34 + 1.12.1 works

shrektan
 

No segfaults found when using the Rtools34 and the static library v1.12.1 (Need to replace the ext::shared_ptr() with boost::shared_ptr(), see the file attached.)

Well, actually with v1.12.1, Rtools35 can compile and run without issues.

I tried to use the std::shared_ptr() and find that there's no way to link against => It confirms that, as stated in the QuantLib v1.4 release, the boost pointer is used by default. And, the v1.14 static library is using the boost::shared_ptr() => my previous guess is wrong.

Tried using the same flags "-m64 -g0 -O2" => as long as v1.14 being linked, segfaults happen.

One not-that-smart way to narrow down the cause is to build the static library against v1.13 and if works, we can continue to build the middle version...It's just the compiling of QuantLib takes hours and seems like not easy to be built successfully...

I may take a try in the weekends.


Re: I can confirm Rtools34 + 1.12.1 works

Dirk Eddelbuettel
 

On 29 November 2018 at 07:52, shrektan@126.com wrote:
| No segfaults found when using the Rtools34 and the static library v1.12.1 (Need to replace the ext::shared_ptr() with boost::shared_ptr(), see the file attached.)
|
| Well, actually with v1.12.1, Rtools35 can compile and run without issues.

So you are saying that both rtools versions (when used with the 1.12.1 QL
library version) work?

| I tried to use the std::shared_ptr() and find that there's no way to link against => It confirms that, as stated in the QuantLib v1.4 release, the boost pointer is used by default. And, the v1.14 static library is using the boost::shared_ptr() => my previous guess is wrong.

I don't understand what you are trying to say.

| Tried using the same flags "-m64 -g0 -O2" => as long as v1.14 being linked, segfaults happen.
|
| One not-that-smart way to narrow down the cause is to build the static library against v1.13 and if works, we can continue to build the middle version...It's just the compiling of QuantLib takes hours and seems like not easy to be built successfully...
|
| I may take a try in the weekends.

This is super helpful work. But I am not sure we need the proof with 1.13.

Maybe we need to focus instead on how to configure QL so that it works with
g++ 4.9.3 ? Shall we talk to upstream? I lurk on their lists and could ask...

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: I can confirm Rtools34 + 1.12.1 works

shrektan
 

So you are saying that both rtools versions (when used with the 1.12.1 QL
library version) work?
Yes. Both Rtools versions work for QL 1.12.1. Just realize that Rtools34 and
Rtools35 both use the gcc4.9.3, so it's expected.

I tried to use the std::shared_ptr() and find that there's no way to link against => It confirms that, as stated in the QuantLib v1.4 release, the boost pointeris used by default. And, the v1.14 static library is using the boost::shared_ptr() => my previous guess is wrong.
One of the big changes in the new QL version is they added an opt-in feature: allowing
the user to use `std::shared_ptr` instead of `boost::shared_ptr`. So my silly guess is
that the static library somehow uses the boost version while the cpp file uses the std version.
Linking each other leads to the segfaults. It can't be linked. My silly guess is wrong.

Maybe we need to focus instead on how to configure QL so that it works with
g++ 4.9.3 ? Shall we talk to upstream? I lurk on their lists and could ask...
+1




Re: I can confirm Rtools34 + 1.12.1 works

Dirk Eddelbuettel
 

On 29 November 2018 at 08:36, shrektan@126.com wrote:
| > Maybe we need to focus instead on how to configure QL so that it works
| > with
| > g++ 4.9.3 ? Shall we talk to upstream? I lurk on their lists and could
| > ask...
|
| +1

Before doing so I had a look at the installation / configuration options at
https://www.quantlib.org/reference/config.html

For Windows it says

Under a Windows system, they must be (un)defined by editing the file
<ql/userconfig.hpp> and commenting or uncommenting the relevant lines.

and that has

#define QL_USE_STD_SHARED_PTR

If defined, std::shared_ptr and related classes and functions will be used
instead of boost::shared_ptr; this requires you to set your compiler's
standard to at least C++11. If disabled (the default) the Boost facilities
are used. Note that std::shared_ptr does not check access and can cause
segmentation faults.

Should we try another value here? It does suggest Boost is used (as before)
so that would not be a change. Would be worth trying the other value?

Also, how about trying the unit testing framework once? Josh, any luck
getting this going?

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: I can confirm Rtools34 + 1.12.1 works

Joshua Ulrich
 

On Fri, Nov 30, 2018 at 6:06 AM Dirk Eddelbuettel
<dirk.eddelbuettel@gmail.com> wrote:

Also, how about trying the unit testing framework once? Josh, any luck
getting this going?
Haven't had a chance to try again until now. Hopefully I can make
some progress today or tomorrow.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org



--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com


Re: I can confirm Rtools34 + 1.12.1 works

Dirk Eddelbuettel
 

On 1 December 2018 at 07:16, Joshua Ulrich wrote:
| On Fri, Nov 30, 2018 at 6:06 AM Dirk Eddelbuettel
| <dirk.eddelbuettel@gmail.com> wrote:
| >
| > Also, how about trying the unit testing framework once? Josh, any luck
| > getting this going?
| >
| Haven't had a chance to try again until now. Hopefully I can make
| some progress today or tomorrow.

I should probably wait for that before bugging upstream.

Could you post your script here in case they want to follow-up? Most recent
use was QL 1.14, Boost 1.68 and Rtools 3.5, correct?

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: I can confirm Rtools34 + 1.12.1 works

shrektan
 

Hi Josh,

I'm trying to rebuild the QuantLib from source on Windows, based on your script https://github.com/rwinlib/quantlib/issues/2 . (P.S. Rtools alone is not enough. Need to install MinGW with some packages. And I need to run "./autogen.sh" in order to generate the ./configure file)
 
I downloaded the source of boost and modified the variable value but it still throws the error that "Boost development files not found". I guess I may need a compiled boost version? Because "QuantLib installation on Linux" says "./configure --with-boost-include=/home/foo/include --with-boost-lib=/home/foo/lib". And I don't understand why there's no "--with-boost-lib" in your script.

In addition, I notice a detail in your script, where the CXXFlags contains "
--enable-shared". In contrast to QuantLib installation on Mac OS X :

Also, if you only intend to build the QuantLib Python module, you might want to pass the --disable-shared option to ./configure to only build a static library and avoid problems with dynamic loading.
It looks like we should use "--disable-shared" as well...


Re: I can confirm Rtools34 + 1.12.1 works

Dirk Eddelbuettel
 

On 1 December 2018 at 07:36, shrektan@126.com wrote:
| Hi Josh,
|
| I'm trying to rebuild the QuantLib from source on Windows, based on your script https://github.com/rwinlib/quantlib/issues/2 . (P.S. Rtools alone is not enough. Need to install MinGW with some packages. And I need to run "./autogen.sh" in order to generate the ./configure file )
|  
| I downloaded the source of boost and modified the variable value but it still throws the error that "Boost development files not found". I guess I may need a compiled boost version? Because "QuantLib installation on Linux" says "./configure --with-boost-include=/home/foo/include --with-boost-lib=/home/foo/lib". And I don't understand why there's no " --with-boost-lib" in your script.
|
| In addition, I notice a detail in your script, where the CXXFlags contains " --enable-shared". In contrast to QuantLib installation on Mac OS X ( https://www.quantlib.org/install/macosx.shtml ) :
|
| >
| > *Also, if you only intend to build the QuantLib Python module* , you might
| > want to pass the --disable-shared option to ./configure to only build a
| > static library and avoid problems with dynamic loading.
|
| It looks like we should use "--disable-shared" as well...

Yep. And we should probably nail down a script and post it here and/or in the
rquantlib repo. PRs welcome!

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: I can confirm Rtools34 + 1.12.1 works

Joshua Ulrich
 

On Sat, Dec 1, 2018 at 11:12 AM Dirk Eddelbuettel
<dirk.eddelbuettel@gmail.com> wrote:


On 1 December 2018 at 07:36, shrektan@126.com wrote:
| Hi Josh,
|
| I'm trying to rebuild the QuantLib from source on Windows, based on your script https://github.com/rwinlib/quantlib/issues/2 . (P.S. Rtools alone is not enough. Need to install MinGW with some packages. And I need to run "./autogen.sh" in order to generate the ./configure file )
|
Both points are correct. I believe the top of the script says that it
was only tested with MinGW and msys1.0. I should have said that it's
only "known to work" with those tools. I initially tried with just
Rtools and the Windows command line, but that didn't work. And I
believe the QuantLib readme says that you need the autogen.sh command
to build from GitHub. I build from the latest release.

| I downloaded the source of boost and modified the variable value but it still throws the error that "Boost development files not found". I guess I may need a compiled boost version? Because "QuantLib installation on Linux" says "./configure --with-boost-include=/home/foo/include --with-boost-lib=/home/foo/lib". And I don't understand why there's no " --with-boost-lib" in your script.
|
You only need the boost headers, unless you want to run the QuantLib
unit tests (they require the boost test framework library). Make sure
--with-boost-include is pointing to the location of the unpacked boost
source files.

| In addition, I notice a detail in your script, where the CXXFlags contains " --enable-shared". In contrast to QuantLib installation on Mac OS X ( https://www.quantlib.org/install/macosx.shtml ) :
|
| >
| > *Also, if you only intend to build the QuantLib Python module* , you might
| > want to pass the --disable-shared option to ./configure to only build a
| > static library and avoid problems with dynamic loading.
|
| It looks like we should use "--disable-shared" as well...

Yep. And we should probably nail down a script and post it here and/or in the
rquantlib repo. PRs welcome!
Both --enable-shared and --enable-static are true by default in my
./configure file. We use the static library for RQuantLib. Disabling
the shared library might get us a small QuantLib build-time speedup,
but it shouldn't affect RQuantLib.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org



--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com


boost unit tests

Joshua Ulrich
 

Hi all,

I was able to successfully build the boost unit test framework using
msys1.0 and Rtools35. From the msys prompt and within the boost
source directory, I ran:

BOOST_SRC=/e/build/src/boost_1_68_0
BOOST_LIB=/e/build/boost
bootstrap.sh gcc
b2 -j6 -a --with-test --prefix=$BOOST_LIB address-model=64
--layout=tagged install
# TODO: build the framework outside the source directory (recommended for boost)

Then configure QuantLib with the following options:

--with-boost-include=$BOOST_SRC --with-boost-lib=$BOOST_LIB/lib

QuantLib test suite is currently running... I used:

/e/build/QuantLib/lib/x64/bin/quantlib-test-suite --log_level=message \
--build_info=yes --result_code=no --report_level=short

I'll follow up once the tests finish. I expect them to take at least
an hour, maybe two.

Best,
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com


Re: boost unit tests

Dirk Eddelbuettel
 

On 1 December 2018 at 14:06, Joshua Ulrich wrote:
| Hi all,
|
| I was able to successfully build the boost unit test framework using
| msys1.0 and Rtools35. From the msys prompt and within the boost
| source directory, I ran:
|
| BOOST_SRC=/e/build/src/boost_1_68_0
| BOOST_LIB=/e/build/boost
| bootstrap.sh gcc
| b2 -j6 -a --with-test --prefix=$BOOST_LIB address-model=64
| --layout=tagged install
| # TODO: build the framework outside the source directory (recommended for boost)
|
| Then configure QuantLib with the following options:
|
| --with-boost-include=$BOOST_SRC --with-boost-lib=$BOOST_LIB/lib
|
| QuantLib test suite is currently running... I used:
|
| /e/build/QuantLib/lib/x64/bin/quantlib-test-suite --log_level=message \
| --build_info=yes --result_code=no --report_level=short
|
| I'll follow up once the tests finish. I expect them to take at least
| an hour, maybe two.

Wicked. Thanks for setting that up.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Re: boost unit tests

Joshua Ulrich
 

On Sat, Dec 1, 2018 at 2:09 PM Dirk Eddelbuettel
<dirk.eddelbuettel@gmail.com> wrote:

On 1 December 2018 at 14:06, Joshua Ulrich wrote:
| Hi all,
|
| I was able to successfully build the boost unit test framework using
| msys1.0 and Rtools35. From the msys prompt and within the boost
| source directory, I ran:
|
| BOOST_SRC=/e/build/src/boost_1_68_0
| BOOST_LIB=/e/build/boost
| bootstrap.sh gcc
| b2 -j6 -a --with-test --prefix=$BOOST_LIB address-model=64
| --layout=tagged install
| # TODO: build the framework outside the source directory (recommended for boost)
|
| Then configure QuantLib with the following options:
|
| --with-boost-include=$BOOST_SRC --with-boost-lib=$BOOST_LIB/lib
|
| QuantLib test suite is currently running... I used:
|
| /e/build/QuantLib/lib/x64/bin/quantlib-test-suite --log_level=message \
| --build_info=yes --result_code=no --report_level=short
|
| I'll follow up once the tests finish. I expect them to take at least
| an hour, maybe two.

Wicked. Thanks for setting that up.
Happy to. I want to find the source of this bug!

My time estimate was way off. Unit tests ran in ~20 minutes and
everything passed.

I'm currently trying to run the "windows_bug_redone.cpp" example, but
I'm having trouble linking. Here are the commands I'm running, and
the linking error.

g++ -g0 -O2 -std=c++11 -m64 -I./src/QuantLib-1.14 -I./src/boost_1_68_0 \
-L./QuantLib/lib/x64/lib -lQuantLib -c windows_bug_redone.cpp -o
windows_bug_redone.o
g++ -static -o windows_bug_redone windows_bug_redone.o
-L./QuantLib/lib/x64/lib -lQuantLib

windows_bug_redone.o:windows_bug_redone.cpp:(.text$_ZNK8QuantLib27CPICapFloorTermPriceSurface7maxDateEv[_ZNK8QuantLib27CPICapFloorTermPriceSurface7maxDateEv]+0x1d):
undefined reference to `QuantLib::Date::advance(QuantLib::Date
const&, int, QuantLib::TimeUnit)'
windows_bug_redone.o:windows_bug_redone.cpp:(.text$_ZNK8QuantLib27CPICapFloorTermPriceSurface7minDateEv[_ZNK8QuantLib27CPICapFloorTermPriceSurface7minDateEv]+0x1c):
undefined reference to `QuantLib::Date::advance(QuantLib::Date
const&, int, QuantLib::TimeUnit)'
windows_bug_redone.o:windows_bug_redone.cpp:(.text$_ZN8QuantLib27CPICapFloorTermPriceSurface13checkMaturityERKNS_4DateE[_ZN8QuantLib27CPICapFloorTermPriceSurface13checkMaturityERKNS_4DateE]+0x3a):
undefined reference to `QuantLib::Date::advance(QuantLib::Date
const&, int, QuantLib::TimeUnit)'
windows_bug_redone.o:windows_bug_redone.cpp:(.text$_ZN8QuantLib27CPICapFloorTermPriceSurface13checkMaturityERKNS_4DateE[_ZN8QuantLib27CPICapFloorTermPriceSurface13checkMaturityERKNS_4DateE]+0x7b):
undefined reference to `QuantLib::Date::advance(QuantLib::Date
const&, int, QuantLib::TimeUnit)'
windows_bug_redone.o:windows_bug_redone.cpp:(.rdata$_ZTVN8QuantLib15AbcdAtmVolCurveE[_ZTVN8QuantLib15AbcdAtmVolCurveE]+0xd0):
undefined reference to `non-virtual thunk to
QuantLib::AbcdAtmVolCurve::update()'
windows_bug_redone.o:windows_bug_redone.cpp:(.rdata$_ZTVN8QuantLib15AbcdAtmVolCurveE[_ZTVN8QuantLib15AbcdAtmVolCurveE]+0xe0):
undefined reference to `non-virtual thunk to
QuantLib::AbcdAtmVolCurve::performCalculations() const'
windows_bug_redone.o:windows_bug_redone.cpp:(.rdata$_ZTVN8QuantLib23FittedBondDiscountCurveE[_ZTVN8QuantLib23FittedBondDiscountCurveE]+0xb8):
undefined reference to `non-virtual thunk to
QuantLib::FittedBondDiscountCurve::performCalculations() const'
collect2.exe: error: ld returned 1 exit status


Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com


Re: boost unit tests

Joshua Ulrich
 

On Sun, Dec 2, 2018 at 6:06 AM Joshua Ulrich <josh.m.ulrich@gmail.com> wrote:

On Sat, Dec 1, 2018 at 2:09 PM Dirk Eddelbuettel
<dirk.eddelbuettel@gmail.com> wrote:

On 1 December 2018 at 14:06, Joshua Ulrich wrote:
| <snip>
| I'll follow up once the tests finish. I expect them to take at least
| an hour, maybe two.

Wicked. Thanks for setting that up.
Happy to. I want to find the source of this bug!

My time estimate was way off. Unit tests ran in ~20 minutes and
everything passed.

I'm currently trying to run the "windows_bug_redone.cpp" example, but
I'm having trouble linking. Here are the commands I'm running, and
the linking error.

g++ -g0 -O2 -std=c++11 -m64 -I./src/QuantLib-1.14 -I./src/boost_1_68_0 \
-L./QuantLib/lib/x64/lib -lQuantLib -c windows_bug_redone.cpp \
-o windows_bug_redone.o
g++ -static -o windows_bug_redone windows_bug_redone.o \
-L./QuantLib/lib/x64/lib -lQuantLib
<snip>
This error was an oversight on my part. I was including QuantLib
headers from ./src/QuantLib-1.14, *not* the installed headers at
./QuantLib/include.

The example builds, links, and runs once I make that change. So the
segfault with RQuantLib is likely a similar issue!

I'm currently waiting for the RQuantLib build to finish, so I can test
it with my newly-build QuantLib library.

--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com


Re: I can confirm Rtools34 + 1.12.1 works

shrektan
 

You only need the boost headers, unless you want to run the QuantLib
| unit tests (they require the boost test framework library). Make sure
| --with-boost-include is pointing to the location of the unpacked boost
| source files.

I finally make the script work by putting the `CXXFLAGS=` after `
$QUANTLIB_SRC/configure` 
(before it was `
CXXFLAGS="-m64 -g0 -O2" $QUANTLIB_SRC/configure --prefix=$QUANTLIB_ROOT`)

I add some comments on https://github.com/rwinlib/quantlib/issues/2 regarding the MinGW and MSYS set-ups.
Maybe they are useful when we want to document the whole steps later...

I have just finished the building of the QuantLib 1.13. I can confirm that the segfaults happen for QL 1.13 on the same line...


Re: I can confirm Rtools34 + 1.12.1 works

shrektan
 

Hi,

I build QL 1.12.1 using the same script but surprisingly find the segfault still happen.
It should not happen because I've tested it using the static library built by Josh...

I'll try to build QL 1.12.1 again, using Rtools34 instead of Rtools35...
If no segfaults happen, it must be something related to the tool chain changes made in Rtools35.

Regards,
Xianying


gwd999 on board

W. D.
 

hello everyone 

gonna fetch infos/files asap 

g, w


Re: boost unit tests

Joshua Ulrich
 

On Sun, Dec 2, 2018 at 6:46 AM Joshua Ulrich <josh.m.ulrich@gmail.com> wrote:

On Sun, Dec 2, 2018 at 6:06 AM Joshua Ulrich <josh.m.ulrich@gmail.com> wrote:

On Sat, Dec 1, 2018 at 2:09 PM Dirk Eddelbuettel
<dirk.eddelbuettel@gmail.com> wrote:

On 1 December 2018 at 14:06, Joshua Ulrich wrote:
| <snip>
| I'll follow up once the tests finish. I expect them to take at least
| an hour, maybe two.

Wicked. Thanks for setting that up.
Happy to. I want to find the source of this bug!

My time estimate was way off. Unit tests ran in ~20 minutes and
everything passed.

I'm currently trying to run the "windows_bug_redone.cpp" example, but
I'm having trouble linking. Here are the commands I'm running, and
the linking error.

g++ -g0 -O2 -std=c++11 -m64 -I./src/QuantLib-1.14 -I./src/boost_1_68_0 \
-L./QuantLib/lib/x64/lib -lQuantLib -c windows_bug_redone.cpp \
-o windows_bug_redone.o
g++ -static -o windows_bug_redone windows_bug_redone.o \
-L./QuantLib/lib/x64/lib -lQuantLib
<snip>
This error was an oversight on my part. I was including QuantLib
headers from ./src/QuantLib-1.14, *not* the installed headers at
./QuantLib/include.

The example builds, links, and runs once I make that change. So the
segfault with RQuantLib is likely a similar issue!

I'm currently waiting for the RQuantLib build to finish, so I can test
it with my newly-build QuantLib library.
RQuantLib built and I was able to successfully run the
ZeroCouponBond.R script without a segfault!

My conclusion is that something was incorrectly specified with my
build script. One thing I know I did not include was the `-std=c++11`
flag on the QuantLib build; that may have been the source of the
crashes.

I've only built everything for 64-bit Windows. I still need to create
the 32-bit builds. I will clean up my build script and re-run fresh,
to make sure I'm not missing any crucial details before I share with
the group.

--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com

1 - 20 of 83