type-registry: switch from cdylib to staticlib and add it as a dependency to libia2

[kkysen]

No description provided.

[kkysen]

https://github.com/immunant/IA2-Phase2/actions/runs/13639316646/job/38126137570?pr=520#step:3:165

FAILED: runtime/type-registry/debug/libtype_registry.a /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry/debug/libtype_registry.a 
cd /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry && CARGO_TARGET_DIR=/mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry cargo build --manifest-path /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/runtime/type-registry/Cargo.toml --profile dev
error: rustc 1.83.0 is not supported by the following package:
  type-registry@0.1.0 requires rustc 1.84

@fw-immunant, do you know where the rustc 1.83 version is coming from here? I don't see it in ci.yml.

[fw-immunant]

https://github.com/immunant/IA2-Phase2/actions/runs/13639316646/job/38126137570?pr=520#step:3:165

FAILED: runtime/type-registry/debug/libtype_registry.a /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry/debug/libtype_registry.a 
cd /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry && CARGO_TARGET_DIR=/mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/build/runtime/type-registry cargo build --manifest-path /mnt/ssd2/home/perl/actions-runner/_work/IA2-Phase2/IA2-Phase2/runtime/type-registry/Cargo.toml --profile dev
error: rustc 1.83.0 is not supported by the following package:
  type-registry@0.1.0 requires rustc 1.84

@fw-immunant, do you know where the rustc 1.83 version is coming from here? I don't see it in ci.yml.

It must come from the runner environment on donna somewhere? cc @thedataking

[kkysen]

It must come from the runner environment on donna somewhere?

Is this from rust-lang/rustup#4211, or is this something else?

[fw-immunant]

See if adding a rustup toolchain install step to CI (and maybe a rust-toolchain.toml to the repo) fixes things, I guess.

[kkysen]

@fw-immunant, do you have any ideas on how to fix this? https://github.com/immunant/IA2-Phase2/actions/runs/13683941518/job/38262733305?pr=520#step:16:83.

ninja: error: 'runtime/type-registry/release/libtype_registry.a', needed by 'tests/abi/libabi_call_gates.so', missing and no known rule to make it

It seems to be working on x86 now, though.

[fw-immunant]

It seems like the consumer (libia2) doesn't seem to include CARGO_ARCH_SUFFIX in the path to the .a.

[fw-immunant]

I think target_link_libraries should just be able to refer to the type-library target instead of its internal .a.

[fw-immunant]

That said, it also seems like libia2 shouldn't actually need to depend on the type registry library, should it? Generated call-gates may, if the rewriter inserts type-registry based validation, but it seems like it'll just be dead code otherwise. Presumably just tests that depend on the type registry should have cmake dependencies declared on it.

[kkysen]

I think target_link_libraries should just be able to refer to the type-library target instead of its internal .a.

I tried that first, using type-registry, but it wasn't working.

That said, it also seems like libia2 shouldn't actually need to depend on the type registry library, should it? Generated call-gates may, if the rewriter inserts type-registry based validation, but it seems like it'll just be dead code otherwise. Presumably just tests that depend on the type registry should have cmake dependencies declared on it.

Wouldn't they just get dead-code eliminated if not used? I thought it'd be simpler that way.

[fw-immunant]

Amazing: if you use IMPORTED with add_library, the target is only visible in the current directory and below, unless you add the GLOBAL keyword to the add_library call.

I.e.,

diff --git a/runtime/libia2/CMakeLists.txt b/runtime/libia2/CMakeLists.txt
index aad855400..23ff26d07 100644
--- a/runtime/libia2/CMakeLists.txt
+++ b/runtime/libia2/CMakeLists.txt
@@ -39,7 +39,7 @@ endif()
 
 target_link_libraries(libia2 PRIVATE dl)
 
-target_link_libraries(libia2 PRIVATE "${CMAKE_BINARY_DIR}/runtime/type-registry/${CARGO_PROFILE_DIR}/libtype_registry.a")
+target_link_libraries(libia2 PRIVATE type-registry)
 
 target_include_directories(libia2 PUBLIC include)
 target_compile_definitions(libia2 PUBLIC _GNU_SOURCE)
diff --git a/runtime/type-registry/CMakeLists.txt b/runtime/type-registry/CMakeLists.txt
index e6e0a3cd5..7cd31b438 100644
--- a/runtime/type-registry/CMakeLists.txt
+++ b/runtime/type-registry/CMakeLists.txt
@@ -23,7 +23,7 @@ add_custom_command(
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Cargo.toml ${CMAKE_CURRENT_SOURCE_DIR}/src/lib.rs
 )
 
-add_library(type-registry STATIC IMPORTED)
+add_library(type-registry STATIC IMPORTED GLOBAL)
 set_property(TARGET type-registry PROPERTY IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${CARGO_ARCH_SUFFIX}/${CARGO_PROFILE_DIR}/libtype_registry.a)
 add_custom_target(type-registry-tgt DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${CARGO_ARCH_SUFFIX}/${CARGO_PROFILE_DIR}/libtype_registry.a)
 add_dependencies(type-registry type-registry-tgt)

[fw-immunant]

That said, it also seems like libia2 shouldn't actually need to depend on the type registry library, should it? Generated call-gates may, if the rewriter inserts type-registry based validation, but it seems like it'll just be dead code otherwise. Presumably just tests that depend on the type registry should have cmake dependencies declared on it.

Wouldn't they just get dead-code eliminated if not used? I thought it'd be simpler that way.

It's more a question of semantic organization than functional correctness. The type-registry is an example of one kind of data validation that a project using IA2 might want to do; it isn't part of what IA2 itself needs to do for all consumers.