-
Notifications
You must be signed in to change notification settings - Fork 7
Issue with curl version #7
Comments
@bu-ra3y 👋 thanks for opening the issue. Can you paste the full code to reproduce the message ? Thanks |
Alright I figured this out @bu-ra3y So on AWS Lambda the
The problem is then we ship our own curl lib with GDAL located in To fix this I think you need to set cc @mojodna and @fredliporace |
This will need to be tested but it seems to me that when setting the LD_LIBRARY_PATH gdal is linked to less libraries ( Default env
with
|
😢 just tried and it's not working
|
🎉 after spending the day compiling GDAL I finally found the solution 😄 Lines 104 to 105 in 358ce32
The idea is to fix shared libraries path using rpath. Sadly there is one major downside of doing so is that gdal won't be able to run if |
Way to go, Vincent.
When do you need libgdal.so in another location?
On Wed, Jan 23, 2019, 10:54 PM Vincent Sarago ***@***.***> wrote:
🎉 after spending the day compiling GDAL I finally found the solution 😄
https://github.com/RemotePixel/amazonlinux-gdal/blob/358ce32609cb64d31c3fd87b8e254e3e67b93db5/Dockerfile#L104-L105
The idea is to *fix* shared libraries path using *rpath*. Sadly there is
one major downside of doing so is that gdal won't be able to run if
libgdal.so is somewhere else /var/task/lib. I tried to use the $origin
variable but didn't succeed yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIVAziPBXS69p-758kW1KBHYcGiLj5JIks5vGTx3gaJpZM4aNoGC>
.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -
Will Barley
Schedule a call <https://calendly.com/will-barley>
+1.650.575.5445
|
Hi @bu-ra3y
I never so I'll publish this new version like that and then I'll try to play around. Note: This also fix a previous problem we had with libjpeg being in |
@vincentsarago , I really appreciate you addressing this. How do I take advantage of your fix?
Is there anything I need to do to change my paths/environment variables or do I leave that the same? |
@bu-ra3y no worry I'll push a new |
sorry @bu-ra3y I'm still checking everything is fine, I've deploy some lambda package using the new image and it seems the code run slower than when using libcurl provided by AWS Lambda |
In case this helps you: The main thing I am doing is reading TIFs from S3 using |
🤔 I may create a |
here are some result using gdal2.4.0-light (without curl and jpegturbo) HTTP/1
using gdal2.4.0 (with curl and jpegturbo) and HTTP/2 enable
using gdal2.4.0 (with curl and jpegturbo) and HTTP/1.1 enable
I kinda feel both options could be good because shipping gdal with its own CURL should reduce the number of HTTP call (GET) which could be a $ saver when working with requester-pays bucket. I'll go with the plan of pushing both image I could also backup the old |
I think we are done here. Thanks @bu-ra3y for you help 👼 |
When using the
2.3.2
and2.4.0
images I get this error when using Rasterio to open a TIF on S3:CPLE_AppDefined in GDAL was built against curl 7.59.0, but is running against 7.51.0. Runtime failure is likely !
I do not hit that error when using your old 2.2.2 image.
Does this have to do with the curl version you specify here?
amazonlinux-gdal/Dockerfile
Line 31 in b2ca47b
The text was updated successfully, but these errors were encountered: