[gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

2024-02-20 Thread Michael Otto via gdal-dev 
Thanks to all who have responded.

I have now tried it with 'vcpkg install gdal[tools]'. The tools/apps are 
there, but they are not statically linked!

See for example gdalinfo:

root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg/installed/x64-linux/tools/gdal# 
ldd gdalinfo
linux-vdso.so.1 (0x7ffcc0fb3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe3a31ae000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fe3a2f82000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe3a2d59000)
/lib64/ld-linux-x86-64.so.2 (0x7fe3a6b09000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fe3a2d39000)

Michael


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

2024-02-20 Thread Kai Pastor, DG0YT via gdal-dev 
When you install gdal[tools], the apps are installed to 
`/tools/gdal`.

(The vcpkg focus is on providing libs build from source.)

To explore port features, you can look at the port's vcpkg.json (aka 
manifest), or start from

https://vcpkg.link/ports/gdal

Regards,
Kai


Am 20.02.24 um 12:22 schrieb Michael Otto via gdal-dev:

Hi Robert,

because I'm not getting anywhere with the "standard" CMake solution, 
I've now used the vcpkg you mentioned and am using it in a Virtualbox 
VM with Linux Mint.


I got the installation instructions from here: 
https://github.com/microsoft/vcpkg?tab=readme-ov-file#quick-start-unix 
. 
I have installed the Linux developer tools (see instructions).


I have installed vcpkg under 
'root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg'.


When installing the libraries, it seems that a lot of dependencies are 
also loaded, compiled and installed in the now large set of directories.


The directory './vcpkg/packages/_x64-linux' now contains 
the compiled static versions of the libraries. But where can I find 
the GDAL apps? These are not contained in this directory.


I am still new to the topic of "self-compiling".
Do you have any tips on what else I need to do?

Michael




Von: "Robert Coup" 
An: "Michael Otto" 
Kopie: gdal-dev@lists.osgeo.org
Datum: 12.02.2024 15:43
Betreff: Re: [gdal-dev] Build static GDAL-Lib and static GDAL-Apps




Hi Michael,

On Mon, 12 Feb 2024 at 12:02, Michael Otto via gdal-dev 
<_gdal-dev@lists.osgeo.org_ > wrote:


The goal is to cast GDAL and all its dependencies (PROJ / GEOS / all 
dependencies to system libraries / ...) into a static library and to 
create the GDAL apps as static executable programs.


Which platform are you working on? If you need a fully static 
compilation of everything /all/ the way down including openssl + zlib 
+ zstd + libtiff + all the other libraries, using vcpkg[1] might be a 
reasonable approach. By default it does static compilation on macOS & 
Linux, and it has a static compilation option on Windows (the default 
on Windows is dynamic). It doesn't support every compile option 
though, but it's customisable and if you're after a reasonably vanilla 
GDAL it should work ok.



There should be no dynamic dependencies.

Note that GDAL + Proj (maybe others), have data files they rely on, so 
while you may be able to get a single executable, you'll still need to 
distribute these files. I can imagine ways around that, but they're 
getting fairly complex.


Unfortunately, I have not had any success so far. The library is 
created statically but the apps are not yet.
Does anyone have experience with this topic or possibly a procedure 
that leads to success?


Can you share the process you've currently got to?

Rob :)

[1] _https://github.com/microsoft/vcpkg_ 





___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

2024-02-20 Thread Michael Otto via gdal-dev 
Hi Robert,

because I'm not getting anywhere with the "standard" CMake solution, I've 
now used the vcpkg you mentioned and am using it in a Virtualbox VM with 
Linux Mint.

I got the installation instructions from here: 
https://github.com/microsoft/vcpkg?tab=readme-ov-file#quick-start-unix. I 
have installed the Linux developer tools (see instructions).

I have installed vcpkg under 
'root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg'.

When installing the libraries, it seems that a lot of dependencies are 
also loaded, compiled and installed in the now large set of directories.

The directory './vcpkg/packages/_x64-linux' now contains the 
compiled static versions of the libraries. But where can I find the GDAL 
apps? These are not contained in this directory. 

I am still new to the topic of "self-compiling".
Do you have any tips on what else I need to do?

Michael




Von:"Robert Coup" 
An: "Michael Otto" 
Kopie:  gdal-dev@lists.osgeo.org
Datum:  12.02.2024 15:43
Betreff:Re: [gdal-dev] Build static GDAL-Lib and static GDAL-Apps



