I spent a good chunk of time upgrading Cadence Virtuoso’s optimizer (AOP) from IC25.1 base to the ISR4 hotfix. What should’ve been a routine update turned into two rabbit holes: the optimizer was checking for a license that doesn’t exist on most servers, and the hotfix installer kept dying on symlinks that point to each other in a loop. Sharing this in case it saves someone else the trouble.
What I Was Doing
IC25.1 base (June 2025 build) was up and running — schematic editor, simulator, everything worked fine. Then I tried to launch AOP, the Design Space Optimization (DSO) engine for automated circuit optimization.
It wouldn’t start.
“LMC-11951: License call failed for feature Virtuoso_ADE_Artist”
The DSO server log had this:
INFO LicenseChecker - Checking for license Virtuoso_ADE_Artist
with license number 95275
ERROR LicenseChecker - (LMC-11951): License call failed for feature
Virtuoso_ADE_Artist, version 1.0.
No such feature exists on any of the license sources
ERROR LicenseChecker - Failed to find licenses Virtuoso_ADE_Artist(95275)Straightforward enough — license not found. Except I had the right license. The RAK docs say you need an ADE Assembler license and a VVO license. Quick lmstat check:
Virtuoso_ADE_Assembler: 888 licenses, 5 in use
Virtuoso_Variation_Option: 888 licenses, 0 in useBoth present. VVO not even in use. So why is the DSO server asking for something called Virtuoso_ADE_Artist instead?
Why IC25.1 Base Checks the Wrong License
No config file controls this. I checked — searched the entire DSO/ tree for config files, properties, anything mentioning “Artist.” Nothing.
So I went one level deeper: extract LicenseChecker.class from the DSO server JAR (OptimizerApi-0.0.1-SNAPSHOT.jar) and run strings on it.
IC25.1 base:
LICENSE_NAME_ARTIST
Virtuoso_ADE_Artist
95275
For comparison, IC23.1 (where AOP works fine):
LICENSE_NAME_CADENCE
Virtuoso_Variation_Option
That’s the problem. IC23.1 checks Virtuoso_Variation_Option — the standard VVO license that every customer has. IC25.1 base checks Virtuoso_ADE_Artist — a different license tier. The feature name was hardcoded into a compiled Java class inside the JAR. No config file, no environment variable, no override possible.
I also checked the Python-side license module (EliWrapper.so, ~15MB). Same story — the base version only has Virtuoso_ADE_Artist baked in.
Fix: Apply the IC25.1 ISR4 Hotfix
The ISR4 hotfix (February 2026) fixes this. Comparing strings in EliWrapper.so:
| STRING | BASE (JUN 2025) | ISR4 (FEB 2026) |
|---|---|---|
Virtuoso_ADE_Artist | Present | Gone |
Virtuoso_Variation_Option | Missing | Added |
Virtuoso_Variation_Analysis_Op | Missing | Added |
The hotfix quietly swaps the license check back to VVO. The release notes don’t call this out — it’s buried among hundreds of CCR fixes. Only way to confirm is comparing the binaries.
Bottom line: IC25.1 base has a license regression in DSO. If you see Failed to find licenses Virtuoso_ADE_Artist(95275) and you have a Virtuoso_Variation_Option license, apply ISR4.
“Too many levels of symbolic links” During ISR4 Hotfix Install
Great, so ISR4 fixes the license. I ran InstallScape to apply it. It failed:
Error: Too many levels of symbolic links
at: tools.lnx86/lib/64bit/libCadenceDSO.soCircular Symlinks in libCadenceDSO.so
Checked the file:
$ ls -la tools.lnx86/lib/64bit/libCadenceDSO.so
lrwxrwxrwx libCadenceDSO.so -> ../../DSO/lib/libCadenceDSO.soOK, it’s a symlink. Follow it:
$ ls -la tools.lnx86/DSO/lib/libCadenceDSO.so
lrwxrwxrwx libCadenceDSO.so -> ../../lib/64bit/libCadenceDSO.soThey point at each other. A -> B -> A -> B -> … forever. The base installer created this circular loop somehow — probably a timing issue where both symlinks got created before either real file existed.
The weird part: Virtuoso ran fine with these broken symlinks. The runtime must load the library from a different path or resolve it some other way. You only hit the problem when an installer tries to follow the chain and write an actual file.
Fix: Replace Circular Symlinks with the Real File
Remove both broken symlinks, extract the real libCadenceDSO.so (3.6MB) from the hotfix tarball, and place it in both locations:
# Kill the circular symlinks
rm tools.lnx86/lib/64bit/libCadenceDSO.so
rm tools.lnx86/DSO/lib/libCadenceDSO.so
# Extract real file from hotfix kit and put copies in both spots
zcat kits/dso64b25.10-s143lnx86.t.Z | \
tar -xf - ./tools.lnx86/lib/64bit/libCadenceDSO.so
cp tools.lnx86/lib/64bit/libCadenceDSO.so $CDSROOT/tools.lnx86/lib/64bit/
cp tools.lnx86/lib/64bit/libCadenceDSO.so $CDSROOT/tools.lnx86/DSO/lib/InstallScape Cannot Replace Directories with Symlinks (DSO/jre, DSO/jars)
Re-ran the installer after fixing the circular symlinks. Failed again, different error. This time the hotfix wanted to create symlinks where real directories already existed:
| HOTFIX WANTS SYMLINK | POINTS TO | BUT BASE HAS… |
|---|---|---|
DSO/jre | ../DSO_server/jre | Real directory (JRE files) |
DSO/jars | ../DSO_server/jars | Real directory (the DSO server JAR) |
DSO/optimizer/system/bin | target | Real directory (optimizer binaries) |
The base install ships full copies of these. The hotfix reorganizes them — moves the real files under DSO_server/ and replaces the originals with symlinks. But InstallScape can’t swap a directory for a symlink in-place.
Fix: Remove the Directories Before Running the Hotfix
rm -rf $CDSROOT/tools.lnx86/DSO/jre
rm -rf $CDSROOT/tools.lnx86/DSO/jars
rm -rf $CDSROOT/tools.lnx86/DSO/optimizer/system/binAfter that, the hotfix installed cleanly.
Complete Fix: All Steps Together
If your IC25.1 ISR4 hotfix install fails on the DSO component, do this before re-running InstallScape:
# 1. Break the circular symlinks
rm -f $CDSROOT/tools.lnx86/lib/64bit/libCadenceDSO.so
rm -f $CDSROOT/tools.lnx86/DSO/lib/libCadenceDSO.so
# 2. Extract and place the real library
zcat kits/dso64b25.10-s143lnx86.t.Z | \
tar -xf - ./tools.lnx86/lib/64bit/libCadenceDSO.so
cp tools.lnx86/lib/64bit/libCadenceDSO.so $CDSROOT/tools.lnx86/lib/64bit/
cp tools.lnx86/lib/64bit/libCadenceDSO.so $CDSROOT/tools.lnx86/DSO/lib/
# 3. Remove dirs that hotfix replaces with symlinks
rm -rf $CDSROOT/tools.lnx86/DSO/jre
rm -rf $CDSROOT/tools.lnx86/DSO/jars
rm -rf $CDSROOT/tools.lnx86/DSO/optimizer/system/bin
# 4. Re-run InstallScape hotfix installerTakeaways
- “License not found” can mean the software is asking for the wrong one. Run
stringson the.soor.classfile to see what it’s actually checking. Don’t assume the feature name is correct just because the error message looks authoritative. - Circular symlinks are sneaky. They look normal with
ls. The application may work fine around them. You only discover the loop when something tries to resolve the full chain — like an installer overwriting the target. - Read the hotfix kit manifest, not just the release notes. The ISR4 notes don’t mention the license fix. Listing the symlinks the kit wants to create (
tar -tvf ... | grep "^l") would’ve saved me a round-trip with the installer. - When an installer fails partway, check what it was trying to create, not just what it was trying to overwrite. The directory-to-symlink conflict is a different failure mode than the circular symlink — both block the same installer, for different reasons.
Environment
- Cadence Virtuoso IC25.1 base (IC25.1-64b.38, June 2025)
- Cadence Virtuoso IC25.1 ISR4 (IC25.1-64b.49, February 2026)
- Rocky Linux 9 / CentOS-compatible
- FlexLM license server with Virtuoso_Variation_Option (VVO)
Leave a Reply