Le 26/01/2022 à 20:26, Joaquim Manuel Freire Luís a écrit :
Ok, sorry you meant the FindHDF4.cmake that comes with GDAL. Doing
what you suggested (tried both) makes no difference but commenting
if(WIN32)
#list(APPEND HDF4_LIBRARIES ws2_32.lib)
endif()
makes the ws2_32 trouble go.
Ah my if(MSVC) suggestion was because I wrongly assumed you used mingw
(the _w64.dll suffix made me thing of mingw64), but I see the VC14 so
you use MSVC.
Can you try this then ?
if (WIN32)
find_library(WS2_32_LIBRARY ws2_32)
if( WS2_32_LIBRARY )
list(APPEND HDF4_LIBRARIES ${WS2_32_LIBRARY})
endif()
endif()
Le 26/01/2022 à 20:08, Joaquim Manuel Freire Luís a écrit :
Updated master (sorry, didn’t stop to think if the commit had been
merged)
However, I have cmake 3.22.1 but it doesn’t have a FindHDF4.cmake,
only a FinfHDF5
FindHDF4.cmake is in the GDAL repository, in
cmake/modules/packages/FindHDF4.cmake, so you can try editing it
locally with my below suggestions
I was building with
set(HDF4_INCLUDE_DIR
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_34/include)
set(HDF4_df_LIBRARY_RELEASE
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/hdfdll.lib)
set(HDF4_mfhdf_LIBRARY_RELEASE
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/mfhdfdll.lib)
and when I commented those lines the build advance … till it stop
at the “Cannot open include file: 'zlib.h'” but that is normal
since I’m not using the commit who fixed it.
*From:*Even Rouault <[email protected]>
<mailto:[email protected]>
*Sent:* Wednesday, January 26, 2022 6:50 PM
*To:* Joaquim Manuel Freire Luís <[email protected]>
<mailto:[email protected]>; [email protected]
*Subject:* Re: [gdal-dev] cmake status update - 99% good news!
did you update to master or did you try my pull request (not
merged yet) ?
If only master, can you try to change the reference to
"ws2_32.lib" to "ws2_32" in cmake/modules/packages/FindHDF4.cmake
as I suggested ?
Or perhaps change the if (WIN32) at line 91 to if (MSVC)
Le 26/01/2022 à 19:43, Joaquim Manuel Freire Luís a écrit :
Don’t know which commit did it. Updated this afternoon and
started to erroring right away with missing 'ws2_32.lib`
*From:*Even Rouault <[email protected]>
<mailto:[email protected]>
*Sent:* Wednesday, January 26, 2022 6:36 PM
*To:* Joaquim Manuel Freire Luís <[email protected]>
<mailto:[email protected]>; [email protected]
*Subject:* Re: [gdal-dev] cmake status update - 99% good news!
Le 26/01/2022 à 19:31, Joaquim Manuel Freire Luís a écrit :
I do have HDF4 but before I was able to build till the
end. I've here a gdal_w64.dll smiling to me. That's why I
said it got worst.
Sorry you lost me. Is https://github.com/OSGeo/gdal/pull/5179
<https://github.com/OSGeo/gdal/pull/5179> helping or not ? If
not helping, which commit in it is causing an issue ?
Le 26/01/2022 à 17:26, Joaquim Manuel Freire Luís a écrit :
>
> Joaquim,
>> But I found two other new issues when adding more
dependencies
>>
>> 1.
>>
C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45):
>> fatal error C1083: Cannot open include file: 'zlib.h':
No such file
>> or directory
>>
>> To work around this, I temporarily added zlib.h and
zconf.h to
>> frmts\mbtiles
> Should be fixed by the first commit of
> https://github.com/OSGeo/gdal/pull/5179
<https://github.com/OSGeo/gdal/pull/5179>
>
> I'm afraid it got worst
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/programs/compa_libs/gdal_GIT/build
ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll',
missing and no known rule to make it
I'd say on the contrary that it helped the build to go
further, didn't it ? My fixes are totally unrelated to a
ws2_32.lib missing
I see in configure.ac that we had the following logic
dnl
---------------------------------------------------------------------------
dnl Check if we need -lws2_32 (mingw)
dnl
---------------------------------------------------------------------------
echo "#include <winsock2.h>" > test_ws2_32.c echo
"#include <ws2tcpip.h>" >> test_ws2_32.c echo "void foo()
{}" >> test_ws2_32.c
if test -z "`${CC} -c test_ws2_32.c 2>&1`" ; then
LIBS="$LIBS -lws2_32"
fi
rm -f test_ws2_32*
dnl
---------------------------------------------------------------------------
dnl Check if we need -lpsapi (mingw)
dnl
---------------------------------------------------------------------------
echo "#include <windows.h>" > test_psapi.c echo "#include
<psapi.h>" >> test_psapi.c echo "void foo() {}" >>
test_psapi.c
if test -z "`${CC} -c test_psapi.c 2>&1`" ; then
LIBS="$LIBS -lpsapi"
fi
rm -f test_psapi*
This hasn't been ported yet to cmake builds.
I've ticketed that in
https://github.com/OSGeo/gdal/issues/5180
<https://github.com/OSGeo/gdal/issues/5180>.
Hum, upon reflection, the error message would seem to
indicate that we try to link to ws2_32.lib but it is not
found in your environemnt
Looking for ws2_32 in cmake build scripts, I see it is
referenced in
cmake/modules/packages/FindODBC.cmake:
set(_odbc_required_libs_names
odbccp32;ws2_32)
cmake/modules/packages/FindHDF4.cmake: list(APPEND
HDF4_LIBRARIES
ws2_32.lib)
Do you use any of ODBC or HDF4 in your build ? Could you
try to disable them and see if it makes a difference ?
Or maybe if you've HDF4, try to change the ws2_32.lib to
ws2_32 in cmake/modules/packages/FindHDF4.cmake ?
Even
--
http://www.spatialys.com <http://www.spatialys.com>
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