Hi Michael,

On Mon, 12 Feb 2024 at 12:02, Michael Otto via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

The goal is to cast GDAL and all its dependencies (PROJ / GEOS / all 
dependencies to system libraries / ...) into a static library and to 
create the GDAL apps as static executable programs. 

Which platform are you working on? If you need a fully static compilation 
of everything all the way down including openssl + zlib + zstd + libtiff + 
all the other libraries, using vcpkg[1] might be a reasonable approach. By 
default it does static compilation on macOS & Linux, and it has a static 
compilation option on Windows (the default on Windows is dynamic). It 
doesn't support every compile option though, but it's customisable and if 
you're after a reasonably vanilla GDAL it should work ok.
 

There should be no dynamic dependencies.

Note that GDAL + Proj (maybe others), have data files they rely on, so 
while you may be able to get a single executable, you'll still need to 
distribute these files. I can imagine ways around that, but they're 
getting fairly complex.
 
Unfortunately, I have not had any success so far. The library is created 
statically but the apps are not yet.
Does anyone have experience with this topic or possibly a procedure that 
leads to success?

Can you share the process you've currently got to?

Rob :) 

[1] https://github.com/microsoft/vcpkg



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

2024-02-13 Thread Kai Pastor, DG0YT via gdal-dev 

Am 13.02.24 um 08:18 schrieb Michael Otto via gdal-dev:
I currently use an Ubuntu VM and use an Alpine-Linux Docker container 
for compiling. First a static Geos library is created via cmake, then 
a static Proj library (without Curl, because this currently leads to 
errors) and then Gdal as a static library.


You must consider all transitive dependencies, build them in the right 
order, and ensure that transitive link libraries are passed on down to 
gdal and to the final app (with link libraries in correct order).
For more than a minimal build, it is really better solved by using 
package managers such as vcpkg than by reinventing the wheel - each 
dependency may add its own set of problems. A simplified(!) dependency 
graph for a minimal build in vcpkg, just gdal core features + geos:


zlib:
libjpeg-turbo:
liblzma:
openssl:
nlohmann-json:
curl[openssl, ssl, non-http]: openssl, zlib
sqlite3[json1, tool]:
tiff[lzma, jpeg, zip]: libjpeg-turbo, liblzma, zlib
proj[tiff, net]: curl, nlohmann-json, sqlite3, tiff
libgeotiff: proj, tiff
json-c:
geos:
gdal: geos, json-c, libgeotiff, proj, tiff, zlib

So libgeotiff, proj, tiff, curl all come with transitive usage 
requirements which depend on actual configuration.
This is impossible to reconstruct in CMake find modules (coming with 
CMake or GDAL).
In vcpkg, ports (maintainers) ensure that usage requirements are 
exported by each package (using CMake config or find module wrappers).


Kai
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Antwort: Re: Build static GDAL-Lib and static GDAL-Apps

2024-02-12 Thread Michael Otto via gdal-dev 
Hello Robert,

at the moment it's only about the Linux platform. And yes, it should be a 
static compilation with all the necessary dependencies (including libtiff 
and all the others).

I currently use an Ubuntu VM and use an Alpine-Linux Docker container for 
compiling. First a static Geos library is created via cmake, then a static 
Proj library (without Curl, because this currently leads to errors) and 
then Gdal as a static library. 
The basis of the script comes from this source: 
https://github.com/OSGeo/gdal/issues/4815.
I have updated the version used to the current version and replaced the 
existing './configure' and 'make' commands with cmake.

This is what it looks like:

Start docker:  docker run -it --rm -v $(pwd):/tmp golang:1.17.3-alpine3.13 
/bin/sh /tmp/mo_gdalbuild.sh

mo_gdalbuild.sh
---

#!/bin/sh

rm -r /tmp/gdal-3.8.3
rm -r /tmp/gdal-3.8.3.tar.gz
rm -r /tmp/geos-3.12.1
rm -r /tmp/geos-3.12.1.tar.bz2
rm -r /tmp/proj-9.3.0
rm -r /tmp/proj-9.3.0.tar.gz
rm -r /tmp/mo_gdal_install

set -e

proxy="http://172.16.7.13:8080";
export HTTP_PROXY="$proxy"
export HTTPS_PROXY="$proxy"

GDAL_VERSION=3.8.3
PROJ_VERSION=9.3.0
GEOS_VERSION=3.12.1

