Is it possible to use the julia language in c++?
Does the julia language provides some libraries to include?
For now, I am trying to use some funcitons of the julia language in my c++ project.
Is this possbile? What could I do?
thanks in advance.
Embedding Julia
Yes Julia can be embedded in a C or C++ program on all of the platforms which Julia itself is available and in all cases the general approach is the same, but in particular the embedding in Windows is made harder because currently the framework for compilation/embedding (gcc) is not the default familiar one for that platform (MSVC). The reason is that Julia is built on Windows using gcc rather than MSVC.
High level
At a high level the steps for embedding Julia include compiling using the resources supplied by the Julia distribution (see below) and then initializing the program to start the Julia engine.
include julia.h
All of the necessary defines for either a c or c++ program are located in julia.h. The exact location for it differs for each distribution, but in general it's located in julia-basedir/include.
link to libjulia
Likewise all of the necessary symbols to embed Julia are located in libjulia. On OS/X and Linux libjulia.so will be generally available in julia-basedir/julia/lib while on Windows libjulia.dll will be julia-basedir/julia/bin.
or optionally in 0.4: use julia-config.jl
The previous might all sound confusing, but luckily contained in the newest Julia 0.4 distributions is a script called julia-config.jl which will provide all of the needed compiler flags automatically -- disclaimer I wrote it. In this case all that you need to do is cut and paste and follow the pattern in the documentation, create a Makefile, and make will take care of the rest.
initialize using jl_init
As described in the docs, use jl_init to start the Julia runtime, while optionally specifying the directory where the Julia compiled base support sys.ji can be located. I've found it's best to specify this directly rather than let it default; julia-config.jl also provides -DJL_INIT_DIR which can be blindly used as an argument to jl_init; the docs provides details.
The problem with Windows
Returning to Windows. If you follow the instructions to compiling Julia in Windows, you will end up with an MSYS2 compilation environment. Note that these instructions are somewhat out of date, and MSYS2 has advanced since then, so it is now simpler (for example use of 7-zip is not necessary). As an aside, this also allows you to obtain git directly -- note the last comment by #ntzrmtthihu777 is now the best one as git via MSYS2 superior to git-bash which is based on the older MSYS.
gcc
Now MSYS2 does indeed provide a gcc, but you must not use it because it implicitly uses a threading model (POSIX) that is different from the one used by Julia (Winthreads) and instead you must obtain gcc from mingw-builds which gives you an option to pick the model during the install; this is indicated by the Julia compilation Window README too, but it bears repeating. Other tools can be obtained from the MSYS2 package manager pacman.
Mingw builds provides an installer, and I've found that the following fstab will be sufficient to make the mingw-builds gcc available in the right location:
none / cygdrive binary,posix=0,noacl,user 0 0
c:/mingw-w64/x86_64-4.9.2-win32-seh-rt_v3-rev1/mingw64 /mingw64 ntfs binary,noacl,auto 0 0
Looking beyond
If you are successful creating a compilation environment suitable for compiling Julia from source -- you can verify this by actually compiling Julia -- then the instructions above including the julia-config.jl/Makefile simplification will work, and will produce a program that embeds Julia and will be a .exe that will work even when invoked outside of MSYS2, which is nice.
But if you are looking to use MSVC directly, then I should warn you that compilation of Julia with MSVC is still int the early stages, so the above approach with MSVC substituted for gcc will not work currently, but there is the possibility that libjulia could be linked to; it is expected that libraries created by mingw are usable by MSVC at least.
Updated MSVC Compilation (creating julialib.lib)
libjulia.dll is the library that contains all the symbols necessary to embed Julia, and in addition, though it is created by gcc, it can be used by MSVC because all of those symbols have C naming, and are not C++ name-mangled. However, it's not usable directly, but requires a .lib to be created. Which can be done in the following way.
Create julialib.lib
use dumpbin to export symbols from the dll into a file for example:
dumpbin /exports libjulia.dll > output
transform the output to a .def file by removing the extraneous text and placing EXPORTS at the top of the time as described in detail here
Use lib to create a .lib from the .def.
lib /def:libjulia.def /out:libjulia.lib /machine:x64
Place libjulia.lib in the same directory as libjulia.dll
Build project by including julia.h and link to libjulia.lib
waTeim's answer is correct, go vote for it! I just want to complement it with steps to use the library in your Visual Studio project. The following assumes that libjulia.lib is in your Julia's bin subfolder, and you want a 64 bit application. I did it in Visual Studio 2013.
First setup the 64 bit solution / project if not done already. Select / click / check the following:
Build / Configuration Manager
Active solution platform / New
X64 / Copy settings from Win32 / Create new project platforms
Then setup your project's configuration:
Right click project / Properties
Select Configuration = All Configurations, Platform = x64
Debugging / Environment: PATH=$(JULIA_HOME);$(PATH)
C/C++ / General / Additional Include Directories: $(JULIA_HOME)\..\include\julia
Linker / General / Additional Library Directories: $(JULIA_HOME)
Linker / Input / Additional Dependencies: add libjulia.lib to the list
Ensure your active configuration is for platform x64 then build your solution. It worked for me, hopefully it will work for you as well :)
Related
Let's say I have created and compiled a simple program using the MinGW 64 (g++ compiler). Running this program on my computer and looking in Process Explorer for what DLL files the program is using I find (among many others):
libgcc_s_seh-1.dll
libstdc++6.dll
libwinpthread-1.dll
These are the only ones that reside under my MinGW installation folder. The rest of the DLL files used reside under C:\Windows.
Question 1:
Are the MinGW DLL files the MinGW C++ runtime libraries (so to speak)? Do they serve the same purpose as for example msvcrXXX.dll (XXX = version of Microsoft runtime library).
Question 2:
If I want to run the application on a different computer which does not have MinGW installed, is it sufficient to include those DLL files listed above (i.e. placing them in the same folder as my executable) to have it run on the other computer (we assume the other computer is also a 64-bit Windows machine). If yes, does this mean we basically ship the MinGW C++ runtime with our executable. If no, why?
libstdc++6.dll is the C++ standard library, like you said.
libwinpthread-1.dll is for C++11 threading support. MinGW-W64 has two possible thread variants: Either use the native Windows functions like CreateThread, but C++11 stuff like std::thread won´t be available then; or include this library and use the C++11 classes (too).
Note that to switch the thread model, you´ll need to reinstall MinGW. Just removing the DLL and not using the C++11 stuff won´t work, the DLL will be required nonetheless with your current install.
libgcc_s_seh-1.dll is something about C++ exception handling.
Yes, it should be sufficient to deliver the DLLs too
(or use static linking and deliver only your program file).
For complicated projects where you're not exactly sure which DLL files need to be included to distribute your application, I made a handy dandy Bash script (for MSYS2 shells) that can tell you exactly what DLL files you need to include. It relies on the Dependency Walker binary.
#!/usr/bin/sh
depends_bin="depends.exe"
target="./build/main.exe" # Or wherever your binary is
temp_file=$(mktemp)
output="dll_list.txt"
MSYS2_ARG_CONV_EXCL="*" `cygpath -w $depends_bin` /c /oc:`cygpath -w $temp_file` `cygpath -w $target`
cat $temp_file | cut -d , -f 2 | grep mingw32 > $output
rm $temp_file
Note that this script would need to be modified slightly for use in regular MSYS (the MSYS2_ARG_CONV_EXCL and cygpath directives in particular). This script also assumes your MinGW DLL files are located in a path which contains MinGW.
You could potentially even use this script to automatically copy the DLL files in question into your build directory as part of an automatic deploy system.
You may like to add the options -static-libgcc and -static-libstdc++ to link the C and C++ standard libraries statically and thus remove the need to carry around any separate copies of those.
I used ntldd to get a list of dependencies.
https://github.com/LRN/ntldd
I'm using msys2 so i just installed it with pacman. Use that and then copy all the needed dependencies
There are several major challenges to distributing compiled software:
Compiling the code for all target processors (remember, when it comes to compiled code, you need to produce separate downloads/distributions for each type of instruction set architecture).
Ensuring that the builds are reproducible, consistent, and can be easily correlated with a specific version of the code (and versions of the dependencies).
Ensuring that the build output is self-contained and includes all of its dependencies within it (so that it is not dependent on any other installations that happen to exist on just your system).
Making sure that your code is built and distributed regularly, with updates distributed automatically so that -- in the event of security issues -- you can push out new patched versions.
For convenience and to increase reach, it is nice for non-savvy users to have a prebuilt version that they can install. However, I would recommend sharing the source code as a first step.
Most of these requirements are fairly non-trivial to hit and often require automating not only build process, but also automating the instantiation / configuration of VMs in which the build should take place. However, there are open source projects that can help... for example, check out Gitian.
In terms of bullet point #3, the key thing here is to use static linking... while this does make the binary you distribute much larger (because its dependencies are now baked into the output), it also makes your binary isolated from the version of the libraries on the system (avoiding "dependency hell").
Point #4 is very tricky, but thankfully there are also opensource tools to help here, as well such as cloudup, which provides a way to add auto-updating capability to your application distribution.
I code in C/C++ and use a (GNU) Makefile to compile the code. I can do the same with CMake and get a Makefile. However, what is the difference between using a Makefile and CMake to compile the code?
Make (or rather a Makefile) is a buildsystem - it drives the compiler and other build tools to build your code.
CMake is a generator of buildsystems. It can produce Makefiles, it can produce Ninja build files, it can produce KDEvelop or Xcode projects, it can produce Visual Studio solutions. From the same starting point, the same CMakeLists.txt file. So if you have a platform-independent project, CMake is a way to make it buildsystem-independent as well.
If you have Windows developers used to Visual Studio and Unix developers who swear by GNU Make, CMake is (one of) the way(s) to go.
I would always recommend using CMake (or another buildsystem generator, but CMake is my personal preference) if you intend your project to be multi-platform or widely usable. CMake itself also provides some nice features like dependency detection, library interface management, or integration with CTest, CDash and CPack.
Using a buildsystem generator makes your project more future-proof. Even if you're GNU-Make-only now, what if you later decide to expand to other platforms (be it Windows or something embedded), or just want to use an IDE?
The statement about CMake being a "build generator" is a common misconception.
It's not technically wrong; it just describes HOW it works, but not WHAT it does.
In the context of the question, they do the same thing: take a bunch of C/C++ files and turn them into a binary.
So, what is the real difference?
CMake is much more high-level. It's tailored to compile C++, for which you write much less build code, but can be also used for general purpose build. make has some built-in C/C++ rules as well, but they are useless at best.
CMake does a two-step build: it generates a low-level build script in ninja or make or many other generators, and then you run it. All the shell script pieces that are normally piled into Makefile are only executed at the generation stage. Thus, CMake build can be orders of magnitude faster.
The grammar of CMake is much easier to support for external tools than make's.
Once make builds an artifact, it forgets how it was built. What sources it was built from, what compiler flags? CMake tracks it, make leaves it up to you. If one of library sources was removed since the previous version of Makefile, make won't rebuild it.
Modern CMake (starting with version 3.something) works in terms of dependencies between "targets". A target is still a single output file, but it can have transitive ("public"/"interface" in CMake terms) dependencies.
These transitive dependencies can be exposed to or hidden from the dependent packages. CMake will manage directories for you. With make, you're stuck on a file-by-file and manage-directories-by-hand level.
You could code up something in make using intermediate files to cover the last two gaps, but you're on your own. make does contain a Turing complete language (even two, sometimes three counting Guile); the first two are horrible and the Guile is practically never used.
To be honest, this is what CMake and make have in common -- their languages are pretty horrible. Here's what comes to mind:
They have no user-defined types;
CMake has three data types: string, list, and a target with properties. make has one: string;
you normally pass arguments to functions by setting global variables.
This is partially dealt with in modern CMake - you can set a target's properties: set_property(TARGET helloworld APPEND PROPERTY INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}");
referring to an undefined variable is silently ignored by default;
As mentioned in the other answers CMake can generate other project files. It refers to these projects as generators.
This lets users write/describe their build using a domain specific language, and use the generator to compile the project. It often results in simpler/better code than writing to these project files directly.
A big advantage is users can use the tool that they are the most comfortable with (Makefiles, Visual Studio, XCode, Ninja, etc). This is nice but arguable introduces complexity. Why not just use Ninja?
The answer is history. (As is the norm in C/C++)
Build systems like Visual Studio have tools that will only accept those project files.
For example Microsoft has a feature called "Static Driver Verifier". A tool to analyze the code of kernel mode windows drivers. However, this tool only works on Visual Studio projects since it works alongside msbuild.
msbuild /t:sdv /p:Inputs="Parameters" ProjectFile /p:Configuration=configuration /p:Platform=platform
If your build system can't generate Visual Studio project files, then you can't use the tool. This can be a very big deal for some projects/companies.
I want to know a programming language that doesn't require a runtime/dependency to be installed on the target system. My primary target is Windows XP and above.
I tried Autohotkey but it dosent have many advance functions.
Firstly, please confirm that does 'C++' requires to install a runtime/dependency on the target system is is Win XP or later. Secondly, please suggest me an alternative to C++ that doesnt require a dependency to be installed.
UPDATE: I will be using CodeBlocks! Does the C++ code compiled with that requires a dependency?
UPDATE: Sorry for the misconception, by CodeBlocks I mean the default compiler of CodeBlocks (ie: GNU GCC Compiler or MinGW).
Everything usually depends on the project, not the language. For example, programs compiled in Visual Studio's C++ uses some runtime libraries to work properly. However, you can configure the project in such way, that these libraries are included in the executable file, thus not needing additional dependencies. Delphi works similarly.
Here's the setting for Visual Studio Project:
If you choose option with "DLL", your program will require runtime DLLs. Otherwise it will be standalone, the runtimes will be incorporated into your binary file.
Edit: In response to question edit
I'll repeat myself: it depends on project, not the compiler or IDE.
If you want to create a program that does not require anything else in order to run, except for base operating system (no .NET, no Java, no Perl, no runtime libraries, etc), then your best bet is to use C or C++ and compile your program as single statically compiled executable.
It is rather difficult to achieve in practice, but it can be done.
Codeblocks is not a compiler, but an IDE, that can use different compilers.
The most common one is MinGW.
To complie with minGW so that all the standard libraries are statically linked you shold configure your project (see "project settings") so the the linker options include the -static flag.
You can even be more specific by stecifying
-static-libgcc
-static-libstdc++
I have been using a socket library for C++. Some other info: 32 bit Linux, Codelite and GCC toolset. I want to be able to compile my program for Windows using the windows edition of Codelite. The socket library I have been using doesn’t have a mingw32 build of the library, but it’s open source. So how can I make a mingw32 build of the socket library so I can make a windows build using the source provided?
Most open source linux libraries are built with the make build system (although there others like jam etc, and custom written scripts for building). MinGW comes with the make utility, it's mingw32-make.exe. It may be possible (if you're lucky) to simply rebuild your library by making it on Windows.
The more usual scenario is that you will need to configure the project before you can build it though. The windows shell doesn't support the scripting requirements required to configure, but there's another part of the MinGW project that does called MSYS. If you install msys and all the required tools you need for it, you'll be able to ./configure your project before running make.
Of course, the above will only work if the library is written to be portable. There are some breaking difference between the linux socket implementation (sys/socket.h), and the windows implementation (winsock2.h). You may be forced to edit chunks of the code to ensure that it is versioned correctly for the platform (or that any dependencies required are also built for Windows).
Also, there is the chance that the library may already be built for Windows, but using a different compiler like MSVC, which produces .lib and .dll files. Mingw requires .a files for libraries, but a clever feature is the ability to link directly against a .dll, without the need for an imports library, so you can often use an existing windows library that was not built against Mingw (Although this won't help for static linking). There is also a tool, dlltool, which can convert .lib to .a.
If you give detail on the specific library you're working with, I may be able to pick out for you what needs to be done to run it on Win.
You port it to the new platform. :)
You're fortunate that it is opensource, because then it would be practically impossible to port it (You'd have to pay $$$'s to get a copy of the code for a particular license, or rewrite the entire product).
Enjoy.
Alternatively, they may well already have a port... Check the documentation for the library you are using.
First off your going to need to make sure that you aren't including any Linux specific libraries.
How do you port C++ programs with makefile made from GNU C++ in Linux to Visual C++?
One thing I can suggest is to use CMake. If you implement your build system with CMake to auto-generate the makefiles for GCC on Linux, it takes only minor modifications to auto-generate projects and solutions for VC++.
Of course, this means learning a whole new build tool, so it may not be for you. It's only a suggestion.
I don't know about an easy way to simply convert from one to another, but..
Assuming you use only ANSI C/C++ features, usually you don't need to convert the makefile, just look which .c/.cpp files are in it and add them to the VS project; you'll also have to check about compiler options and defined macros, to put them inside the VS project. I've done this to compile libs like expat, freetype, agg and others, without problems.
Porting the build system: You could use a Windows port of GNU make, and change the makefile to invoke the Visual C++ command line tools (cl.exe, link.exe, lib.exe, etc.) when building on Windows and the GNU compiler tools when building on Linux. The difficulty of this approach depends on the complexity of the makefiles.
Porting the code: This depends on what APIs and libraries you are using, and what compiler warnings/errors/quirks you will encounter. For a more specific answer, ask a more specific question.
CMake was mentioned. I have used CMake and successfully compiled the resulting Visual Studio project. I found the CMake documentation very unhelpful -- I had to ask an existing user -- and the official manual (which costs money) was out of print at the time. Further, the Visual Studio project it produced was very rigidly formatted according the template preferred by whoever wrote the converter. I was unable to figure out how to customize project options or group source files.
I regularly cross-compile on Visual Studio and G++. For the most part, you just need to add all of the source files and header files into a Visual Studio project ('Add Existing Files', and add your entire source tree) and then compile it. Usually you'll get errors, so you start fixing bugs from there. If you used platform-specific libraries, you may be stuck porting to an alternative or removing features.
One further word of caution: Visual Studio and G++ have different compiler quirks. For the most part, they both conform excellently to the C++ standard, but slightly off-standard code which works in one may not work in the other. I have found this to be particularly true when dealing with templates, with Visual Studio being bizarrely permissive of syntax errors in many cases.
CMake has the nicety of generating visual studio project.
If you do not need that, I suggest Meson build system. Much nicer, similar proposal. Requires python3 and ninja, but noone is perfect. :)