[VL] Fix wrong lib suffix for google_cloud_cpp_storage

[PHILO-HE]

What changes were proposed in this pull request?

Currently, static google_cloud_cpp_storage lib is used in both static build and dynamic build. The lib suffix was wrongly set for CMake to find the lib.

How was this patch tested?

Local verification.

[github-actions]

Thanks for opening a pull request!

Could you open an issue for this pull request on Github Issues?

https://github.com/apache/incubator-gluten/issues

Then could you also rename commit message and pull request title in the following format?

[GLUTEN-${ISSUES_ID}][COMPONENT]feat/fix: ${detailed message}

See also:

• Other pull requests

[PHILO-HE]

@zhztheplayer, just verified, we should set ".a" as the suffix for GCS.

[majetideepak]

@PHILO-HE, @zhztheplayer This change seems to be breaking our build since it expects a static libcurl.a as well.
Is this expected?

[2024-12-13T11:30:19.159Z] #11 1586.8 CMake Error at /usr/local/lib64/python3.9/site-packages/cmake/data/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
[2024-12-13T11:30:19.159Z] #11 1586.8   Could NOT find CURL (missing: CURL_LIBRARY) (found version "7.76.1")
[2024-12-13T11:30:19.159Z] #11 1586.8 Call Stack (most recent call first):
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/python3.9/site-packages/cmake/data/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/python3.9/site-packages/cmake/data/share/cmake-3.28/Modules/FindCURL.cmake:194 (find_package_handle_standard_args)
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/python3.9/site-packages/cmake/data/share/cmake-3.28/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/cmake/google_cloud_cpp_rest_internal/google_cloud_cpp_rest_internal-config.cmake:18 (find_dependency)
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/python3.9/site-packages/cmake/data/share/cmake-3.28/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
[2024-12-13T11:30:19.159Z] #11 1586.8   /usr/local/lib64/cmake/google_cloud_cpp_storage/google_cloud_cpp_storage-config.cmake:16 (find_dependency)
[2024-12-13T11:30:19.159Z] #11 1586.8   velox/CMakeLists.txt:124 (find_package)
[2024-12-13T11:30:19.159Z] #11 1586.8   velox/CMakeLists.txt:329 (find_gcssdk)

[FelixYBW]

@PHILO-HE, @zhztheplayer This change seems to be breaking our build since it expects a static libcurl.a as well. Is this expected?

Yes, the PR is to link libcurl.a always no matter you use vcpkg on or off.

[majetideepak]

@FelixYBW Why do we need to enforce set(CMAKE_FIND_LIBRARY_SUFFIXES ".a") here?
Can a user not control what library (static vs shared) to build when building the google_cloud_cpp_storage package?
Can we remove this enforcement in the CMakeLists.txt here? It will help users like me who want to use static google_cloud_cpp_storage but dynamic libcurl. Thanks.

[PHILO-HE]

Hi @majetideepak, I get your point. Just created one pr to try: #8251.
BTW, we are promoting static build, where vcpkg is leveraged to use static dependencies for gluten native lib. Maybe, you can try to use it.

[majetideepak]

@PHILO-HE Static build is fine to some extent but forcing standard shared libraries such as libcurl, openssl to be statically linked is tricky.
Some library could be expecting libcurl to be available dynamically and if we statically link a different libcurl version in a different library, it can introduce ODR violations which are tricky to fix. We have to track every library used for this.
Openssl has fips issue as reported here #8232

[PHILO-HE]

@PHILO-HE Static build is fine to some extent but forcing standard shared libraries such as libcurl, openssl to be statically linked is tricky. Some library could be expecting libcurl to be available dynamically and if we statically link a different libcurl version in a different library, it can introduce ODR violations which are tricky to fix. We have to track every library used for this. Openssl has fips issue as reported here #8232

@majetideepak, I see. We didn't realize this issue before. Considering what you mentioned, some libs should be dynamically linked even if static build is used for Gluten. We should adjust our target of static build. cc @FelixYBW