I am new to fortran and linux. I wish to learn using external libraries like lapack, odepack and all. On internet searches, I can find the downloadable files, source codes and .sh files but have no idea on how to integrate those things as external libraries and call them in gnuplot. I need some references on usage of these packages, detailed, starting from how to integrate those using makefile like stuffs as external libraries using terminal commands and use them in fortran programs.
Related
I can't seem to find anything on the internet which show you how to build and compile a C++ library such that it can be used in R via the Rcpp package. I am missing some steps where the library is somehow linked to R tools
For instance how do you get the boost library working with R or any other such library?
Normal instructions:
https://andres.jaimes.net/718/how-to-install-the-c-boost-libraries-on-windows/
https://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#or-build-from-the-command-prompt
This is almost surely a duplicate but I am in-between tasks and cannot search now...
"It's still complicated" but Rcpp 1.0.5 now also ship this arXiv paper I wrote on this as this vignette. In short, you need to differentiate between
header-only you can ship or include
small-ish library you include and build
an external library
The third one is hardest as you now have the problem of getting it to CRAN and your users.
What's the best way to compile and include a static library (in this case OpenCV) for use in a R package distributed as a binary package. Should I compile it as static outside of R and then put relevant .a files in "inst" or should I include all the source and header files of OpenCV in "inst" and compile from R?
I understand that CRAN will never accept this but it's more for the purpose of making deployment easier for users so they do not need to compile OpenCV or the package from source themselves.
If I get some good pointers on how to proceed or a package that have done something similar I intend to write up a short blog post for other people who want to do the same thing but with other large external libraries (both on Linux, OSX and Windows).
I apologies before hand if I've failed to appreciate that this question has been asked several times before.
I have a bunch of python code that I would like to "compile" into a shared library with a C interface that can be linked with other C/c++ programs and work without depending on too many other libs (perhaps python and some other dlls but they should all be included into a directory with the final lib).
I don't really want to rewrite the python code into C++ for this. I can of course, but it would be best to have a standalone lib that can be used like a dll/so lib.
I have tried cython and wanted to compile python to C and then just compile C code into a dll but that doesn't seem to work quite yet (I haven't been able to make it work flawlessly yet). And then I also tried bbfreeze - but does bbfreeze support creating an .so file? Wasn't able to find out how to do it. Does anyone know?
Do you know of any other options that are more straightforward? the python code only needs to be compiled once. And best of all would be if it creates a single .so file no matter how big it is that just works without too many dependencies.
You can use Python as a library from inside your C++ application: it's called the Python/C API.
The idea is that you initialize your own interpreter, then you load a script in it. You can expose your C++ objects through global variables or modules inside the Python interpreter for your code to interact with, your you can just run Python functions directly from your C++ code.
Now, I understand that you might want to have your Python scripts embedded inside the shared library: this is not necessarily an easy task, with the traditional GNU toolchain. There are multiple techniques to achieve this, but none is official, and all seem way too complicated as opposed to just having the script in an external file.
If your goal is to hide the scripts from the end-user, you could sign them or encrypt them with a private key and embed the public key inside your library, but keep in mind that the key can easily be retrieved by anyone with enough motivation.
I compiled the POCO libraries in VC++, then I used Builder's implib to make libraries for Builder. I added these library files in my application's debug directory, however, linker still throws errors like
Unresolved external 'poco::session::...'
Could you please tell me what is the proper way to import the POCO library in my C++ Builder application?
One way to do it is to build the POCO libraries in C++ Builder directly. The POCO distribution doesn't come with a .cbproj file, but I found that it wasn't too difficult to figure out which files are required and then create my own Poco_Foundation.cbproj in C++ Builder.
If I recall correctly, there are some portions of Poco (involving template specialization) that C++ Builder won't compile. I was able to work around a lot of the compile errors, but I had to just exclude some of the units because they had too many dependencies on the units that don't compile. Most of the problems I found were in the Poco_Net library; I think the Poco_Foundation library compiled pretty easily.
Good luck.
I have an application that needs to use a certain closed source C++ API. This API is distributed with some bits of Boost, binary library files and all. I like to use Boost in my own code. I can't just use their version of Boost since they did not distribute all the parts of Boost I need. How should I proceed? The target platform is linux, eventually Windows as well.
I won't pass Boost objects across the API boundary.
I can compile things to object files so that my code uses my boost headers, and the API's code uses its Boost headers. This part seems straightforward.
What I don't get: how to link my code to my Boost library files, and API's code to its Boost library files. Do I need to compile my own wrapper around the API -- a wrapper whose headers do not include Boost -- to a dynamic library?? (This is the only way I can think of to do the linking. The symbols in the API's Boost library files should be identical to the symbols in my Boost library files. I have to do the linking in two stages, no? The only way I can link one piece of the program without the rest is by making a dynamic library, no?)
A given executable can only have one piece of code for each symbol. So if their library uses symbol foo from boost v. 1 and you use the same symbol from boost v. 2, then you will get a clash. There's no easy way to get rid of this clash without changing the symbol. It should be possible to use dynamic execution if you were able to compile the boost code into a dynamic library, but this seems like it would be overkill.
Since, in C++, a symbol is mangled with its class/namespaces, you could also change one of these to get the symbol to change.
If you are only using the header-only boost libraries, you can just build your code separately from the code that links against the other libraries.
Which boost libraries are you using?
How does the api link with the boost library they used? They deploy a boost-##.so with it, or it was statically link?
So, please run "objdump -T api.so | grep boost" in your api .so to check if the api exposes the Boost.
Also, it is possible that they have renamed the boost namespace like the user chrisaycock mentioned. Use the c++filt command to have a closer look at the symbols you found with "objdump -T api.so | grep boost".
If it was statically linked and the boost symbols weren't exposed ( or were renamed ) then you can use boost at your code without concerning the API's boost.
If boost is really exposed, I recommend to just try using boost. To your code using boost, probably a clash won't happen. If it happens, you may compile a new boost and change your namespace name. Just run a replace-all script replacing "namespace boost" for something like "namespace boost_1_46".