Statically compiled and statically linked

General Usage
1

I love the syntax of julia, but, unless julia became statically compiled & statically linked and enables cross compilation, i will use julia as my one and only language. For the mean time there’s https://golang.org/ and https://crystal-lang.org/. Good luck for https://julialang.org/

1 Like
2

So you are using Julia now? That’s great. And don’t worry, static compilation is not on the immediate horizon, so you can keep using Julia as your one and only language.

7 Likes
3

Yes!! As I’ve said, I love the syntax, but i love most the statically compiled and statically linked programming languages like https://golang.org/. Being able to compile a statically linked executable for any specific platform from one platform is the greatest, for me. If https://julialang.org/ can do that, I would be very happy for using julia.

Cheers!!

1 Like
4

I’m pretty sure the OP was asking for static linking/compilation, not a deliberate avoidance of it. In any case, the absence of (static) compilation is also one of the things holding me back from using Julia more at work, so I’m really hoping you’re wrong :slight_smile:

5 Likes
5

With respect, if static compilation/linking is the key feature for someone, why would they want to use an essentially dynamic language?

Standalone binaries are one thing, but they would still need to include the compiler (or just interpret things which were not compiled). There are great statically compiled languages out there… but of course they lack the convenience of Julia. But that’s not a coincidence.

4 Likes
6

I think the focus on “statically compiled” etc is just because that’s the format that usually offers what we want.

The real demand is much more in line with a dynamic language like Julia.

Most users would be totally happy if they can ship a single julia “binary” to their customer/department/non julia programmer - which they can just execute and which doesn’t take a full 5 minutes to compile everytime you start it up.
Because that is indeed a deal breaker for most people!

Especially if someone doesn’t already have julia installed, installation times with download, precompilation, etc easily range between 10-60 minutes right now.

There is no question that this needs to be addressed, especially if we want to reach a wider audience :wink:

22 Likes
7

I have not been following this topic very closely recently, but I though you had a package that tackles this problem?

8

Yeah, we’re on it :wink: Pretty sure this will be solved over the next year!
Right now there are quite a lot of show stoppers when using PackageCompiler, so lot’s of work still needs to be done.
Sadly, I’m not super well informed about Julia’s compilation or even compilation/linking in general, so my personal progress in PackageCompiler has been a bit slow - especially since I also want to push out a release of a new GPUArrays / CLArrays and Makie soon :stuck_out_tongue:

12 Likes
9

(Hey @sdanish, glad to hear about Makie! Looking forward to that!!)

10

So true…

1 Like
11

No doubt go is a viable option. I use it a ton for projects, but these also tend to be more typical business software projects. But doing data science, machine learning, et al., not so easy due to lack of community. Crystal, Pony, Nim, D… have even smaller communities and they lack that “killer” app to drive adoption. Rust is interesting but it’s hard to tell where the community is really heading, whether adoption is real (versus flash-in-the-pan interest from people that end up bailing on the language), and whether people continue to build production code with Rust due to lack of packages plus long development times (think haskell, people love it but it rarely makes it to production). Swift remains to be seen in terms of “server side” adoption and use. In the case of many of the previous languages, c++ will be the likely fallback.

Also, it’s not clear for areas like data science that a compiled language is a benefit overall. ad-hoc data analysis and exploration come to mind. the start up of a jit, or having to wait for things to re-compile are still faster than writing compile scripts with strict type enforcing (i wrote one-off data scripts in go for years doing lots of data engineering tasks. and while it was very easy and fast in go it likely would have been faster to write the code in ruby or python).

3 Likes
12

Hi,

We are using AOT (static) compiled Julia code in production in our company since couple of months ago. We had no problems in compiling our Julia code either on Linux or Windows and deploying it either bare steel or in a container in form of executable or dll/so library.

In addition, from our AOT Julia code we make calls into 3rd party frameworks (e.g. licensing frameworks available as dll/so).

I will present more details on our journey through the perils of AOT compilation at JuliaConf 2018.

Best Regards,
Jan

26 Likes
13

I’m really happy you managed to create a Static / Dynamic Library from Julia.

What if the function you used required BLAS, does the file automatically integrated the required BLAS functions or you needed to link BLAS library to the project using the Julia generated library?

14

Hi,

Sorry for late reply. I was travelling.

If a function in my Julia code requires BLAS all I need to do is to make sure that BLAS library is available to the AOT compiled binary. This is simply achieved by copying BLAS to the same folder as your AOT binary file. AOT binary will then access into the BLAS library for any BLAS call encountered along the way. I hope this answers your question.

You can then copy the entire folder to another computer and it will work like a charm :).

Regards,
Jan

1 Like
15

Hi,

I think this depends on the OS you’re working on and if we’re talking on Static Library or Dynamic Library.
Assuming C / C++ project, In the case of Static Library I guess all you need is the linker which links the Library generated by Julia to be aware of a BLAS library as well.

In the case of Dynamic Library generated by Julia I think things are highly depend on the OS.
Let’s say we’re On Windows, then I think (Not an expert), you have 3 options:

  1. The BLAS DLL is on the same folder as the EXE file which is calling the Dynamic Library.
  2. The DLL is in System Path.
  3. The DLL is called / loaded by the program with its location known.

I don’t know how it works in Linux (Besides having the same System Path which works on all OS).

Let’s focus on Static Libraries, How can you generate with Julia a Static Library to be incorporated in a C / C++ Project? Is it possible in the current form of Julia?

16

AFAIK generating static libraries currently isn’t possible.
However, you can easily create dynamic libraries with C/C++ API using PackageCompiler

17

Marek is right (my colleague, same company :)). Our architecture is as follows.

C++/C App → driver.dll (C language) → AOT.dll (written in Julia and AOT compiled) → further dependencies e.g. BLAS.dll, license.dll etc. (Julia takes care of this automatically).

Hope this helps,
Jan

2 Likes
18

Could you tell more how you do it?
How do you generate the h file for the DLL, What do you mean by Julia takes care of that automatically?

19

Hi Royi,

We are currently preparing the talk for the Julia conference with some toy examples. Let us upload the presentation with the example to this thread sometimes next week when all is ready.

Thanks,
Jan & team

3 Likes
20

Hi guys,

The presentation, simple documentation and the AOT example is available at: https://github.com/TangentWorks/AOTDemo.jl

Video is available at: JuliaCon 2018 | Our journey through the Perils of AOT compilation | Ján Dolinský - YouTube

Best Regards from JuliaCon 2018!
Jan

4 Likes