fmuChecker.linux64 fails to recognize and read the FMUs that contain symbolic links in binaries
The zip by default converts the symbolic links to actual target files and deflates and stores.
Hence most of the time when zip -r destname.zip src_dir is called the symlinks in src_dir (/binaries/linux64) are replaced with the actual target files. Thus significantly increasing the size and redundancy in the contents
Whenever too many, and large binaries are involved the size difference becomes very pronounced. It is necessary that we allow symbolic links when libs in "binaries" are versioned.
I've attached a sample BouncingBallTestFMUs.zip with
a: BouncingBalls test fmu from fmi-cross-check
b: one with a symbolic link placed in "BouncingBallsWithSymlink/binaries/linux64" which was zipped with
cd BouncingBallsWithSymlink
zip -r --symlink BouncingBallsWithSymlink.fmu .
It results in following error
root@yoda:~/FMUChecker/build# ./fmuCheck.linux64 -n 5 -s 1 -l 1 -k me ./test-fmus/BouncingBallWithSymlink.fmu
"time","h","v"
[FATAL][FMICAPI] Could not load the DLL: /tmp/fmucktmpaZT8s2/binaries/linux64/BouncingBall.so: file too short
[FATAL][FMUCHK] Could not create the DLL loading mechanism(C-API) for ME.
FMU check summary:
FMU reported:
0 warning(s) and error(s)
Checker reported:
Warnings and non-critical errors were ignored (log level: FATAL)
2 Fatal error(s) occurred during processing
This would significantly reduce size of FMUs built with Julia, whose binaries consists of symlinks.
You can find a practical example of such fmus with and without symlinks here
fmuChecker.linux64
fails to recognize and read the FMUs that contain symbolic links in binariesThe
zip
by default converts the symbolic links to actual target files and deflates and stores. Hence most of the time whenzip -r destname.zip src_dir
is called the symlinks insrc_dir
(/binaries/linux64
) are replaced with the actual target files. Thus significantly increasing the size and redundancy in the contentsWhenever too many, and large binaries are involved the size difference becomes very pronounced. It is necessary that we allow symbolic links when libs in "binaries" are versioned.
I've attached a sample BouncingBallTestFMUs.zip with a: BouncingBalls test fmu from fmi-cross-check b: one with a symbolic link placed in "BouncingBallsWithSymlink/binaries/linux64" which was zipped with
It results in following error