weixin_39929723
weixin_39929723
2021-01-01 05:54

GDAL 1.11.4

Fiona is broken in the default channel because it installs GDAL 2.0, which fiona is not ready to use yet.

See https://github.com/Toblerity/Fiona/issues/239 and https://github.com/ContinuumIO/anaconda-issues/issues/401.

Note to self: rasterio seems to be OK with GDAL 2.0 https://github.com/mapbox/rasterio/pull/505.

该提问来源于开源项目:conda-forge/staged-recipes

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

17条回答

  • weixin_39929723 weixin_39929723 4月前

    Travis is failing due to:

    The log length has exceeded the limit of 4 MB

    Even in a feedstock by itself gdal will still go over the 4 MB limit, unless we reduce the build matrix to only one Python/NumPy version at a time :unamused:

    点赞 评论 复制链接分享
  • weixin_39648539 weixin_39648539 4月前

    Even in a feedstock by itself gdal will still go over the 4 MB limit, unless we reduce the build matrix to only one Python/NumPy version at a time :unamused:

    Ouch. I thought there was a way of building GDAL without its python bindings, and then providing python bindings independently. Is that an option?

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    I thought there was a way of building GDAL without its python bindings, and then providing python bindings independently.

    There is. I was avoiding it for two reason: (a) laziness and (b) to avoid dealing with naming things.

    I can solve (a) with :coffee:, (b) on the other hand, is more complicated.

    I don't like the fact that the default channel names gdal (the executable files, the non-python bindings, and the libs) libgdal while naming calls gdal the python bindings only. However, for consistent, I guess we'll have do the same. Ideas? (Maybe naming the former gdal, the latter python-gdal and break consistency with the default channel? Not sure if that is the better way to go.)

    Is that an option?

    I am testing that right now. I will send the PR probably later today.

    点赞 评论 复制链接分享
  • weixin_39648824 weixin_39648824 4月前

    Could you redirect some of the build output (say the results of ./configure and make install) to a file to limit the log size? These logs could be made available as artifacts if they are really needed.

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    Could you redirect some of the build output (say the results of ./configure and make install) to a file to limit the log size?

    I tried that before and I think that Travis-CI by passes the redirection. (I read somewhere that there is a way to do that using some ruby config magic, but I am not sure it is worth it.)

    I am closing #51 and I will try again here. Even without the python bindings the logs/timeout still blow Travis-CI out. So, since re-starting Travis-CI is inevitable, I believe that keeping one recipe for gdal is the way to go.

    点赞 评论 复制链接分享
  • weixin_39648539 weixin_39648539 4月前

    I believe that keeping one recipe for gdal is the way to go

    But then we have a huge install for py27, py34 and py35. Surely we are better off with one huge install and 3 little py27, 34, and 35 distributions for the py bindings?

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    But then we have a huge install for py27, py34 and py35. Surely we are better off with one huge install and 3 little py27, 34, and 35 distributions for the py bindings?

    Yes, the download is big... The main reason I went that route is to do the same as the osgeo channel (the most popular channel for gdal), and because I failed miserably to build a libgdal only on Windows.

    I kept getting a Hint: libgdal has unsatisfiable dependencies (see 'conda info libgdal') even though all dependencies were consistent with each other and I could install the "broken" tarball (and it worked!).

    I will try again...

    点赞 评论 复制链接分享
  • weixin_39648539 weixin_39648539 4月前

    I've just remembered about the fact we need to compile for each VS anyway (see https://github.com/conda-forge/staged-recipes/pull/79#issuecomment-193316623) so this approach is fine! :+1:

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    so this approach is fine!

    OK. So, unless you have a suggestion for the AppVeyor failure I will skip Windows+PY35 and end this. (My computer handle another gdal build :wink:)

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    Looks like a patch may be necessary (unless it has already been fixed in GDAL upstream)

    gdal 1.11.4 is the latest on the 1.X series (release in January 2016 together with gdal 2.0.2). So guess it is not patched.

    I will take a look at making one but, if you agree, I would like to get this merged first to get the Linux and OS X packages out there.

    点赞 评论 复制链接分享
  • weixin_39648539 weixin_39648539 4月前

    I will take a look at making one but, if you agree, I would like to get this merged first to get the Linux and OS X packages out there.

    Oh, completely! Merge as soon as you are happy - I don't need this to have 3 green ticks to move forwards. :+1: :+1: :+1: :+1: :+1:

    点赞 评论 复制链接分享
  • weixin_39648539 weixin_39648539 4月前

    P.S. For now, just skip the 3.5 build - only do it when we have a need? Maybe just capture the information in an issue on the feedstock...

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    P.S. For now, just skip the 3.5 build - only do it when we have a need? Maybe just capture the information in an issue on the feedstock...

    Will do.

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    I will keep this PR open because I realized I cannot access AppVeyor's logs for the feedstocks (For example this returns Project not found or access denied.)

    PS: Can you enable AppVeyor's rolling-builds option. I will be sending a series of tests PRs and that option will save a lot of time.

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    The last commit introduces some code I "stole" from gdal 2.0.0 that got us a little closer to compiling gdal 1.11.4 on AppVeyor and Microsoft Visual Studio 14.0, but my googling skills are lacking and I cannot solve the last issue.

    
    odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function _StringCchPrintfW
    gdal111.dll : fatal error LNK1120: 1 unresolved externals
    NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\link.EXE"' : return code '0x460'
    
    点赞 评论 复制链接分享
  • weixin_39633917 weixin_39633917 4月前

    looks like https://connect.microsoft.com/VisualStudio/feedback/details/1134693/vs-2015-ctp-5-c-vsnwprintf-s-and-other-functions-are-not-exported-in-appcrt140-dll-breaking-linkage-of-static-libraries

    Not sure about a total solution, though - looks like MS needs to release a newer SDK or something.

    点赞 评论 复制链接分享
  • weixin_39929723 weixin_39929723 4月前

    Not sure about a total solution, though - looks like MS needs to release a newer SDK or something.

    Yep. I guess we need to wait :unamused:

    Thanks!

    点赞 评论 复制链接分享

相关推荐