Embedding Julia in C++: DLL procedure entry point errors

General Usage
1

Good afternoon,

I’ve been trying to follow the basic guide for embedding Julia in C++, and I’m running into a problem when my C++ uses certain standard functions.

image

Here’s a simple bit of test code that causes the problem to occur:


#include <iostream>
#include <uv.h>
#include <windows.h>
#include <julia.h>
#include <cmath>

int main()
{
    std::cout << "Hello World!\n";

    /* required: setup the Julia context */
    jl_init();

    /* run Julia commands */
    jl_eval_string("print(sqrt(2.0))");

    double a = std::acos(2.0);
    std::cout << a;

    /* strongly recommended: notify Julia that the
         program is about to terminate. this allows
         Julia time to cleanup pending write requests
         and run all finalizers
    */
    jl_atexit_hook(0);
    return 0;
}

Edit: Note the std::acos call added in the middle. Without this line, the executable runs and works as expected. The problem arises when I use functions from cmath or other things that appear to have the same function definition as those in the julia dlls. (The linker can’t differentiate?)

Would greatly appreciate any help in resolving this issue. Many thanks!
Josh

1 Like
2

Still stuck on this. I’ve done some investigating with Dependancy Walker and it seems clear that the executable is expecting the acos function in the julia dlls instead of using the cmath functions.

image
image1380×966 73 KB

I’m guessing that the linker doesn’t have a good understanding of the namespacing? Anyone know how to tell the VS2019 linker to prioritize the standard libraries over the additional julia dependancies?

Thanks,
Josh

3

I think just order of libraries on the link line will do this, You might need to explicitly add the standard vc link libraries before the Julia ones to your CMakeLists.txt | vcxproj perhaps?

4

I think that I have a solution. The openlibm.dll.a seems like it has the math functions according to ‘dumps’ - but is lacking entry points. A coworker built a .lib based on the dumps output from the dll.a - and that is working like I expected all along.

I’m not sure why the dll.a didn’t have entry points - and wouldn’t expect to need to do this. Seems like there’s a chance that this use case has just not really been done much. It’s perhaps unusual to have any need to use math functions in the c++ as well as the Julia?

If someone has a cleaner way to do this without build our own .lib - I’d welcome the suggestion.

Thanks,
Josh

5

It might not fit your needs but the approach in GitHub - GunnarFarneback/DynamicallyLoadedEmbedding.jl: Embed Julia with dynamical loading of libjulia at runtime. is at least very different and less intrusive in the build step.