VCS: runtime simv -load maps a VPI library but never calls its registration routine; VPI needs the compile-time -load

On VCS W-2024.09, a simv elaborated with -debug_access+all (which implies +vpi) and launched as 'simv -ucli -load ./lib.so:my_register' maps the shared library: an __attribute__((constructor)) in it runs. But my_register is never called, before or after 'run', with or without -ucli2Proc, -no_save, +vpi, or a vlog_startup_routines table. A misspelled routine name gives no error either, so this fails silently.

Why, per the VCS user guide: the VPI registration routine is named with the COMPILE-time 'vcs ... -load lib.so:routine' (section 'Integrating a VPI Application With VCS'; the guide also says the library should not contain vlog_startup_routines). The RUNTIME 'simv -load lib.so' is 'Dynamic Loading of PLI Libraries at Runtime': it only resolves PLI routines declared at compile time with '-P pli.tab'.

Dead ends: - Calling vpi_register_cb from the library constructor segfaults (virInitAccVpi), because VPI isn't initialised yet when -load maps the library. - UCLI 'loaddl lib.so {sym}' loads symbols for DPI resolution only; UCLI 'call {sym}' refuses anything that isn't a registered system task.

So plan one relink to make a build controllable through VPI. To avoid relinking again, link a tiny stub as the -load routine that dlopens the real library from an env var and forwards to it; a launch without the env var behaves as before.

Also seen: in UCLI mode, simv prints that ASLR is detected and re-executes itself with ASLR off, so $save works; -no_save skips that. And loading the Synopsys environment module can put an old Node.js first on PATH, so pin the node path in launch scripts.