RT Package build spec doesn't keep symbolic link

[Bas.v.E]

I've build a library for RT Linux which consist of a few .so files with symbolic links to other files in the same directory, and I want to easily distribute this library over different machines. So I thought, this is a good way to test the package build spec in LabVIEW. So I've created the build spec under my RT target, added the folders where I want my library to extract to and added all the files in LabVIEW.

When I look in the buildspec I see that the files are shortcuts so they still have the symbolic link. They are also the same size as the originals so I know these are the same files as on my build system. 

 

So after building the package I transfer the .ipk file to my target and run as admin

opkg install hdf5lib_1.0.0-0_x64

I see that the package is succesfully installed, but when I browse to the destination folder, I see that all the symbolic link files have been changed to match the size of the original .so file. This also means that ldconfig gets errors and I cannot use my library. I've seen this before on copy actions with libraries and I know that this happens when a copy command like cp does not have the argument -a attached to it.

Is it possible to give source files in a package a little bit more control over the way they are copied to their new location so you can keep symbolic links, permissions, modification times and other metadata?

[cbutcher]

Although I can think of at least two reasons why this isn't great, you might be able to:

1. Remove all symbolic links from your source (reason 1 - you might have those being generated in some build process, and retroactively or post-build removal might be annoying)
2. Write a post-install action to create all of these symlinks (reason 2 - on a Windows LabVIEW setup I have the option to add executable files - ".exe, .bat, .cmd". If you're trying to build these to be installed on a Linux system, you might struggle to get something that can be run cross-platfom (but maybe you can have a "createSymlinks.bat" to satisfy the creation tool and a "createSymlinks.sh" and hope that it's run by name and not path?)
   • When I create a Package build spec under a cRIO rather than My Computer target, the Custom Action filetype is .sh 🙂 )

Alternatively, you can probably do this by using the command line nipkg.exe to build a package after you structure it yourself, but I guess from your text you're intentionally trying to use the Build Spec option, so this isn't really the goal...

[Bas.v.E]

So I've investigated a bit more, but I have to correct myself, the moment the package is created in LabVIEW it loses it's symbolic link, so It doesn't have anything to do with the way the .ipk is installed. So for now, the only option I have left is to tar the files, add that tar.gz file to my package, and create an .sh script to untar it in the correct location and after that remove the tar file. but this defeats the a part of the purpose of letting you create a package for the opkg packagemanager within LabVIEW.