Jump to content

Martijn

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Further looking into this problem, it seems to occur whenever the CLN call as specified in the VI is invalid on the target machine at the time of install. Simplest breaking case is a CLN referencing a 32-bit DLL. Install on LabVIEW 32-bit and the path resolves. Install on 64-bit LabVIEW and the path is the DLL in the original development directory but with a "." before the parent directory name. In the case when platform independent *.* notation is used, any asterisks for platform independence are removed, leaving just an invalid DLL path as observed after installing on linux which somewhat surprised me above. This seems like undesirable behaviour regarding packing CLNs when you're targeting multiple distributions - particularly if you want to compile the library on the target OS. I intend to use VI scripting to rename all the CLN calls after install, but I figure this behaviour should be documented somewhere.
  2. Updating to 2012.0.1 (build 1818) has fixed the bug insofar as clicking the "Generate VI" button produces the "upgrade" dialog box (which is incorrectly positioned as being centred on the top-left corner of my screen - at least I can still click "cancel"!) but I cannot remove the existing VI. I feel like removing it should be an option since it only got there by a bug in the first place.
  3. There appears to be a bug regarding Custom Actions in VIPM 2012 community (build 1780), whereby I can add as Post-Build Action by clicking the "Generate" button but cannot remove it, because when I try to remove it it complains that the free version does not include Pre/Post-Build actions. I expect the intention is not to let me create the action at all, but not letting me remove it is annoying. Since I can't edit the file manually (signature mismatch) how can I get rid of it? I'd really really rather not remake the package file from scratch.
  4. Hi all, I'm packaging a library that makes calls via a Call Library Node (CLN) to a shared library. On Windows this is to a DLL and works fine - the installed packages have their library paths changed to match the location of the installed DLL. The development path looks like is C:\dev\projs\labview\...\library.* which gets changed to C:\Program Files\National Instruments\...\library.* as expected. However, when installed with VIPM under linux, it turns into /C/dev/projs/labview/.../library.dll - the path separator has changed but the path is meaningless. I had expected the same behaviour under Linux - that the path would transform to the appropriate vi.lib location. Should that be happening, or do I need to implement VI scripting code to change it as a post-install VI? Cheers, Martijn PS This question is related to my earlier question about building shared libraries but I considered it sufficiently different to warrant a separate topic. Hopefully once this issue is solved I will be able to finish that procedure and update you all on the results.
  5. Actually, I presume the lib*.* convention works the same on all platforms so I suppose I could distribute cross-compiled versions for each permutation. It will probably work but it'd be nice to get a Post Install Action to do it for me
  6. Hi Jim, Looks like the Post Install Action is indeed what I want. The logic I've gone with is the check the "Files Installed" attribute for the source file to be compiled, and if found, use that path to execute the gcc call in the correct directory. My initial attempt used "Folders Created" to get the base dir but this did not seem to work when upgrading a package because I'm guessing the folders themselves are not recreated, but I think this works much better. I am indeed using the .* convention of the CLN to pick the relevant library, which seems pretty convenient. I was just wondering if there were any unintended side-effects I should be aware of using this on other platforms than Windows. In particular I'm not clear on how it distinguishes 32/64-bit on Linux. Sadly I do not have a Linux license so I can't directly test myself. Cheers, Martijn
  7. Hi all, I'm using VIPM to distribute a package that adds functionality to LabVIEW via a C library. This works fine under Windows as I simply distribute 32- and a 64-bit pre-compiled versions of the DLL in the package and get LabVIEW to load which one it prefers at runtime. I want to expand to Linux support, in which case the analog is a shared library, but then pre-compilation is undesirable and it would be better to create the library at install time. I'd imagine the correct thing to do in this situation is to create a post-install VI script to run GCC and compile the source for the host machine; has anyone done this before? Cheers, Martijn
  8. Hi there, I'm trying to install the VI Package Manager, but for some reason when I get to the installing stage, the installer disappears without quitting - leaving me with an occupied prompt. The thing that is perplexing me is that there are no error messages, or messages of any kind produced - I just click install and the window vanishes. It creates the installation directory but it remains empty, so there are no log files there. I found some logs in /tmp and I found one that seems to apply: LabVIEW_Failure_Log.root.txt: #### #Date: Tue, Jun 02, 2009 08:36:18 PM #Desc: LabVIEW caught fatal signal 8.2.1 - Received SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x12d50c14 #RCS: unspecified #OSName: Linux #OSVers: 2.6.24-23-generic #AppName: /tmp/lvtemp298dir/installer #Version: 8.2.1 #AppKind: AppLib All other log files that might apply (installer_8.2.1_root_cur.txt, installer_8.2.1_root_log.txt, vipm-2.0.3-linux_8.2.1_root_cur.txt, vipm-2.0.3-linux_8.2.1_root_log.txt in /tmp) all contain essentially the same thing: #### #Date: Tue, Jun 02, 2009 08:36:09 PM #OSName: Linux #OSVers: 2.6.24-23-generic #AppName: ./vipm-2.0.3-linux #Version: 8.2.1 #AppKind: AppLib and nothing after that. Seems like it could be a LabVIEW runtime problem, but I thought I'd check here first. Best find I could find regarding a LV SIGSEGV is at http://digital.ni.com/public.nsf/allkb/A2D...6256EBD005B31D2 (or forum posts pointing there) whose solution does not work. Am I barking up the right tree? Should I try hassling NI about it? Oh, and I'm running Ubuntu 8.04.2 with LabVIEW runtime 8.2.1 (downloaded and installed this evening). Any advice for further debug would be appreciated. Cheers, Martijn
×
×
  • Create New...

Important Information

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