add GDAL builder #293

visr · 2019-12-15T18:55:39Z

An attempt to build GDAL with a rather minimal set of dependencies. We'd like to add more, but only after this builds well, taking it one step at a time.

Going over it with @giordano on Slack we already managed to bypass configure errors (PROJ dependency checks) by adding CompilerSupportLibraries_jll, see the second commit. Unfortunately it does not seem possible to bypass these checks with configure arguments.

Right now, on x86_64-linux-gnu, this hits:

[14:59:35] sed: /workspace/destdir/x86_64-linux-gnu/lib/../lib64/libstdc++.la: No such file or directory
[14:59:35] libtool:   error: '/workspace/destdir/x86_64-linux-gnu/lib/../lib64/libstdc++.la' is not a valid libtool archive
[14:59:35] make[1]: *** [GNUmakefile:66: libgdal.la] Error 1

Which is odd since there is no /workspace/destdir/x86_64-linux-gnu/ directory. Not sure where that path comes from or how to fix it. I tried to add --without-libtool to configure, and with that I got a fully succesfull build on x86_64-linux-gnu. However it did not help on for instance i686-linux-musl, so I left it out here. There I got this error:

[16:15:16] /opt/i686-linux-musl/i686-linux-musl/include/c++/4.8.5/iostream:74: undefined reference to `__dso_handle'
[16:15:16] /opt/i686-linux-musl/bin/i686-linux-musl-ld: /workspace/srcdir/gdal-3.0.2/frmts/o/LERC_band.o: relocation R_386_GOTOFF against undefined hidden symbol `__dso_handle' can not be used when making a shared object
[16:15:16] /opt/i686-linux-musl/bin/i686-linux-musl-ld: final link failed: Bad value
[16:15:16] make[1]: *** [GNUmakefile:62: /workspace/srcdir/gdal-3.0.2/libgdal.so] Error 1

For that I still tried ; preferred_gcc_version=v"6" (like GEOS_jll), but that didn't change anything.

Relevant links
https://github.com/JuliaGeo/GDALBuilder
https://github.com/JuliaGeo/GDAL.jl
https://github.com/OSGeo/gdal/
https://gdal.org/

This gets us past a failure during the `configure` step where it checks the PROJ dependency by compiling test programs. This led to this failure related to `libstdc++`: ``` configure:24103: checking for proj_create_from_wkt in -lproj configure:24128: c++ -std=c++11 -o conftest -DHAVE_AVX_AT_COMPILE_TIME -DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -g -O2 conftest.cpp -lproj -L/workspace/destdir/lib -lproj -lz -L/workspace/destdir -L/workspace/destdir/lib -lpthread -lm -lrt -ldl >&5 /workspace/destdir/lib/libproj.so: undefined reference to `__cxa_throw_bad_array_new_length@CXXABI_1.3.8' /workspace/destdir/lib/libproj.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> ```

ViralBShah · 2019-12-15T19:19:14Z

Sweet! Looking forward to this.

giordano · 2019-12-15T19:36:52Z

To make ./configure succeed on Windows you have to set

export LDFLAGS="${libdir}"

(this is fine, it's common to have to do this), but also do

cp ${libdir}/libproj_6_2.dll ${libdir}/libproj.dll

otherwise -lproj won't be found 😑 I wonder if there are smarter ways to deal with this.

G/GDAL/build_tarballs.jl

visr · 2019-12-15T20:01:58Z

cp ${libdir}/libproj_6_2.dll ${libdir}/libproj.dll

Yeah sorry, this one was not yet included from GDALBuilder. Cannot find it anymore, but I believe that I saw this same trick being done in the GDAL repository.

MinGW builds should work, there are Travis configurations set here: https://github.com/OSGeo/gdal/tree/v3.0.2/gdal/ci/travis/mingw_w64

visr · 2019-12-15T20:49:44Z

Ok after fed5e11 we actually get 20 passing builds, 6 failing builds, overview at https://github.com/JuliaPackaging/Yggdrasil/pull/293/checks?check_run_id=349623402

I went through the 6 failing ones, and there are two different issues:

x86_64-linux-musl-cxx03 - libtool searching for libstdc++.la in wrong location
x86_64-linux-musl-cxx11 - libtool searching for libstdc++.la in wrong location
i686-w64-mingw32-cxx03 - libtool searching for libstdc++.la in wrong location
i686-w64-mingw32-cxx11 - libtool searching for libstdc++.la in wrong location
x86_64-w64-mingw32-cxx03 - libtool searching for libstdc++.la in wrong location
x86_64-w64-mingw32-cxx11 - libtool searching for libstdc++.la in wrong location

giordano · 2019-12-15T20:55:13Z

The problem with x86_64-linux-musl might be that it isn't doing a real cross-compilation and making a mess with different C++ libraries. From the log:

[20:13:28] checking whether we are cross compiling... no

Edit: well, there is only a single libstdc++.so in the entire file system, there is not much to get confused about 😕

G/GDAL/build_tarballs.jl

Co-Authored-By: Mosè Giordano <giordano@users.noreply.github.com>

visr · 2019-12-15T22:51:38Z

Ok, after a8937ca the Windows builds are still failing, but now at least similarly to the x86_64-linux-musl ones, with libtool having issues finding libstdc++ see the CI log. A difference between these two however is as @giordano noted, for x86_64-linux-musl it thinks we are not cross compiling, for Windows it does rightly think so.

giordano · 2019-12-15T23:42:42Z

G/GDAL/build_tarballs.jl

+
+if [[ ${target} == *mingw* ]]; then
+    export LDFLAGS="-L${libdir}"
+    cp ${libdir}/libproj_6_2.dll ${libdir}/libproj.dll


The more I think about this the more I'm convinced that we shouldn't do this here: in any case ${libdir}/libproj.dll must not be in the tarball generated by this builder, but if we keep this line and remove the file at the end of the builder, this file will be a missing dependency for whatever needs it. I think we should either copy the file in PROJ_jll or do something to convince GDAL to link against the right file.

libgdal needs libproj. However, due to PROJ_jll with it's libproj_6_2.dll being a dependency of GDAL_jll, won't libproj_6_2.dll already be dlopened before libgdal and thus everything is fine?

That's not a matter of being dlopened, when the linker is passed the option -lfoo it'll look for a file called libfoo.${dlext} (I think on Windows the "lib" is not necessary), with some variations to allow for the version number. Here the file is called libproj_6_2.dll, since the Makefile is compiling with -lproj the linker can't find libproj.dll (probably it would allow for libproj-62.dll). I think the dynamic loader follows similar rules as the linker: if the library is linked to libproj.dll, libproj_6_2.dll won't be an acceptable replacement.

Interesting. But in GDALBuilder we used the same trick and dit not distribute libproj.dll, only libproj_6_1.dll. And it does find it:

As far as I can see you're not deleting the file at the end, so it's probably in GDAL tarball, which is definitely something that we don't want. As I said before, the linker should allow for the version of the package to be in the file name, but I've never seen it as libproj_6_1, I'm surprised the loader can find it

Hmm in the old GDAL/lib there is libproj.dll.a, but that's all, and if I move that file away it still finds it just fine.

So at least we should add a rm ${libdir}/libproj.dll after compilation in this build script to prevent getting that file out of this build? And if we get issues we try to fix the name in the PROJ build script?

The libraries for Windows are under bin, not lib

Yeah I know, I just meant that under bin there is only libproj_6_1.dll, nothing else. So I gues the loader on Windows is sufficiently flexible, just not during the build, which is why we needed to rename it before the build only.

Have a look at b7eae71, if you don't like we can hard-reset it. However, I think this is a better way to deal with this, instead of copying files around.

In an ideal world, PROJ would provide a pkgconfig file and we would get from there the name of the library, instead of doing this mess.

Thanks! Have you considered submitting this patch upstream to https://github.com/OSGeo/gdal/commits/master/gdal/configure.ac?

giordano · 2019-12-16T00:13:35Z

I think the remaining problem is that ${prefix}/lib/libgeos_c.la is wrong, it has lines like:

# Libraries that this one depends upon.
dependency_libs=' /workspace/destdir/lib/libgeos.la /workspace/destdir/x86_64-w64-mingw32/lib/../lib/libstdc++.la'

Deleting all libtool libraries with (like in Gnome_themes_extra)

# Clear out `.la` files since they're often wrong and screw us up
rm -f ${prefix}/lib/*.la

lets me build successfully GDAL, but I get a lot of libtool error messages like

[00:17:47] /bin/sh /workspace/srcdir/gdal-3.0.2/libtool --mode=link --silent c++ -std=c++11 -L/workspace/destdir/bin -municode gnmanalyse.lo  /workspace/srcdir/gdal-3.0.2/libgdal.la -o gnmanalyse.exe
[00:17:47] libtool: warning: library '/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.la' was moved.
[00:17:47] libtool: warning: library '/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.la' was moved.
[00:17:47] libtool:   error: Could not determine the host path corresponding to
[00:17:47] libtool:   error:   '/workspace/srcdir/gdal-3.0.2/.libs:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib'
[00:17:47] libtool:   error: Continuing, but uninstalled executables may not work.
[00:17:47] libtool:   error: Could not determine the host path corresponding to
[00:17:47] libtool:   error:   '/workspace/destdir/bin:/workspace/srcdir/gdal-3.0.2/.libs:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../bin:/workspace/destdir/lib'
[00:17:47] libtool:   error: Continuing, but uninstalled executables may not work.
[00:17:47] libtool:   error: Could not determine the host path corresponding to
[00:17:47] libtool:   error:   '/workspace/srcdir/gdal-3.0.2/.libs:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib'
[00:17:47] libtool:   error: Continuing, but uninstalled executables may not work.
[00:17:47] libtool:   error: Could not determine the host path corresponding to
[00:17:47] libtool:   error:   '/workspace/destdir/bin:/workspace/srcdir/gdal-3.0.2/.libs:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib:/opt/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../bin:/workspace/destdir/lib'
[00:17:47] libtool:   error: Continuing, but uninstalled executables may not work.

which may however be harmless for us

staticfloat · 2019-12-17T02:45:57Z

which may however be harmless for us

I think they are. I always ignore libtool whenever I can. ;)

visr · 2019-12-17T21:08:10Z

Great, it's looking much greener on the Azure side.

For Windows and OSX I see some like this, but I assume it's harmless:

┌ Warning: libgdal-26.dll contains a `cpuid` instruction; refusing to analyze for minimum instruction set, as it may dynamically select the proper instruction set internally.  Would have chosen sandybridge, instead choosing core2.
└ @ BinaryBuilder ~/.julia/packages/BinaryBuilder/AaK4k/src/auditor/instruction_set.jl:1226
[ Info: Checking bin/libgdal-26.dll with RPath list String[]
┌ Warning: Linked library PSAPI.DLL could not be resolved and could not be auto-mapped
└ @ BinaryBuilder ~/.julia/packages/BinaryBuilder/AaK4k/src/Auditor.jl:290
┌ Warning: Linked library ODBCCP32.dll could not be resolved and could not be auto-mapped
└ @ BinaryBuilder ~/.julia/packages/BinaryBuilder/AaK4k/src/Auditor.jl:290
┌ Warning: Linked library ODBC32.dll could not be resolved and could not be auto-mapped
└ @ BinaryBuilder ~/.julia/packages/BinaryBuilder/AaK4k/src/Auditor.jl:290

The only failure is x86_64-w64-mingw32-cxx03. Its cxx11 counterpart is fine. The failure (see log) looks like:

[16:14:34] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `vtable for std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >'
[16:14:34] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[16:14:34] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >'
[16:14:34] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::operator=(std::runtime_error const&)'
[16:14:34] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct(unsigned long, char)'

To me it looks like libgeos is built for cxx11 string ABI only (release), whilst perhaps we should expand_cxxstring_abis in the GEOS build script as well. After all, GEOS is the library that caused me to report JuliaPackaging/BinaryBuilder.jl#407. Not sure why this would only fail the x86_64-w64-mingw32-cxx03 build though.

staticfloat · 2019-12-17T21:11:27Z

To me it looks like libgeos is built for cxx11 string ABI only (release), whilst perhaps we should expand_cxxstring_abis in the GEOS build script as well.

Agreed.

Not sure why this would only fail the x86_64-w64-mingw32-cxx03 build though.

I think this is an accident having to do with linking differences between platforms and ABIs. I'm pretty sure we would have runtime problems on the other platforms, but for some reason the win32 platform is throwing a compile-time problem (perhaps because GCC 4 on win32 actually cannot use cxx11-style strings, whereas other platforms do have the symbols in their compiler support libraries)

Ref JuliaPackaging#293 (comment)

* [GEOS] expand_cxxstring_abis Ref #293 (comment) * expand supported platforms directly

giordano · 2019-12-18T02:18:32Z

Still same error after rebuilding GEOS with expanded C++ ABIs 🤔

visr · 2019-12-18T09:49:45Z

Odd. The reason it is still the same error is that the cxx03 and cxx11 tarballs for GEOS are identical. Only the log, with random strings, is diffferent.

https://github.com/JuliaBinaryWrappers/GEOS_jll.jl/releases/tag/GEOS-v3.8.0%2B2

giordano · 2019-12-18T09:53:50Z

The reason it is still the same error is that the cxx03 and cxx11 tarballs for GEOS are identical

Are the libraries identical bit-by-bit? Did we already achieve reproducible builds?

visr · 2019-12-18T09:56:50Z

Haha yeah, bit by bit. Didn't test every platform, only GEOS.v3.8.0.aarch64-linux-musl and
GEOS.v3.8.0.x86_64-w64-mingw32.

giordano · 2019-12-18T23:14:04Z

Interestingly enough, I cannot generate reproducible builds locally: two different builds for the same target platforms generate non-identical libraries. Also the libraries for the two cxx* variants are different.

ViralBShah · 2020-01-08T22:52:00Z

This seems like it is quite close. What do we need to do to get it in?

visr · 2020-01-09T06:41:18Z

I think we need to get a cxx03 build of GEOS first, which hangs on #316.

giordano · 2020-01-18T04:14:32Z

By setting LDFLAGS to link against libpthread and libdl, like in 6d71674, now I can successfully compile locally for powerpc64le-linux-gnu-cxx11.

For Windows the problem was that PROJ couldn't be found, but we minor version was bumped in #394, hopefully that's the only issue.

For x86_64-linux-musl-cxx03 I'm moderately confident that the problem will be fixed by JuliaPackaging/BinaryBuilder.jl#604.

All in all, we may be very close to the end!

giordano · 2020-01-18T04:37:52Z

Amazingly enough, GEOS-v3.8.0+3 still has bit-by-bit identical binaries for the two C++ string ABIs:

% cmp GEOS.v3.8.0.x86_64-linux-musl-cxx03/lib/libgeos.so GEOS.v3.8.0.x86_64-linux-musl-cxx11/lib/libgeos.so && echo "We're identical"
We're identical
% nm GEOS.v3.8.0.x86_64-linux-musl-cxx03/lib/libgeos.so|c++filt|grep "std::__cxx11"
0000000000170c10 T geos::triangulate::quadedge::LocateFailureException::LocateFailureException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000170c10 T geos::triangulate::quadedge::LocateFailureException::LocateFailureException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000107f00 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000108ae0 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, double)
00000000001080c0 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000107f00 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000108ae0 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, double)
00000000001080c0 T geos::io::ParseException::ParseException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
00000000001090a0 T geos::io::StringTokenizer::StringTokenizer(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
00000000001090a0 T geos::io::StringTokenizer::StringTokenizer(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[...]

giordano · 2020-01-18T05:12:07Z

https://dev.azure.com/JuliaPackaging/Yggdrasil/_build/results?buildId=993&view=logs&j=095e0385-4ed6-507d-c56a-272f739074a5&t=9ecafb61-666a-549e-5150-2076c2e04e4c&l=4472

[ Info: /workspace/G/GEOS/build/x86_64-linux-musl-cxx03/1flhV0oH/destdir/lib/libgeos-3.8.0.so locks us to cxx11
┌ Warning: /workspace/G/GEOS/build/x86_64-linux-musl-cxx03/1flhV0oH/destdir/lib/libgeos-3.8.0.so contains cxx11 ABI std::string values within its public interface, but we are supposedly building for cxx03 ABI. This usually indicates that the build system is somehow ignoring our choice of compiler, as we manually insert the correct compiler flags for this ABI choice!
└ @ BinaryBuilder ~/.julia/dev/BinaryBuilder/src/auditor/compiler_abi.jl:200

As far as I can see, this is the only platform showing the infamous warning. It looks like when the target is x86_64-linux-musl the C++ string ABI is ignored. I compiled locally in verbose mode and _GLIBCXX_USE_CXX11_ABI is not set at all

Edit: continue to JuliaPackaging/BinaryBuilder.jl#604 (comment)

Includes a few build bug fixes: https://github.com/OSGeo/gdal/blob/v3.0.3/gdal/NEWS

giordano · 2020-01-19T00:34:14Z

Awesome, finally a different error not related to C++11 string ABI 😂

[00:30:46] /bin/sh /workspace/srcdir/gdal-3.0.3/libtool --mode=link --silent c++ -std=c++11  gdaltransform.lo  /workspace/srcdir/gdal-3.0.3/libgdal.la -o gdaltransform
[00:30:46] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:46] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:46] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:46] collect2: error: ld returned 1 exit status
[00:30:46] make[1]: *** [GNUmakefile:88: gdal_translate] Error 1
[00:30:46] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:46] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:46] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:46] collect2: error: ld returned 1 exit status
[00:30:46] make[1]: *** [GNUmakefile:91: gdaladdo] Error 1
[00:30:47] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:47] collect2: error: ld returned 1 exit status
[00:30:47] make[1]: *** [GNUmakefile:100: nearblack] Error 1
[00:30:47] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:47] collect2: error: ld returned 1 exit status
[00:30:47] make[1]: *** [GNUmakefile:94: gdalwarp] Error 1
[00:30:47] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:47] collect2: error: ld returned 1 exit status
[00:30:47] make[1]: *** [GNUmakefile:103: gdalmanage] Error 1
[00:30:47] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:47] collect2: error: ld returned 1 exit status
[00:30:47] make[1]: *** [GNUmakefile:121: gdalenhance] Error 1
[00:30:47] /workspace/destdir/lib/libgeos_c.so.1: undefined reference to `operator delete(void*, unsigned long)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
[00:30:47] /workspace/destdir/lib/libgeos-3.8.0.so: undefined reference to `std::runtime_error::runtime_error(char const*)'
[00:30:47] collect2: error: ld returned 1 exit status
[00:30:47] make[1]: *** [GNUmakefile:133: gdaltransform] Error 1
[00:30:47] make[1]: Leaving directory '/workspace/srcdir/gdal-3.0.3/apps'
[00:30:47] make: *** [GNUmakefile:112: apps-target] Error 2

Probably we need to build with gcc 6, geos has been built with gcc 6

visr added 2 commits December 14, 2019 19:57

add GDAL build script

6cbff30

giordano reviewed Dec 15, 2019

View reviewed changes

G/GDAL/build_tarballs.jl Show resolved Hide resolved

G/GDAL/build_tarballs.jl Outdated Show resolved Hide resolved

add review suggestions

fed5e11

giordano reviewed Dec 15, 2019

View reviewed changes

G/GDAL/build_tarballs.jl Outdated Show resolved Hide resolved

add missing -L flag in LDFLAGS

a8937ca

Co-Authored-By: Mosè Giordano <giordano@users.noreply.github.com>

giordano reviewed Dec 16, 2019

View reviewed changes

Clear out .la files

9f270c1

giordano closed this Dec 17, 2019

giordano reopened this Dec 17, 2019

ViralBShah closed this Dec 17, 2019

ViralBShah reopened this Dec 17, 2019

visr added a commit to visr/Yggdrasil that referenced this pull request Dec 17, 2019

[GEOS] expand_cxxstring_abis

0e040ef

Ref JuliaPackaging#293 (comment)

visr mentioned this pull request Dec 17, 2019

[GEOS] expand_cxxstring_abis #302

Merged

giordano pushed a commit that referenced this pull request Dec 18, 2019

[GEOS] expand_cxxstring_abis (#302)

64213e1

* [GEOS] expand_cxxstring_abis Ref #293 (comment) * expand supported platforms directly

giordano closed this Dec 18, 2019

giordano reopened this Dec 18, 2019

visr mentioned this pull request Dec 21, 2019

GEOS expanded cxx string ABIs are identical #316

Closed

giordano added the Science 👩‍🔬 Builder of scientific libraries label Dec 21, 2019

[GDAL] Customise name of PROJ lib to link against

b7eae71

giordano force-pushed the gdal branch from cc65b27 to b7eae71 Compare December 24, 2019 22:57

visr mentioned this pull request Jan 16, 2020

GEOS - rebuild after cxxstring_abi fixes in BB #392

Merged

giordano closed this Jan 18, 2020

giordano reopened this Jan 18, 2020

[GDAL] Fixes for Windows and PowerPC

feb1626

giordano added the long shot 🏹 This is going to be fun label Jan 18, 2020

This was referenced Jan 18, 2020

Setup dependencies that match the GCC ABI of the compiler JuliaPackaging/BinaryBuilder.jl#604

Merged

Chemfiles-v0.9.2+0 makes Julia crash on 64-bit Windows JuliaPackaging/BinaryBuilder.jl#603

Closed

[GDAL] use latest bugfix release 3.0.3

658845c

Includes a few build bug fixes: https://github.com/OSGeo/gdal/blob/v3.0.3/gdal/NEWS

giordano closed this Jan 19, 2020

giordano reopened this Jan 19, 2020

[GDAL] Build with GCC v6, for compatibility with GEOS

dd30d80

giordano merged commit 5556c40 into JuliaPackaging:master Jan 19, 2020

visr deleted the gdal branch January 19, 2020 11:18

visr mentioned this pull request Jan 22, 2020

use GDAL_jll for binary dependency JuliaGeo/GDAL.jl#82

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add GDAL builder #293

add GDAL builder #293

visr commented Dec 15, 2019 •

edited

Loading

ViralBShah commented Dec 15, 2019

giordano commented Dec 15, 2019 •

edited

Loading

visr commented Dec 15, 2019

visr commented Dec 15, 2019 •

edited by giordano

Loading

giordano commented Dec 15, 2019 •

edited

Loading

visr commented Dec 15, 2019

giordano Dec 15, 2019

visr Dec 17, 2019

giordano Dec 17, 2019 •

edited

Loading

visr Dec 17, 2019

giordano Dec 17, 2019

visr Dec 17, 2019

giordano Dec 17, 2019

visr Dec 17, 2019

giordano Dec 24, 2019

visr Dec 29, 2019

giordano commented Dec 16, 2019 •

edited

Loading

staticfloat commented Dec 17, 2019

visr commented Dec 17, 2019

staticfloat commented Dec 17, 2019

giordano commented Dec 18, 2019

visr commented Dec 18, 2019

giordano commented Dec 18, 2019 •

edited

Loading

visr commented Dec 18, 2019

giordano commented Dec 18, 2019

ViralBShah commented Jan 8, 2020

visr commented Jan 9, 2020

giordano commented Jan 18, 2020

giordano commented Jan 18, 2020

giordano commented Jan 18, 2020 •

edited

Loading

giordano commented Jan 19, 2020 •

edited

Loading

add GDAL builder #293

add GDAL builder #293

Conversation

visr commented Dec 15, 2019 • edited Loading

ViralBShah commented Dec 15, 2019

giordano commented Dec 15, 2019 • edited Loading

visr commented Dec 15, 2019

visr commented Dec 15, 2019 • edited by giordano Loading

giordano commented Dec 15, 2019 • edited Loading

visr commented Dec 15, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giordano Dec 17, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giordano commented Dec 16, 2019 • edited Loading

staticfloat commented Dec 17, 2019

visr commented Dec 17, 2019

staticfloat commented Dec 17, 2019

giordano commented Dec 18, 2019

visr commented Dec 18, 2019

giordano commented Dec 18, 2019 • edited Loading

visr commented Dec 18, 2019

giordano commented Dec 18, 2019

ViralBShah commented Jan 8, 2020

visr commented Jan 9, 2020

giordano commented Jan 18, 2020

giordano commented Jan 18, 2020

giordano commented Jan 18, 2020 • edited Loading

giordano commented Jan 19, 2020 • edited Loading

visr commented Dec 15, 2019 •

edited

Loading

giordano commented Dec 15, 2019 •

edited

Loading

visr commented Dec 15, 2019 •

edited by giordano

Loading

giordano commented Dec 15, 2019 •

edited

Loading

giordano Dec 17, 2019 •

edited

Loading

giordano commented Dec 16, 2019 •

edited

Loading

giordano commented Dec 18, 2019 •

edited

Loading

giordano commented Jan 18, 2020 •

edited

Loading

giordano commented Jan 19, 2020 •

edited

Loading