You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows, building a shared library from a Julia package using PackageCompiler produces a shared library, but not an associated import library.
As such, shared libraries generated by PackageCompiler cannot be linked to other C/C++ code in a straightforward manner.
When using PackageCompiler to compile a package to a shared library on Windows, the output consists of DLLs corresponding to the package itself as well as the Julia-related dependencies (libjulia.dll, libamd.dll, etc.).
As a MWE, I tried compiling the Julia portion of the libcg proof-of-concept (https://github.com/simonbyrne/libcg) using the following code (run from within libcg/CG):
However, in order for these DLLs to be implicitly linked to another library/executable (i.e. not using LoadLibrary), there should be corresponding import libraries (.lib or .dll.a); these are not generated by the compilation process initiated by PackageCompiler.
I noticed that PR #614 added tests for create_library, but examining the current state of those tests here, it looks like the test consists mainly of running create_library without checking the output.
Not sure if this is related, but I opened an issue on libcg itself related to the failing build of the C library/executable.
Version Info
julia>versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-0615:21 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU:Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz
WORD_SIZE:64
LIBM: libopenlibm
LLVM: libLLVM-12.0.1 (ORCJIT, skylake-avx512)
Environment:
JULIA_EDITOR = code
JULIA_NUM_THREADS =
The text was updated successfully, but these errors were encountered:
As an addendum, there are tools to generate import libraries from DLLs (e.g. lib.exe from MSVC, but there still seem to be problems there, as well. It seemed to me that is a separate issue, and this is the best place to start. However, I can provide more info on that here, if desired, or open a separate issue.
I have the same problem when trying to embed julia in a VS C++ project. Without .lib files I got LNK2019 and LNK1120 errors related to unresolved external symbols. I also tried lib.exe and failed. Does anyone have a solution?
I havethe same / similar issue, the compiled project can not be started each MS Window computers. On the machine where I have compiled the project, I am able to run the compiled MyApp.exe, but on another PC, where no Julia is installed, I see:
ERROR: Unable to load dependent library C:\Users\joshuaeder\Desktop\Test\../bin/libopenlibm.dll
ERROR: Unable to load dependent library C:\Users\joshuaeder\Desktop\Test\../bin/libgcc_s_seh-1.dll
It does not make a difference, if I compile with Julia v1.8.5 or v1.9.0 Unfortunately, both missing DLL are already in the "bin" folder ...
It was my fault, I had just copied the folder bin.
Maybe it can be written more specifically that all three folder must be copied (yes it is written implicitly).
On Windows, building a shared library from a Julia package using
PackageCompiler
produces a shared library, but not an associated import library.As such, shared libraries generated by
PackageCompiler
cannot be linked to other C/C++ code in a straightforward manner.When using
PackageCompiler
to compile a package to a shared library on Windows, the output consists of DLLs corresponding to the package itself as well as the Julia-related dependencies (libjulia.dll
,libamd.dll
, etc.).As a MWE, I tried compiling the Julia portion of the
libcg
proof-of-concept (https://github.com/simonbyrne/libcg) using the following code (run from withinlibcg/CG
):The output directory looks like this:
However, in order for these DLLs to be implicitly linked to another library/executable (i.e. not using
LoadLibrary
), there should be corresponding import libraries (.lib
or.dll.a
); these are not generated by the compilation process initiated byPackageCompiler
.I noticed that PR #614 added tests for
create_library
, but examining the current state of those tests here, it looks like the test consists mainly of runningcreate_library
without checking the output.Not sure if this is related, but I opened an issue on
libcg
itself related to the failing build of the C library/executable.Version Info
The text was updated successfully, but these errors were encountered: