-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libgdal not defined on linux machine Julia 1.1.0 #61
Comments
Which package were you installing that has GDAL.jl as a dependency? I'd like to try to reproduce. Normally speaking if you add another package, it will also add and automatically build GDAL.jl. The libgdal not defined error comes if build GDAL is not run. The platform_key deprecation warning should be harmless, and will be fixed once we get a newer build from GDALBuilder working. Other than this you didn't get any errors on build GDAL? |
Sorry, I was afk all weekend. Uhh, it's a package our team built, and it's proprietary, so I can't really share it. I did not experience this issue in mac OS julia 1.0 or 1.1, but when I built on a linux node I experienced this issue. |
Ok, no need to share the package, all I am looking for is a way to reproduce your situation. Do you have some steps that we can reproduce to determine if this is an issue with GDAL.jl? Right now it looks to me that the required packages were just not installed correctly. Perhaps you did If you just have a julia script with
This will download GDAL.jl and build it as well. If it is used indirectly by another package, this should be done automatically by the package manager as long as GDAL.jl is correctly listed as a dependency. |
Right, I'll explain what I did, I'm working on a remote Linux node on an HPC. So I downloaded the julia 1.1 tarball (I've downloaded with and without dependencies and get the same results) locally and scp'd it into the node. I then make julia 1.1 and then install. Then, I set the julia project to the package directory that we made. Then, in the package manager REPL, I |
And does it work if you In the screenshot I see that on
Also what is the output of |
Ok, got it. Doesn't build.
|
Your x86_64 linux should work fine and is also tested, so that shouldn't be the problem. Could you try removing your entire
And then post the entire contents of the linked build.log? For me after doing this it looks like this:
And afterwards |
Yeah, I removed GDAL and then added it. Still having a problem.
|
Aha now at least we have the error:
So it downloaded the GEOS tarball from GEOSBuilder, but then it couldn't find/satisfy the libgeos_c shared library inside? That is odd, because the tarball is there and it has that shared library inside. Do you always get this as the error? Could you check if you see that shared library, and if it is there, if you can |
Ok, so inside So, I couldn't imagine that another package could be the problem, I went ahead and removed all other packages manually from package list, including GDAL. And ran |
Could you try going in the using Libdl
dlopen("libgeos_c") |
Sure:
|
Huh odd, I'd expect that file to be there. I see in the lib dir all of these files, do you have the same ones?
Of those these are symlinks:
But perhaps on your cluster symlinks are not allowed? Which BinaryProvider version is used here? In the latest release I see this was added: JuliaPackaging/BinaryProvider.jl#112 Perhaps you can try setting the environment variable as suggested to I'd really like to make a new build available, but didn't manage so far: JuliaGeo/GDALBuilder#5 (comment) |
Yes, I do. I've got:
and
I also set I'll ask sys admins about symlinks. |
Also, there doesn't seem to be any issues with the symlinks. The node seems to handle them just fine. |
Sorry, forgot for a moment you need to be explicit about the path on Linux, this went wrong because it should be If this works, the question is, why is BinaryProvider not satisfied here? You should try several versions of BinaryProvider, and if for instance it broke in later versions, it should be reported as an issue in the BinaryProvider repository. I just tried building GDAL using the latest BinaryProvider on CentOS, but had no issues. |
Oh... Yeah you're right, duh. I'm not getting the above. I get:
What is |
GLIBCXX refers to the C++ standard library ( I think I get it now. You built julia from source with an old GCC. Can you check the version? I assume it's GCC 4.x. The BinaryBuilder GDAL build is built with GCC 5.1, and links to a newer To resolve this there are some different options. You could instead of building julia from source, download the generic julia binaries and use those, they come shipped with a newer Of course it would be best if this package just works with self built julia. In BinaryBuilder they added a solution to that, where you can compile different binaries for different GCC versions. See JuliaPackaging/BinaryBuilder.jl#230. Though I don't think that's even needed here, because currently BinaryBuilder defaults to GCC 4.8.5 by default, using a All the options that require a new GDAL build are currently stuck on JuliaGeo/GDALBuilder#5 (comment). Hopefully someone can help out there. Ah and here are some tables with GCC and |
Wait, sorry, I spoke prematurely. Uhh, it's still failing in the same spot, even when I run it from the Julia 1.1 provided binary. |
What error exactly do you see? That might give a clue. You also didn't mention yet which GCC version you used to build julia. Having this information will help to validate (or throw out) my theory above. I'm happy that you reported this issue, such that we can fix it and people in the future will not get stuck on this. It will be extra helpful if you try to use the information and links I provided and go further to try to look for an answer. Truth is I also had to search for most of this information, I'm not an expert at all. So if it doesn't work now, next question that pops up is, which version of |
I'm using gcc version 4.8.5 |
The error is the same errors as provided above. |
If it is exactly the same as above:
That would mean it didn't load the |
Same problem here. Is there a way to manually point to the adequate library? Not sure what the cause of the problem is since I am able to dlopen the library inside i.e.: julia> using Libdl
julia> dlopen("libgeos_c")
Ptr{Nothing} @0x00000000018c98b0
julia> versioninfo()
Julia Version 1.2.0
Commit c6da87ff4b (2019-08-20 00:03 UTC)
Platform Info:
OS: Linux (x86_64-redhat-linux)
CPU: Intel(R) Xeon(R) Gold 6150 CPU @ 2.70GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
Environment:
JULIA_NUM_THREADS = 16
Trying to load GDAL julia> using GDAL
[ Info: Recompiling stale cache file /gpfs/home/dl2594/.julia/compiled/v1.2/GDAL/6JYbv.ji for GDAL [add2ef01-049f-52c4-9ee2-e494f65e021a]
WARNING: could not import GDAL.libgdal into C
ERROR: InitError: UndefVarError: libgdal not defined
Stacktrace:
[1] CPLSetErrorHandler at /gpfs/home/dl2594/.julia/packages/GDAL/vec6Y/src/C/cpl_error.jl:160 [inlined]
[2] __init__() at /gpfs/home/dl2594/.julia/packages/GDAL/vec6Y/src/GDAL.jl:55
[3] _include_from_serialized(::String, ::Array{Any,1}) at ./loading.jl:685
[4] _require_from_serialized(::String) at ./loading.jl:736
[5] _require(::Base.PkgId) at ./loading.jl:1023
[6] require(::Base.PkgId) at ./loading.jl:911
[7] require(::Module, ::Symbol) at ./loading.jl:906
during initialization of module GDAL
The content of the directory
I set up in
The build.log file shows:
|
Strange, not sure what is happening there, or why you get
Is using Julia 1.3 an option for you? My aim is to move the install over to the new Artifact system as soon as possible, and given the complexity of the GDAL build, it will be hard to make that work for older Julia releases as well. Since this is failing on GEOS, you could try installing LibGEOS v0.6.0 on Julia 1.3. That already uses the new system, so will be a good indication if this will help for you.
So it seems the provided GDAL is not working well on your system. If you have a separate GDAL installed on your system, you could try pointing it to that by replacing the paths in the deps/deps_*.jl. |
ok! I'll ask the sys admin to install Julia 1.3. This may take some time though as this is a big cluster. If this does not work, I'll ask for a system-wide installation of GDAL and update this thread accordingly. |
I think that somehow I was using version 0.2.0. Don't know why. Anyway, I removed some packages this morning and updated my ecosystem and GDAL went from 0.2.0 to 1.0.1 and can now build and test correctly. I guess I should have verified the module version and not assume it was the latest! :/ edit - It was ArchGDAL that was holding GDAL to 0.2. |
Ok good to know. We hope to have a new build soon, see JuliaGeo/GDALBuilder#12. That should allow ArchGDAL to use the latest GDAL version again. |
I think I'll close this issue now that in GDAL.jl 1.0.2 we use the new build of #81. That should fix several build issues. @kharazity if you still have issues with that release, please open a new issue. |
Hi all. I'm using Julia 1.1.0 on a Linux machine. I am installing a package which has GDAL as a dependency. I've been trying to get GDAL to work, but when I run
] test GDAL
I get;ERROR: LoadError: InitError: UndefVarError: libgdal not defined
. I also get the warning thatplatform_key()
has been deprecated when I try to]build GDAL
in the REPL. Is there reason for this error. I installed Julia 1.1.0 from tarball with and without deps and still seem to get this error. Any help would be appreciated.The text was updated successfully, but these errors were encountered: