caraya
caraya copied to clipboard
vipm-io
Bad Linkage with some tests on latest release
It's late and I've been battling this for hours now, but when I run Caraya on my project I get a slew of Bad Linkage errors.
This starts with v1.2, 1.1 works fine
I can provide more details if you can't reproduce.
@tannerblair, any hint about which VI is wrongly linked would help. I've personally not seen this happen, neither did my colleagues who installed 1.2 in recent months.
I am also getting this quite a lot, I have only just started using Caraya so not sure whether it is the same issue as tannerblair or just user error on my part.
For me it seems to be that the Linker.Read Info From File invoke node in ReadLinkerInfo is generating an error when something in the My Computer target is targeting something in the RT directory. It looks like this is causing LabVIEW to look in the wrong vi.lib directory
This is the case even though the VI under test doesn't appear to be referencing this item at all. I do have a broken dependency for this type def in the My Computer target and am currently trying to work out why it is there.
it would be good if the results viewer could give a little more information as to what is causing this error as I have to dig through all your source code to find the cause.
@Niatross Could you provide an example project that reproduces this issue?
I assume you have a project with both MyComputer and a RT target. The VI reportedly broken is usually put in a disabled structure when called from the non-RT target. Could it be on there for the linker to find? If the VI is found in the dependencies on the non-RT target, it will be referenced as broken even though it is in a conditional disable structure. If that's the case, that might inform on what to do to ignore it and continue reading linker info.
I would be surprised if the linker were to find a VI not in the application instance it is running in.
I am currently trying to create the smallest project which displays this issue but am struggling as the issue doesn't appear to be consistent. By not consistent I seem to make changes totally unrelated to my failing test and it starts working again (I have been living with this issue since I first started using Caraya)
I assume you have a project with both MyComputer and a RT target.
Correct
The VI reportedly broken is usually put in a disabled structure when called from the non-RT target. Could it be on there for the linker to find?
Yes, it is in a CDS which disables it when the target is Windows. This is in a totally unrelated file though which isn't actually in the My Computer target though, I have currently been able to get it out of my dependencies at the moment. I suspect it is there because once upon a time I had the cluster output from RT CPU Loads in a type def used on My Computer. I disconnected this type def a while ago though (I am going to try reverting to a version before this in a minute)
I would be surprised if the linker were to find a VI not in the application instance it is running in.
So would I. Still investigating why it is in My Dependencies.
I am starting to think this might be because I structure my projects using libraries. This is something that I am going to move away from because on a multi target project it has the annoying side effect of the other target adding the entire library as a dependency the moment one item in the library is used. I suspect that the VI which actually uses RT GET CPU Loads on the RT target is being pulled in as a dependency on My Computer because something in library is being used by something in My Comptuer
Please check out this pre-released version (1.4.0 RC1) that you can download from the release page. I'd appreciate if it could be confirmed or infirmed.
1.4.0 RC1 https://github.com/JKISoftware/Caraya/discussions/172
(Not yet released on VIPM Community.)