- The freexl port builds in vcpkg CI, and there are no open issues for
Windows.
- Either there are log files for the actual error, reported on the
console, or it fails early for example because of mixing different
msys2/cygwin runtimes.
- freexl is an optional feature of port gdal. If nothing as
I didn't pay much attention to the CMake code. Now:
You don't need to deal with string(CONCAT ...). Normally you just need to
- treat VCPKG__FLAGS as CMake string (because this follows
CMAKE__FLAGS),
- treat as VCPKG_CMAKE_CONFIGURE_OPTIONS as CMake list, *quoting whole
list items* if needed.
IMO you ask for trouble when you manually inject -DFRMT_mrsid=ON into
CFLAGS and CXXFLAGS. This is CMake input ("ON"!). Let the configuration
do that for you. Did configuration successfully detect the dependency?
Check the config logs.
Kai
Am 22.02.25 um 05:15 schrieb Michael Katz via gdal-d
In vcpkg, I see downstream build errors for pdal, osgearth, gz-common5.
This seems to be related the GDAL_DEBUG changes,
https://github.com/OSGeo/gdal/pull/11314, in the context of forward
declarations in non-gdal code. It is probably visible only in debug
builds. (Vcpkg builds debug and releas
In our builds, we statically link the Proj library into GDAL. This
approach is necessary because our product integrates with other
environments that often include their own GDAL builds. In the past,
dynamically linking the Proj library caused significant issues: these
other environments would s
r, we only add -lstdc++ when building a test program
fails without this explicit addition. Cf
https://github.com/OSGeo/gdal/blob/master/cmake/helpers/GdalCompilationFlags.cmake#L165
to L183
Le 06/07/2024 à 12:02, Kai Pastor, DG0YT via gdal-dev a écrit :
Why does it have to force anything at
Why does it have to force anything at all? CMake normally knows how to
setup CMAKE_CXX_IMPLICIT_LINK_LIBRARIES.
(Right now fixing hard-coded libstdc++ assumptions in ffmpeg and
dependencies in vcpkg, breaking Android.)
Kai
Am 06.07.24 um 09:59 schrieb Even Rouault via gdal-dev:
Hi,
when us
Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:
Hi,
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
I did a test build in vcpkg, and I see downstream problems with static
linkage. It now raises:
CMake Error at /mnt/vss/_work/1/s/scripts/buildsystems/vcpkg.cma
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 schr
Am 15.02.24 um 00:42 schrieb Carl Godkin:
Hi Kai,
> To pass lists into cmake, you usually need ';' as item separator.
Thanks for the suggestion. I am sure I am missing something but
inserting a semi-colon on the Linux command line appears to require it
be escaped.
When I pass this:
-DW
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 sta
To pass lists into cmake, you usually need ';' as item separator.
(Exception: CMAKE__FLAGS which is a command line fragment with
space-separated items.)
In vcpkg, webp is configured via a CMAKE_PROJECT_INCLUDE file:
if(GDAL_USE_WEBP)
find_package(WebP CONFIG REQUIRED)
add_library(WEBP:
Am 29.09.23 um 16:20 schrieb Abel Pau via gdal-dev:
I add next two lines below (ODBC is not in vcpkg?)
list(APPENDCMAKE_PREFIX_PATH "C:/dev/vcpkg/vcpkg/installed")
set(ODBCCPP_INCLUDE_DIR "D:/GitHub-repository/odbc-cpp-wrapper/src")
Note that vcpkg's CMake integration requires using vcpkg's CM
These instructions seem unaware of the fact that builds are configured
by passing input variables to cmake. In particular it is not necessary
to edit CMakeList.txt, and some of the environment variables have no
effect at all.
I don't know how this is done in CLion. On the command line, you wou
git bash, quotes, make, this seems to add a lot of complication when you
could directly run cmake+ninja for fast builds on windows.
I think you shoudn't try to pass escaped quotes, but just quote the
whole arguments as in
... "-DINST_DATA=/c/prefix_path/shared"
"-DSYSCONF_DIR=/c/prefix_path
The dependency in PROJ is optional. If you build PROJ from source, it is
under your control.
Am 15.02.23 um 22:36 schrieb Fengting Chen:
Thanks. I later found out that libproj has dependency on libtiff. And
since libproj is required by GDAL, basically GDAL indirectly depends
on external libt
> What are the dependencies that I can just install with apt? I don't use conda
> or any of the other package managers listed in the readme. Any help is
> appreciated.
I would suggest to look at the gdal packaging in Ubuntu or Debian. There are
"make-depends" in the dsc files or in debian/contr
I'm not using MSVC, so this is a guess:
Are you including 'windows.h' without 'NOMINMAX' being defined?
Then you will get macros which interfere with the limits code.
Regards, Kai.
> Paul Meems hat am 17.12.2022 00:46 CET geschrieben:
>
>
> Thanks, Kurt for your response.
>
> I'm getting a ve
btiff/-/merge_requests/434
I've also added long overdue TIFFLIB_MAJOR_VERSION,
TIFFLIB_MINOR_VERSION, TIFFLIB_MICRO_VERSION defines
Even
Le 10/12/2022 à 11:40, Kai Pastor, DG0YT a écrit :
Thanks for your work!
There is an issue with tiff_vers.h:
The new linebreak style of the TIFF_VERSION_STR
Thanks for your work!
There is an issue with tiff_vers.h:
The new linebreak style of the TIFF_VERSION_STR definition breaks
version detection in CMake's FindTIFF.cmake,
leaving TIFF_VERSION unset (in CMake). Some packages rely on this
variable. E.g. openimageio in vcpkg:
-- Found TIFF
CMake E
Am 08.07.22 um 02:38 schrieb Nik Sands:
==
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
EXPAT_INCLUDE_DIR
EXPAT_LIBRARY
-- Build files have been written to: ...
==
Why would it be ignoring these a
> cmake -DSQLITE3_INCLUDE_DIR=~/build/include
> -DSQLITE3_LIBRARY=~/build/lib/libsqlite3.a ..
For static linkage, this may work for sqlite3, But often just providing the
library file path is not enough because it lacks transitive usage requirements
(i.e. additional libs like iconv).
> ld: lib
Am 07.06.22 um 09:28 schrieb Even Rouault:
Note: If you really wanted to get the equivalent of GDAL_INCLUDE_DIRS
and GDAL_LIBRARIES, you could use the following expressions:
$
$
It is not so trivial.
$
- won't carry GDAL itself
- may use generator expressions (in particular for multi-config
Am 02.05.22 um 14:12 schrieb Javier Jimenez Shaw:
If I understood the example you mention correctly, it is a direct
dependency of GDAL: the executable test_cpp links directly with GDAL.
Our problem is that we have a library (ioimage), that links with GDAL.
The error appears when we try to compil
It looks like you missed a " " after -DCMAKE_BUILD_TYPE=Release when
configuring GEOS:
> set_property(TARGET GEOS::geos APPEND PROPERTY IMPORTED_CONFIGURATIONS
> RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL)
Kai.
___
gdal-dev mailing list
gdal-dev@lists.o
ning the size of the GDAL binaries with each of them
> embedding libgdal.
>
> So even if I understand there are use cases for GDAL static builds
> (thanks for all the work you do on that side with your pull requests !),
> having them as the default in a distribution seems probl
> ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll', missing and no known
> rule to make it
'ws2_32.lib' is neither the name of a CMake target nor a flag ('-l'). So it is
taken as a file by Ninja. However, Ninja is not the linker and so it doesn't
find that file. Solutions:
- '-lws2_32' (a
I made an initial attempt on gdal with cmake for vcpkg:
https://github.com/microsoft/vcpkg/pull/22392
Now vcpkg's default is static linkage on Linux and macOS. AFAICT static
linkage is not covered very well. Fixing this needs a lot of work either
on the find modules, or on getting dependencies
28 matches
Mail list logo