apk add --no-cache \
wget \
coreutils \
build-base \
unzip \
cmake

# statically linked version of PROJ.

apk add --no-cache \
sqlite \
sqlite-dev \
sqlite-static \
tiff \
tiff-dev
cd /tmp
wget --no-verbose -e use_proxy=yes -e https_proxy=$proxy https:
//download.osgeo.org/proj/proj-${PROJ_VERSION}.tar.gz
tar -xzf proj-${PROJ_VERSION}.tar.gz
cd proj-${PROJ_VERSION}

mkdir build
cd build

cmake \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_TESTING=OFF \
-DBUILD_PROJSYNC=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/tmp/mo_gdal_install/proj/dist \
-DENABLE_CURL=OFF \
..

cmake --build .
cmake --build . --target install


# statically linked version of GEOS.

cd /tmp
wget --no-verbose -e use_proxy=yes -e https_proxy=$proxy https:
//download.osgeo.org/geos/geos-${GEOS_VERSION}.tar.bz2
tar -xjf geos-${GEOS_VERSION}.tar.bz2
cd geos-${GEOS_VERSION}

mkdir build
cd build
cmake \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_TESTING=OFF \
-DCMAKE_INSTALL_PREFIX=/tmp/mo_gdal_install/geos/dist \
..

cmake --build .
cmake --build . --target install

# statically linked version of GDAL
# (a minimal version still needs to be configured !)

apk add --no-cache \
jpeg-dev \
libjpeg-turbo-static \
openssl-libs-static \
linux-headers

cd /tmp
wget --no-verbose -e use_proxy=yes -e http_proxy=$proxy http:
//download.osgeo.org/gdal/${GDAL_VERSION}/gdal-${GDAL_VERSION}.tar.gz
tar -xzf gdal-${GDAL_VERSION}.tar.gz
cd gdal-${GDAL_VERSION}

mkdir build
cd build

cmake \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_APPS=ON \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_TESTING=OFF \
-DCMAKE_PREFIX_PATH=/tmp/mo_gdal_install/gdal \
-DCMAKE_INSTALL_PREFIX=/tmp/mo_gdal_install/gdal \
-DGEOS_INCLUDE_DIR=/tmp/mo_gdal_install/geos/dist/include \
-DGEOS_LIBRARY=/tmp/mo_gdal_install/geos/dist/lib64/libgeos_c.a \
-DPROJ_INCLUDE_DIR=/tmp/mo_gdal_install/proj/dist/include \
-DPROJ_LIBRARY_RELEASE=/tmp/mo_gdal_install/proj/dist/lib64/libproj.a \
-DBUILD_JAVA_BINDINGS=ON \
-DGDAL_JAVA_INSTALL_DIR=/tmp/mo_gdal_install/java \
-DGDAL_JAVA_JNI_INSTALL_DIR=/tmp/mo_gdal_install/java/jni \
..

cmake --build .
cmake --build . --target install



If I check the individual libraries created using 'ldd', I can see that 
they are statically linked.

If I run 'ldd' on the resulting apps, it looks different. Everything is 
still linked dynamically. This should be changed ;o).

Best regards
Michael




Von:"Robert Coup" 
An: "Michael Otto" 
Kopie:  gdal-dev@lists.osgeo.org
Datum:  12.02.2024 15:43
Betreff:Re: [gdal-dev] Build static GDAL-Lib and static GDAL-Apps



Hi Michael,

On Mon, 12 Feb 2024 at 12:02, Michael Otto via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

The goal is to cast GDAL and all its dependencies (PROJ / GEOS / all 
dependencies to system libraries / ...) into a static library and to 
create the GDAL apps as static executable programs. 

Which platform are you working on? If you need a fully static compilation 
of everything all the way down including openssl + zlib + zstd + libtiff + 
all the other libraries, using vcpkg[1] might be a reasonable approach. By 
default it does static compilation on macOS & Linux, and it has a static 
compilation option on Windows (the default on Windows is dynamic). It 
doesn't support every compile option though, but it's customisable and if 
you're after a reasonably vanilla GDAL it should work ok.
 

There should be no dynamic dependencies.

Note that GDAL + Proj (maybe others), have data files they rely on, so 
while you may be able to get a single executable, you'll still need to 
distribute these files. I can imagine ways around that, but they're 
getting fairly complex.
 
Unfortunately, I have not had any success so far. The library is created 
static