Showing results for 
Search instead for 
Did you mean: 

LabVIEW NXG 4.0 GLL - How to use them?

Go to solution

I saw NXG 4.0 supports building libraries into GLLs so gave it a quick shot, but I can't find any info about using the GLLs in any useful way. I can build them...but that's about it.


  • There is no way (I could find) to build a standalone GLL. They are only built when an application is built.
  • Conversely, there's no way NOT to build a library into a GLL when building an application. If I use libraries to organise my code, they will be compiled into GLLs. This creates a bit of a mess on disk (each GLL gets it's own top level folder, containing a single GLL). Can libraries not be statically built and included in the executable?
  • A compiled GLL can not be replaced with an updated build version, or even an identical recompiled version. The calling application will throw an error (-4503) when it's loading the GLL. So although it's being dynamically loaded, it has to be the exact file compiled with the application. This kinda defeats the primary use case for dynamic loading.
    • gll_fail.png
  • I can't find any way of calling code in a pre-existing GLL. GLLs don't seem to be supported in the NXG project.
    • gll_file_type.png
  • If I have a project with two applications referencing the same library, then build each application, they don't share a single GLL. Instead they get their own built versions of the GLL. If I move the GLLs on disk, maintaining the necessary relative paths, the GLL can't be shared due to error -4503 above.


Is there any way to use a GLL, beyond being a bit of extra compiler output?

Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 1 of 8
Accepted by topic author MichaelBalzer

Hello Michael,

Thanks for the feedback! You are correct in your analysis of the situation. In the LabVIEW NXG 4.0 release, the GLLs don't do too much. I wanted to share our reasoning for this, and give you a heads up to some things that are coming down the pipeline.

We wanted to get people comfortable with the concept of how we build components, and how these built components (i.e. GLLs) compose the binary output of your applications. Components are the main organizational tool in LabVIEW NXG, and having desktop libraries compile into GLLs is a continuation of that theme.

There are still "source components," just not as a build option. You can always take a .gcomp directory and give that to somebody else or use it in a separate project. But for the notion of what happens on build on the desktop, right now we will always build these into GLLs. We do have on our long-term backlog an option for creating a monolithic EXE, but we will not get to that any time in the near future. The capabilities that GLL will soon provide were higher on the list of requirements for the customers we have spoken to than monolithic EXEs.

On the subject of those GLL capabilities, the team is currently hard at work on patching individual GLLs (and thus being able to build GLLs individually) as well as the ability to load a GLL dynamically from your built app. 

I am excited to see these features get out the door. Our general approach has been to get smaller increments of functionality out the door more often, so stay tuned for the next LabVIEW NXG release!



Message 2 of 8

Thanks for the detailed response, Taylor. I was hoping for a PPL / LVLIBP replacement when I saw GLLs were included in NXG 4.0, and it sounds like they will be in a future release.


A monolithic exe isn't high on my requirements list either, but would be a nice to have. A key feature I'd like to see (and I'm sure many others) for GLLs would be around plugin architectures. Not just the ability to create them, but a much simpler workflow for code creation. Right now with PPLs and LVLIBPs, it means juggling several projects in and out of memory so libraries don't get locked, or have build errors. Multiple projects also exacerbates any code refactoring amongst PPLs and their dependencies. If and when this can all be done from a single project in NXG, I'll happily switch!

Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
Message 3 of 8

So you'll be glad to know that we have drastically simplified the workflows around creating GLLs and using them as plugins. No more separate projects for each PPL. As we get close to releasing this, I'll be able to share more details on the specifics of the workflows, but I hope that you will be pleased!

Message 4 of 8

I was considering using NXG for GLLs that can actually work like real plugins.  When is it planned to be released?  It doesn't look like its in the next version after 4.0, according to the roadmap.  Does that mean next year?

0 Kudos
Message 5 of 8

GLLs as plugins will be supported in the upcoming release of LabVIEW NXG. You will only be able to dynamically instance VIs, not classes at this time. Classes are still on the near term roadmap as we understand the importance of dynamic instances of classes for test system development. We do support dynamically getting references to VIs that have classes on their connector pane, however.


If you sign up for the 5.0 beta you can see GLL plugins in action now.

Message 6 of 8

Hi Taylor_R.


I am using NXG 5.0 now and I am also trying to to make usage of GLLs.


It seems like compiling a GCOMP makes no effect on the way I build my LVdist as a package, in particular whether or not I check "protect diagrams when built" the code always get exposed and editable, If do not chose as a G pallet in Addons it shows as a link only , not as dependency of the other project, and do not get distributed when compiled.


I need to create the equivalent of a .lvlibp in LV CG to distribute to my colleagues, but the only option that seems to work is when I configure the LVdist to deploy in the NXG Addons folder + creating a G pallet file: as recommended here, therefore, it offers to save As.. if I want to save modifications on the other machine, and it is going to pollute people pallets very quickly.


Can I create a single compiled version of my code (less files the better), that is an API style, and give only that file to other developer integrate on his code? I am planing to integrate some modules on TestStand also, as a finalized standalone: any recommendation?





Download All
0 Kudos
Message 7 of 8

Hey Luis,


In general the distribution document (.lvdist) is used for packaging up code in NIPM packages.  Depending on what kind of code that is included in the package we will perform different build steps / modifications to the code.  In the case of a library (gcomp configured as library) there are two possible options, distributing as an "addon" or just distributing the source.  If the library is installed to the public addons folder, <LabVIEW NXG install>/Addons, then we assume this library is a reusable library that should be available to any projects that are using that version of NXG.  We create some additional files that help with performance in addition to including the original source.  If any other folder is selected to install, we will treat the library as just source and only include the source itself.


As you noticed, libraries in the public addons folder behave differently than source that is included directly in the project.  It is similar to the concept of vi.lib in LabVIEW because any projects created will have access to VIs in the addons folder.  The main difference is that all content in the addons folder is treated as read-only.  If someone wants to modify the VIs in that folder we need to duplicate the library into the project to make an editable copy.  This way changes to the addons content only affects the project that wanted to make modifications.  I think you can use the addon concept to create a library that is distributed to other developers.  It sounded like one of the main pain points with the addon concept was duplication of the code when changes needed to be made.  In general, if you make changes to the library, are those changes that would need to be distributed to all machines?  Or is it common to make localized changes on just one machine?  The idea with the addon concept was that if you made changes those changes would want to be pushed out.  For example, with a bug fix, you would create a new version of the addon and push it out so that people get the latest.  Also on the issue with the duplication of the palette, that behavior is a bug.  We shouldn't have a duplicated palette for an addon that has created a local project copy.


I'm guessing since this is in a post about GLLs, you were hoping/asking if there was a way to distribute a GLL that could be used in the editor similar to an lvlibp.  Unfortunately we don't have the ability to do that.  GLLs are only available for use with LabVIEW NXG built applications right now.





Pat P.
Software Engineer
National Instruments
0 Kudos
Message 8 of 8