@Rocky Question: How to rebuild a single thirdparty library in the docker dev-env? We're working on a feature in our fork that requires libevent to be built with OpenSSL support. The pre-built thirdparty in the

starrocks/dev-env-ubuntu

docker images has libevent compiled without OpenSSL (

EVENT__HAVE_OPENSSL

is undefined in

event-config.h

,

libevent_openssl.a

is missing). We also noticed that

build-thirdparty.sh

builds libevent before openssl (line ~1463), so even a full rebuild from source produces libevent without OpenSSL — libevent's autotools configure can't find OpenSSL because it hasn't been built yet. The docker container runs as non-root (

--user $(id -u):$(id -g)

in

build-in-docker.sh

), so

/var/local/thirdparty

is read-only. Our current workaround is copying the pre-built thirdparty to a writable location, rebuilding just libevent there, and pointing

STARROCKS_THIRDPARTY

at the copy. Questions: 1. Is there an existing mechanism to selectively rebuild a single thirdparty library within the docker dev environment, or is the expectation that a new dev-env image gets published when thirdparty dependencies change? 2. Is the

build_libevent

before

build_openssl

ordering in

build-thirdparty.sh

intentional, or a bug? Happy to submit a PR for the fix if so.

Hi there! I'm Rocky. Dealing with the pre-built environment can be tricky when you need to change core dependencies. Here are the answers to your questions based on the StarRocks development workflow: 1. Rebuilding a Single Third-Party Library There isn't a dedicated "selective-rebuild" flag in the top-level

build.sh

, and as you've noted, the

/var/local/thirdparty

directory in official images is read-only for non-root users. The "official" way to handle this without building a new Docker image is indeed the workaround you've found: 1. Copy the thirdparty directory to a writable location in your workspace (e.g.,

cp -r /var/local/thirdparty ./thirdparty_local

). 2. Set the environment variable:

export STARROCKS_THIRDPARTY=$(pwd)/thirdparty_local

. 3. Run the selective build: You can trigger the build for a specific library by passing its name as an argument to the thirdparty build script:

bash
   cd $STARROCKS_THIRDPARTY
   ./build-thirdparty.sh libevent

_Note: Most StarRocks/Doris-style thirdparty scripts support passing the library name to call the corresponding

build_libraryname

function directly._ 2. Build Order of

libevent

and

openssl

The ordering of

build_libevent

before

build_openssl

in

build-thirdparty.sh

is almost certainly unintentional (a bug) if OpenSSL support in Libevent is required for your feature. In a standard dependency chain,

openssl

should be built before

libevent

and

thrift

so that their configuration stages (autotools/cmake) can detect and link against the OpenSSL headers and libraries located in the

${STARROCKS_THIRDPARTY}/installed

directory. Recommendation: * Submit a PR: The community would definitely appreciate a fix for this. Swapping the order ensures that

libevent

is compiled with

libevent_openssl.a

available, which is necessary for features requiring encrypted event transport. * Workaround for your PR: In your PR, you should also ensure that the

libevent

build function explicitly points to the OpenSSL installation path (e.g., using

--with-openssl=${STARROCKS_THIRDPARTY}/installed

) to ensure it doesn't accidentally pick up a system-level OpenSSL. If you have any more questions about the build system, feel free to ask! Good luck with your feature! References • using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views.md • data_source/catalog/deltalake_catalog.md • data_source/feature-support-data-lake-analytics.md • knowledge/usage/best-practice.md