fix(build): export dynamic symbols from the Lua hosting binaries

[DennisOSRM]

Fixes the first half of #7700.

Problem

Lua C modules pulled in by a profile's require() are dlopen'ed at runtime and resolve their lua_* symbols against the hosting executable. Since the vcpkg migration in #7487 Lua comes from vcpkg and the x64-linux triplet links it statically, so those symbols never reach the dynamic symbol table:

terminate called after throwing an instance of 'sol::error'
  what():  lua: error: error loading module 'socket.core' from file
  '/usr/lib/x86_64-linux-gnu/lua/5.5/socket/core.so':
  /usr/lib/x86_64-linux-gnu/lua/5.5/socket/core.so: undefined symbol: lua_gettop

Before #7487 ENABLE_CONAN defaulted to OFF and the build used the system Lua, a shared liblua, so a dlopen'ed module resolved these symbols from the already loaded .so. This is a regression.

Fix

CMake historically added -rdynamic to every executable on ELF platforms. Under CMP0065, NEW here because of cmake_minimum_required(VERSION 3.18), it does so only for targets with ENABLE_EXPORTS:

CMake 3.4 and above prefer to do this only for executables that are explicitly marked with the ENABLE_EXPORTS target property.

So the property is set on osrm-extract and osrm-contract, the only two binaries linking ${LUA_LIBRARIES}. This is the documented mechanism for executables that load plugins via dlopen, and replaces the reporter's -DCMAKE_EXE_LINKER_FLAGS="-rdynamic" workaround.

Guarded with NOT MSVC, where ENABLE_EXPORTS instead produces an import library and is not needed.

Verification

No Linux machine was available here, so the policy behaviour was confirmed directly with a minimal project pinned to the same cmake_minimum_required(VERSION 3.18), using a sentinel in place of the platform export flag, which is empty on Apple:

target	export flag in link line
ENABLE_EXPORTS ON	present
default	absent

Locally osrm-extract and osrm-contract configure, link, and run. Worth a check on Linux against the reporter's lua-redis case before merging.

Not covered

The second half of #7700, system Lua module paths, is unaddressed. vcpkg builds Lua with upstream's LUA_ROOT of /usr/local/, so Debian's /usr/share/lua/5.5 is never searched. Separately, luaAddScriptFolderToLoadPath (include/util/lua_util.hpp:25) extends package.path but never package.cpath, so profile local C modules cannot be loaded on any platform. Both need a portability decision and are left for a follow up.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.79%. Comparing base (e9436d3) to head (b3509e4).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7710      +/-   ##
==========================================
+ Coverage   94.78%   94.79%   +0.01%     
==========================================
  Files         526      526              
  Lines       42085    42085              
==========================================
+ Hits        39891    39896       +5     
+ Misses       2194     2189       -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.