Package build fails with error 13

[Daklu]

I'm attempting to build a package from a project that contains two libraries, each of which has 3-4 classes. It also includes a handful of dlls, two of which are .Net assemblies and referenced by the classes. The other dlls are support files the assemblies depend on.

 

If I attempt to include either of the libraries in the build it fails. Excluding the libraries but building with just the dlls works, but of course isn't very useful to me. The libraries and classes don't do anything particularly special.

 

I've attached the associated error file. Let me know if you want to look at source code. I can't post it publicly but we could make arrangements to transfer it via email or secure ftp.

 

-Dave

October_06_2010.txt

[Jim Kring]

I'm attempting to build a package from a project that contains two libraries, each of which has 3-4 classes. It also includes a handful of dlls, two of which are .Net assemblies and referenced by the classes. The other dlls are support files the assemblies depend on.

 

If I attempt to include either of the libraries in the build it fails. Excluding the libraries but building with just the dlls works, but of course isn't very useful to me. The libraries and classes don't do anything particularly special.

 

I've attached the associated error file. Let me know if you want to look at source code. I can't post it publicly but we could make arrangements to transfer it via email or secure ftp.

 

-Dave

 

Hi Dave,

 

Yes, please upload your code to us -- I've sent you instructions, off-line -- and I'll take a look at the problem. From your description and the error log, I've got some ideas about the nature of the problem.

 

Thanks,

 

-Jim

[vugie]

Hi

I have exactly the same problem. I want to build package of lvlib with number of classes referring to total of two DLLs. To one of this DLLs I refer directly, to second one not only directly, but also by getting function addresses using kernel32.dll calls.

The error log is essentially the same as Dave's one.

[Jim Kring]

Hi

I have exactly the same problem. I want to build package of lvlib with number of classes referring to total of two DLLs. To one of this DLLs I refer directly, to second one not only directly, but also by getting function addresses using kernel32.dll calls.

The error log is essentially the same as Dave's one.

 

I'm very curious to dig into this and see what's the matter. We'll definitely need to reproduce the issue on our system, to see what's wrong. Can you post (or send us off-line) an example of a VI Package project that shows this problem?

 

Thanks,

 

-Jim

[vugie]

I'm very curious to dig into this and see what's the matter. We'll definitely need to reproduce the issue on our system, to see what's wrong. Can you post (or send us off-line) an example of a VI Package project that shows this problem?

 

I wanted to make a package of lvODE library I just published on LAVA. Here is the link for source: http://lavag.org/files/file/155-lvode-01-lv2009/, VIPB file is attached below.

.vipb

[Jim Kring]

Thanks! I'll check it out.

[Jim Kring]

Guys,

 

I'm pretty sure I've found and fixed the issue.

 

I've attached a fixed version of ogb.llb that you can put inside the "support" folder of the VIPM installation directory (make a backup of the original first, in case you run into problems and need to revert to the original). Please try this out and let me know if your builds work.

 

 

ogb.llb.zip

 

 

It turns out this this is a bug that affects building packages that contain both a DLL and an LVLib that contains an LVClass (talk about a corner case).

 

Cheers,

 

-Jim

[vugie]

I'm pretty sure I've found and fixed the issue.

...

 

Thanks, works and sings. What was the direct reason? The case with lvclass in lvlib is definitely sth LabVIEW does not like (vide issue with palettes).

 

So, only LAVA is not working as for now... Oh no, not again!

[Jim Kring]

Thanks, works and sings. What was the direct reason? The case with lvclass in lvlib is definitely sth LabVIEW does not like (vide issue with palettes).

 

So, only LAVA is not working as for now... Oh no, not again!

 

Well, since you asked... the issue is that the "Write Linker Info" Application Method (it's a private one) does not like it when you pass in a path to Class Private Data (which appears as a VI/CTL in memory with a virtual Path value like "C:\MyProject\MyClass.lvclass\MyClass.ctl" -- the Class Private Data is not actually a file on disk). So, before we call Write Linker Info, we filter the Class Private Data from the list of paths. However, our Class Private Data detector was not handling the situation where an LVClass was inside an LVLib -- this was making the VI.Name attribute of the Class Private Data look something like "OuterLibrary.lvlib:MyClass.lvclass:MyClass.ctl", when our parser/detector was looking for something like "MyClass.lvclass:MyClass.ctl". When a package is built, the "Write Linker Info" method is only being called when there are additional resource files, like DLLs, present in the VI package (since we move these on disk, rather than using VI Server Save Instrument, like we do for VIs). The end result is that this bug only shows up when a VI Package includes a DLL and an LVLib that contains an LVClass.

[Michael Aivaliotis]

This issue is fixed in the current public release of VIPM.