boneanxs commented on code in PR #11186:
URL: https://github.com/apache/gluten/pull/11186#discussion_r3869667350
##########
dev/vcpkg/ports/folly/portfile.cmake:
##########
@@ -60,39 +48,26 @@ vcpkg_cmake_configure(
# https://github.com/facebook/folly/issues/1623
-DFOLLY_NO_EXCEPTION_TRACER=ON
-DMSVC_USE_STATIC_RUNTIME=${MSVC_USE_STATIC_RUNTIME}
- -DCMAKE_DISABLE_FIND_PACKAGE_LibDwarf=OFF
- -DCMAKE_DISABLE_FIND_PACKAGE_Libiberty=ON
- -DCMAKE_DISABLE_FIND_PACKAGE_LibAIO=ON
- -DLIBAIO_FOUND=OFF
+ -DCMAKE_INSTALL_DIR=share/folly
+ -DCMAKE_POLICY_DEFAULT_CMP0167=NEW
+ -DVCPKG_LOCK_FIND_PACKAGE_fmt=ON
+ -DVCPKG_LOCK_FIND_PACKAGE_LibDwarf=OFF
Review Comment:
Hi, I noticed a possible semantic inversion in the LibDwarf configuration
introduced by this PR.
Before this change, Gluten used:
```cmake
-DCMAKE_DISABLE_FIND_PACKAGE_LibDwarf=OFF
```
This means LibDwarf discovery was enabled.
This PR changed it to:
```
-DVCPKG_LOCK_FIND_PACKAGE_LibDwarf=OFF
```
With the vcpkg toolchain, this causes CMAKE_DISABLE_FIND_PACKAGE_LibDwarf
to be enabled internally, so
find_package(LibDwarf) is skipped. As a result, Folly is generated with:
#define FOLLY_HAVE_DWARF 0
and Velox exception stack traces contain only empty numbered frames.
This appears to regress #7037 / #7038, where LibDwarf support was
explicitly added and verified to make Velox
stack traces work in Release builds.
Was disabling LibDwarf intentional in this PR, or was this expected to be
a semantically equivalent migration?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
