Generate more binary releases

[olt]

Binary releases were built by me in a local VM with Vagrant and a shell script and I manually uploaded them to https://imposm.org/static/rel/. This did not scale and prevented regular releases.

I've updated this procedure and all tagged versions are now automatically available as a binary release https://github.com/omniscale/imposm3/releases

Please use these releases with a new import (the cache is not compatible with older releases as we switched from HyperLevelDB to LevelDB). The releases are build on Ubuntu 14.04 and they are compatible with any Linux distribution that uses glibc 2.19 or higher (e.g. Ubuntu 14.04, Debian 8, SLES 12, Fedora 21; see https://en.wikipedia.org/wiki/GNU_C_Library#Version_history).

Please use this ticket to report any issues with this releases!

[yohanboniface]

@olt: The commit changing the releases URL does not seems to be reflected in the documentation.

[yohanboniface]

Not sure if I'm missing something or if there is an issue in the Github release with shared libraries.

If I run the imposm binary from https://github.com/omniscale/imposm3/releases/download/v{release}/imposm-0.6.0-alpha.4-linux-x86-64.tar.gz on a fresh Ubuntu 18.04 install, I hit:

imposm: error while loading shared libraries: libleveldb.so: cannot open shared object file: No such file or directory

I don't have any issue if I run the binary from https://imposm.org/static/rel/imposm3-0.4.0dev-20170519-3f00374-linux-x86-64.tar.gz

Thanks for your lights :)

[olt]

@yohanboniface Docs are updated.

Is the lib directory still next to the binary? What is the output if ldd ./imposm and ldd ./lib/libleveldb.so?

$ ldd ./imposm
linux-vdso.so.1 (0x00007ffda8536000)
libleveldb.so => /tmp/imposm-0.6.0-alpha.4-linux-x86-64/./lib/libleveldb.so (0x00007fb4d10cb000)
libgeos_c.so.1 => /tmp/imposm-0.6.0-alpha.4-linux-x86-64/./lib/libgeos_c.so.1 (0x00007fb4d0e99000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb4d0c7c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4d08d1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb4d05c6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb4d03b0000)
libgeos-3.6.2.so => /tmp/imposm-0.6.0-alpha.4-linux-x86-64/./lib/libgeos-3.6.2.so (0x00007fb4d0001000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb4d135f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb4cfd00000)


$ ldd ./lib/libleveldb.so
linux-vdso.so.1 (0x00007fffb85fc000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8105daa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8105b94000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8105977000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f81055cc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f81052cb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8106349000)

[yohanboniface]

Is the lib directory still next to the binary?

Ekh, no :s I'm moving the binary to the bin folder. Note that this used to work™ with previous releases ;) Is that choice on purpose? I can change my strategy (symlink instead for eg), but I feel like this is less portable in general, and specifically for package managers, but I may be missing the point. :)

root@scw-152195:~# imposm
imposm: error while loading shared libraries: libleveldb.so: cannot open shared object file: No such file or directory
root@scw-152195:~# ldd /usr/bin/imposm 
	linux-vdso.so.1 (0x00007ffc93b59000)
	libleveldb.so => not found
	libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007f2d00617000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2d003f8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d00007000)
	libgeos-3.6.2.so => /usr/lib/x86_64-linux-gnu/libgeos-3.6.2.so (0x00007f2cffc6e000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2cff8e0000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2cff6c8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2d00846000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2cff32a000)

For the record, with previous binary

root@scw-152195:~# ldd /usr/bin/imposm 
	linux-vdso.so.1 (0x00007ffe23fc4000)
	libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007f8a82ec1000)
	libleveldb.so.1 => /usr/lib/x86_64-linux-gnu/libleveldb.so.1 (0x00007f8a82c64000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8a82a45000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a82654000)
	libgeos-3.6.2.so => /usr/lib/x86_64-linux-gnu/libgeos-3.6.2.so (0x00007f8a822bb000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8a81f2d000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8a81d15000)
	libsnappy.so.1 => /usr/lib/x86_64-linux-gnu/libsnappy.so.1 (0x00007f8a81b0d000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8a8176f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8a830f0000)

Thanks for you help :)

[olt]

The lib directory is not new and the releases always contained a copy of recent GEOS and (Hyper)LevelDB libs. However the new Imposm binaries require LevelDB 1.21 which is not yet released. So loading your systems LevelDB in /usr/lib/x86_64-linux-gnu/libleveldb.so.1 fails.

I think package managers will compile from source anyway.