Le 14/03/2024 à 19:27, Fengting Chen a écrit :

I included this fix but it doesn’t help. I was building the georaster driver as a plugin but the linker failed at building gdal library. So the fix doesn’t seem to be related to the problem.

You can't build the driver as a plugin with internal libjpeg. CMake should prevent you from doing that because of

https://github.com/OSGeo/gdal/blob/master/frmts/georaster/CMakeLists.txt#L6

But I now remember (thanks git blame!) that during the defered driver loading RFC development, I found that the condition to check that was broken. This was fixed in https://github.com/OSGeo/gdal/commit/adb0fd695253cf9fb91bee46309e6c66b25e8d65

Building Custom Rule C:/fechen/gdal-3.8.4/CMakeLists.txt

vsidataio.obj : error LNK2005: "void __cdecl jpeg_vsiio_src(struct jpeg_decompress_struct *,struct VSIVirtualHandle *)"

(?jpeg_vsiio_src@@YAXPEAUjpeg_decompress_struct@@PEAUVSIVirtualHandle@@@Z) already defined in vsidataio.obj [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

vsidataio.obj : error LNK2005: "void __cdecl jpeg_vsiio_dest(struct jpeg_compress_struct *,struct VSIVirtualHandle *)" (?jpeg_vsiio_dest@@YAXPEAUjpeg_compress_struct@@PEAUVSIVirtualHandle@@@Z) already defined in vsidataio.obj [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

Creating library C:/fechen/gdal-3.8.4/build/Debug/gdald.lib and object C:/fechen/gdal-3.8.4/build/Debug/gdald.exp

C:\fechen\gdal-3.8.4\build\Debug\gdald.dll : fatal error LNK1169: one or more multiply defined symbols found [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

*From: *Even Rouault <even.roua...@spatialys.com>
*Date: *Thursday, March 14, 2024 at 11:52 AM
*To: *Fengting Chen <fengting.c...@oracle.com>, gdal-dev@lists.osgeo.org <gdal-dev@lists.osgeo.org> *Subject: *Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows failed at linking

Hi,

possibly already fixed in master with commit https://github.com/OSGeo/gdal/commit/849226ce1a9 <https://urldefense.com/v3/__https:/github.com/OSGeo/gdal/commit/849226ce1a9__;!!ACWV5N9M2RV99hQ!KbMOD2u6nEacIP2ix07m6Y00zYu21fPOi8h2u_p-cjBCRSh9U8hYhTmK3txq5tv2LAvFBFXNfErVwdiaD9U8YKKFUCjQ$>

Even

Le 14/03/2024 à 16:47, Fengting Chen a écrit :

    After upgrading the windows build environment to VS2022, I got the
    following linker error:

    vsidataio.obj : error LNK2005: "void __cdecl jpeg_vsiio_src(struct
    jpeg_decompress_struct *,struct VSIVirtualHandle *)"
    (?jpeg_vsiio_src@@YAXPEAUjpeg_decompress_struct@@PEAUVSIVirtualHandle@@@Z)
    already defined in vsidataio.obj
    [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

    vsidataio.obj : error LNK2005: "void __cdecl
    jpeg_vsiio_dest(struct jpeg_compress_struct *,struct
    VSIVirtualHandle *)"
    (?jpeg_vsiio_dest@@YAXPEAUjpeg_compress_struct@@PEAUVSIVirtualHandle@@@Z)
    already defined in vsidataio.obj
    [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

    Creating library C:/fechen/gdal-3.8.4/build/Debug/gdald.lib and
    object C:/fechen/gdal-3.8.4/build/Debug/gdald.exp

    C:\fechen\gdal-3.8.4\build\Debug\gdald.dll : fatal error LNK1169:
    one or more multiply defined symbols found
    [C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]

    I set “GDAL_USE_JPEG_INTERNAL”  with “ON”. Any suggestions?

    Thanks!

    *From: *Even Rouault <even.roua...@spatialys.com>
    <mailto:even.roua...@spatialys.com>
    *Date: *Tuesday, March 12, 2024 at 12:56 PM
    *To: *Fengting Chen <fengting.c...@oracle.com>
    <mailto:fengting.c...@oracle.com>, gdal-dev@lists.osgeo.org
    <gdal-dev@lists.osgeo.org> <mailto:gdal-dev@lists.osgeo.org>
    *Subject: *Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on
    windows failed at linking

    Not the answer you'll probably want to hear, but:

    - Use an up-to-date compiler

    - Use package distributions like vcpkg or conda-forge that already
    brings all the dependencies "for free"

    - It seems you mix builds of different compilers (VS vs mingw).
    That's a bit asking for troubles ;-)

    Le 12/03/2024 à 17:48, Fengting Chen via gdal-dev a écrit :

        Resend with more information:

        I am trying to build GDAL 3.8.4 on windows under VS2015. The
        build failed at linking stage that a bunch of external symbols
        not found, specifically the symbols in libproj, libcurl. I
        checked the dll library stub .lib for libproj and libcurl
        using “dumpbin” and found the symbols in the library a little
        different, for example the linker error shows
        “__imp__curl_slist_append” not found, the symbol output from
        the “dumpbin” is  “__imp_curl_slist_append” .

        Any idea how to fix this?

        Thanks!

        *From: *gdal-dev <gdal-dev-boun...@lists.osgeo.org>
        <mailto:gdal-dev-boun...@lists.osgeo.org> on behalf of
        Fengting Chen via gdal-dev <gdal-dev@lists.osgeo.org>
        <mailto:gdal-dev@lists.osgeo.org>
        *Date: *Monday, March 11, 2024 at 4:50 PM
        *To: *gdal-dev@lists.osgeo.org <gdal-dev@lists.osgeo.org>
        <mailto:gdal-dev@lists.osgeo.org>
        *Subject: *[External] : [gdal-dev] GDAL 3.8.4 build on windows
        failed at linking

        GDAL 3.8.4 build on Windows from VS2015 x64 command prompt:
        “cmake –build .” throws the following error (there are more
        similar errors):

        cpl_vsil_az.obj : error LNK2001: unresolved external symbol
        __imp__curl_slist_append [E:\gdal-3.8.4\build\GDAL.vcxproj]

        cmake options has:

        set (GDAL_USE_CURL                ON CACHE  BOOL "" FORCE)

        set (CURL_INCLUDE_DIR
        "E:/SDK/curl-8.6.0_1-win64-mingw/include" CACHE PATH "" FORCE)

        set (CURL_LIBRARY_RELEASE
        "E:/SDK/curl-8.6.0_1-win64-mingw/bin/libcurl-x64.lib" CACHE
        FILEPATH "" FORCE)

        libcurl-x64.lib is the DLL stub. Using dumpbin on
        libcurl-x64.lib shows that “__imp_curl_slist_append” is
        available. But the linker error is “__imp__curl_slist_append”
        not found. There is an extra “_” in it.

        Any idea why this error occurred?

        Thanks!

        _______________________________________________

        gdal-dev mailing list

        gdal-dev@lists.osgeo.org

        https://lists.osgeo.org/mailman/listinfo/gdal-dev  
<https://urldefense.com/v3/__https:/lists.osgeo.org/mailman/listinfo/gdal-dev__;!!ACWV5N9M2RV99hQ!N8ZTSFcueASfCUE2XGRgmOMaX6fq5SFf-Tq25Un9Kws27WD09uZjzbSDMeAzmhzOrmz0mgSpFItXVTdprbA3RxpGPNVk$>

--
    http://www.spatialys.com  
<https://urldefense.com/v3/__http:/www.spatialys.com__;!!ACWV5N9M2RV99hQ!N8ZTSFcueASfCUE2XGRgmOMaX6fq5SFf-Tq25Un9Kws27WD09uZjzbSDMeAzmhzOrmz0mgSpFItXVTdprbA3R_bZl290$>

    My software is free, but my time generally not.

--
http://www.spatialys.com  
<https://urldefense.com/v3/__http:/www.spatialys.com__;!!ACWV5N9M2RV99hQ!KbMOD2u6nEacIP2ix07m6Y00zYu21fPOi8h2u_p-cjBCRSh9U8hYhTmK3txq5tv2LAvFBFXNfErVwdiaD9U8YKzOL5Qh$>
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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to