Broken aliases and missing "static.macosclangrelease" files.

[RosettaRosettaRosettaRosetta]

I'm using a Mac, and used clang to compile. Am a newbie to Rosetta, so apologies in advance if any terminology is wrong or inaccurate.

I was unable to use a static.macosclangrelease file due to the file being 'not found'. Upon closer inspection, every one of the bin/ aliases point to something like this "zinc_statistic_generator.static.macosclangrelease -> ../build/src/release/macos/12.6/64/x86/clang/14.0/static/zinc_statistic_generator.static.macosclangrelease".

The first issue is that this pathway doesn't exist, and searching through my files my pathway is closer to "/build/src/release/macos/15.2/64/arm/clang/16.0/default". The Mac and Clang version seem to be wrong, not to mention the 'default' instead of 'static'. It seems like all the aliases are linked to the wrong place.

The second issue is that within my directory itself, I can't find the any ".static.macosclangrelease" files, and I'm not sure if this is normal. All the files are in .os format, so even if I manually changed where the aliases are pointing to, I can't find the corresponding .static.macosclangrelease file to point it too.

I tried scons -c and recompile everything, but even though the compilation seems successful, it isn't working.

[roccomoretti]

The normal compilation commands don't produce the static versions, but rather default. (You'll need to include the extras=static directive to get those.) In the pre-compiled downloaded version, we distribute things as static for maximum compatibility across systems, but that's not necessarily something you'd need to do if you're compiling on the same system you're running on. But the naming conventions will be different, with the files in the bin directory being *.default.macosclangrelease (or just simply *.macosclangrelease. -- The *.default.macosclangrelease and *.static.macosclangrelease versions of Rosetta applications should function identically. The default/static difference is just due to technicalities of how the executables are loaded by the system, but shouldn't change which code actually gets run.

If I had to guess, you downloaded the pre-compiled version, which should have both the *.static.macosclangrelease symlinks in the bin directory as well as the corresponding files in the build directory. However, in the process of recompiling you cleared out the build directory (but not the bin directory), leaving the *.static.macosclangrelease symlinks being dangling. You compilation created a new set of files in the build directory, but at a different location due to the different OS & compiler versions, as well as being a default compile rather than a static one. Hopefully it generated some *.default.macosclangrelease links in the bin directory.

The compilation process should automatically make the symlinks from the build/ directory into the bin/ directory. If that didn't work properly, I'm not sure what the issue is with compilation. -- For debugging compilation issues, it's often best to repeat the scons command. It should "pick up where it left off", and whatever error messages that are causing issues should be more obvious in a smaller log file.

In either case, deleting the bin/ directory (to clean up the now-dangling *.static.macosclangrelease symlinks) and then re-running the scons command should help clean things up. You'll either get new *.default.macosclangrelease symlinks in the bin directory, or you'll get an error message about what went wrong with the compilation.

One final note: there might be issues with symlinks depending on the type of filesystem you're putting Rosetta on. There shouldn't be an issue with native Mac & Unix filesystems, but Windows filesystems (e.g. FAT and NTFS) may have issues with symlinks. If you're putting Rosetta on a shared filesystem, that might potentially be contributing to issues.