LabVIEW
Identifying the official (or supported) gcc version for a given Labview version
Solved!
Thanks for the information Guillaume! 
While it shows that the OP was wrong about NI not documenting what libstdc++ versions LabVIEW requires (which is the really important part, not the gcc compiler version used to create it) there is one information that can be a little misleading to casual users. Your first link references the online help about CIN code resource creation which has been a legacy technology in LabVIEW since at least version 7 and should in the meantime be considered obsolete. The status with CINs at this point is that they do simply not work in RT targets and all 64 bit targets of LabVIEW and support for creating them has been basically removed since at least LabVIEW 2009.
Technically the information presented in that online help is equally valid for the creation of DLLs/shared libraries that want to link to the LabVIEW manager API functions but CINs shouldn't be mentioned there anymore. For DLLs/shared libraries not interfacing to LabVIEW manager functions (so DLLs/shared libraries that were not specifically written to interface to LabVIEW) the binary compatibility of the calling application and the shared library is only really important if you happen to want to pass runtime objects from one to the other (creating file handles/descriptors in one and operating on them from the other, or memory pointers created in one and resized and/or freed in the other as an example). Potentially there are more and other complications on Linux with binary compatibility with shared libraries but for Windows that at least are the limitations.
The problem about having to have the right gcc version stems from the fact that under Linux the standard operation is to install whatever GCC version your fancy strikes you and recompile all the applications from source when problems arise. That obviously doesn't work for closed source applications and the strength of the open source environment gets its weakness here. Otherwise the GCC developers would have spend more time to make sure that different shared library binary versions in the same process can more easily coexist. It may even be intentional to not make it easier as a sort of finger pointing and shaming at closed source applications. However reality here is that LabVIEW for Linux is more likely to be discontinued than that NI makes it open source! Not saying here NI will discontinue it, they have no interest at all to do that, but if forced to make the decision to discontue or go open source I'm 100% sure of the outcome
@nl-soleil wrote:
Guillaume,
Touché 🙂 I finally obtained the info I was looking for. Thanks for that. I tried almost all keywords searching NI web site - without success, cause my search was gcc (i.e. supported compiler) oriented.
Rolf,
Right, the stdlibc++ is the important part of the problem. However the gcc version tells you what stdlibc++ it comes with. So it still makes sense to determine which gcc version you need to compile your shared lib for a particular LV version. Anyway, thanks for reply. It contains very useful info.
Unless you do not work with a standard GCC installation. Probably not an issue for most normal users and those who thinkered with non-standard stdlibc++ and other libraries support inside a GCC developer toolchain most likely know better about this than you and me together. 
@nl-soleil wrote:
BTW, I found an interesting announcement googling the web about labVIEW and Linux.
That was specifically for LabVIEW 2014. This was the first version to support a native 64 Bit Linux version (and 64 Bit MacOS X) and yes CERN was probably one of the driving forces behind this. The other was support for their x86 based NI Linux RT targets. Both these things will make sure that LabVIEW for Linux is not going to disappear quickly from this globe, but Linux will remain one of the several other supported LabVIEW platforms with LabVIEW for Windows making still a larger dent into the pocket than all the others together.
But strategically LabVIEW for Linux remains important for NI and got even more important since the NI Linux RT targets appeared. The only problem with customers like CERN is that they are using so much non-standard hardware that they are writing their own interface drivers anyways, so they are not such a strategic force to drive support for DAQmx or other drivers for the Linux platform. And device driver development is to much platform specific that NI Linux RT drivers could simply be taken to desktop Linux.
