I have successfully installed QuabtLib for my windows box, and wanted to port it to Linux Ubuntu. The Boost install was successful, and I was able to run ./configure from the swig directory. However when I run the make file, the system freezes at the following point:
QuantLib/quantlib_wrap.cpp: In function ‘void* _p_TestSurfacePtrTo_p_boost__shared_ptrT_Surface_t(void*, int*)’:
QuantLib/quantlib_wrap.cpp:253496:41: warning: ‘Surface’ is deprecated (declared at /usr/include/ql/math/surface.hpp:47) [-Wdeprecated-declarations]
return (void *)((boost::shared_ptr< Surface > *) ((TestSurfacePtr *) x));
Would be great if someone knew the fix.
Environment info: Boost 1.56
QuantLib 1.4
QuantLibSwig 1.4
Python2.7.6
Ubuntu 14
Thanks,
Here's my comment above, posted as an answer for future reference.
The warning is expected. The Surface class was marked as deprecated in QuantLib 1.4, we're wrapping it anyway, and the compiler is warning us about that.
The freeze is probably caused (was definitely caused, in the case of the original poster) by the exhaustion of the available memory. The wrappers are huge, weighing at about 10 MBytes, and compiling them requires quite a few resources. If you're using a virtual machine, try adding more memory. If you're using a physical machine and you can't, try disabling optimizations to make the compilation process less demanding. You can do this by passing CXXFLAGS=-O0 to either ./configure or make.
Related
I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.
I know how to code but I really do not know my way around a computer.
I have a program that I have to run for my master thesis. It is a code with multiple collabs and runs perfectly on Linux. However, it is a very complex simulational code and therefore it takes time to run for multiple parameters. I've been using my Linux at the university to run it but would like to run some of it on my personal computer (MAC OS). It works by using the R language to call upon c++ functions as follows (being filename a code on c++).
On a Rstudio script:
Sys.setenv("PKG_CPPFLAGS" = "-fopenmp -DPARALLEL")
system("rm filename.so")
system("rm filename.o")
system ("R CMD SHLIB filename.cpp")
dyn.load("filename.so")
After system ("R CMD SHLIB filename.cpp") I get error:
clang: error: unsupported option '-fopenmp'
make: *** [filename.o] Error 1
I've researched on the subject and found this
Enable OpenMP support in clang in Mac OS X (sierra & Mojave)
I've Installed LLVM, yet I do not know how to use it in this case.
How do I use it in this case?
Thank you in advance.
"Don't do it that way." Read up on R and Rcpp and use the proper tools (especially for packaging and/or compiling) which should pick up OpenMP where possible. In particular,
scan at least the Rcpp Introduction vignette
also look at the Rcpp Attributes vignette
"Just say no" to building the compilation commands by hand unless you know what you are doing with R and have read Writing R Extensions carefully a few times. It can be done, I used to show how in tutorials and workshops (see old slides from 12-15 years ago on my website) but we first moved to package inline which helps here, and later relied on the much better Rcpp Attributes.
Now, macOS has some extra hurdles in which tools work and which ones don't. The rcpp-devel mailing list may be of help, the default step is otherwise to consult the tutorial by James.
Edit: And of course if you "just want the above to work" try the obvious step of removing the part causing the error, i.e. use
Sys.setenv("PKG_CPPFLAGS" = "")
as your macOS box appears to have a compiler but not OpenMP (which, as I understand it, is the default thanks to some "surprising" default choices at Apple -- see the aforementioned tutorial for installation help.)
I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry
I made a program that was based off of the demo program on the affdex git page found here. It is the demo called 'opencv-webcam-demo'. I was running Ubuntu 14.04 at the time and it worked fine. I then upgraded to Ubuntu 16.04 and now the demo (even without my changes) does not run properly. I tried to install the latest versions of opencv and boost and confirmed that they were installed correctly but I still get the same issue.
Here is the output when I run the program in Ubuntu 16.04:
ethan#ethan-HP-Pavilion-dv6-Notebook-PC:~/leepsProgram/build/opencv-webcam-demo$ ./opencv-webcam-demo --help
Hit ESCAPE key to exit app..
Encountered an exception std::exception*** Error in `./opencv-webcam-demo': free(): invalid pointer: 0x0000000001c71ca8 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f0ce2798725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f0ce27a0f4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f0ce27a4abc]
./opencv-webcam-demo(_ZN5boost10filesystem4pathD1Ev+0x18)[0x469c86]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0x9a)[0x7f0ce275b35a]
/home/ethan/libraries/affdex-sdk/lib/libaffdex-native.so(+0x5273a3)[0x7f0ce642a3a3]
There was also a Memory Map so if that helps then let me know and I can paste that in here too.
So far I have tried to figure out what part of the code works and what part does not work and found that if you remove boost from the program it will reach up until the point were Affdex has to specify a path to the data folder, at which point it throws an Affdex Exception saying that the data path must be non-null. However it should not be null because I set it at the start.
affdex::path DATA_FOLDER = "<path to data folder>";
...
frameDetector->setClassifierPath(DATA_FOLDER);
Still, removing boost is not ideal since it is already coded for me. But if I have to remove boost then I must solve this issue as well.
Libraries and their versions / OS version:
Boost 1.59.0
OpenCV 3.1.0
Affdex 3.1-396
Ubuntu 16.04
Are these libraries compatible with Ubuntu 16.04?
Thanks for any help. It is greatly appreciated.
I think the problem is that you are mixing libraries with compiled with incompatible versions of libstdc++ .. What is the compiler version you are using?
The current version of the linux SDK was compiled with GCC 4.8
UPDATED: I have solved this problem by updating SDK version to the newest version (https://download.affectiva.com/linux/gcc-5.4/affdex-cpp-sdk-4.0-75-ubuntu-xenial-xerus-x86_64bit.tar.gz).
The tutorial provided the old version:
wget https://download.affectiva.com/linux/affdex-cpp-sdk-3.2-20-ubuntu-xenial-xerus-64bit.tar.gz
I have similar problem, with similar error log. Please consider to upgrade or find a better way to the C++ samples version. Many people try to use the same C++ code for testing. I wasted a lot of time to figure out why?
Debugging starts
Hit ESCAPE key to exit app..
Initializing Affdex FrameDetector
*** Error in `/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo': munmap_chunk(): invalid pointer: 0x0000000000856e10 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff582c7e5]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x1a8)[0x7ffff5839698]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(_ZN5boost10filesystem4pathD1Ev+0x18)[0x467948]
/home/aiq/Desktop/aiq_workspace/affdex-sdk/lib/libaffdex-native.so(_ZN6affdex12DetectorBase17setClassifierPathERKSs+0xc6)[0x7ffff6f5061a]
/home/aiq/Desktop/aiq_workspace/affdex-sdk/lib/libaffdex-native.so(_ZN6affdex8Detector17setClassifierPathERKSs+0x2f)[0x7ffff6f4abb1]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(main+0xaed)[0x466110]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff57d5830]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(_start+0x29)[0x465209]
Please look into the issue. Comments not taking long answer, so I post as an answer here.
I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.