Jump to content
Daklu

Package build fails with error 13

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.