Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1 occurred at System Exec while building Shared Object

Hello,

I am using 64-bits Linux SuSe 11.1 and 32-bits Linux 2009 Labview.

I am trying to build a Shared Object using a VI which is a simple VI used to do addition of two numbers.

When I build the Shared Object, I get the following error:
"Error 1 occurred at System Exec: /usr/local/lib/liblvrt.so.9.0: could not read symbols: File in wrong format
collect2: ld returned 1 exit status "

Please advise what can be done.

Thank you.

Regards,

H.

0 Kudos
Message 1 of 20
(8,794 Views)

Sorry for such an almost trivial question, but are you running the 64 bits computer in 32 bits compatibility mode?

0 Kudos
Message 2 of 20
(5,414 Views)

Hello,

Pardon me, but I do not know if there is a compatibility mode. Is there a way I can make sure? My guess is that LV links to 32 bit libraries while installing.

When I installed LabView, it installed successfully and all other Vis work fine, except for building Shared object or importing Shared object.

Thank you.

-H

0 Kudos
Message 3 of 20
(5,415 Views)

HP,

If you are running on a 64-bit OS, then the gcc for your machine will also be 64-bit. This means that when the LabVIEW Shared Object File is built, it will be 64-bit. Then, it is trying to link to the 32-bit Run-Time Engine and failing. To solve this issue you somehow need to get gcc and ld to run in 32-bit mode and make sure that whatever parameters that need to make that happen are in a shortcut named gcc that is found in the path before the current gcc.

Randy Hoskin

LabVIEW for Linux

0 Kudos
Message 4 of 20
(5,415 Views)

Also, everything else that is linked to the SO file needs to be 32-bit as well. That may be harder than it sounds.

I would suggest using a native 32-bit OS for running LabVIEW for Linux.

Randy Hoskin

LabVIEW for Linux

0 Kudos
Message 5 of 20
(5,415 Views)

Hey Randy,

That sounds like a bug in the Application builder to me.  I would expect 32-bit LabVIEW to realize that it is running on 64-bit Linux and pass the appropriate options to gcc.

In this case making a wrapper script and adding it to your path may fix the problem.  Try something like:

echo "gcc -m32 $@" > ~/bin/gcc

chmod +x ~/bin/gcc

export PATH=$HOME/bin:$PATH

labview

--

Shawn

Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 6 of 20
(5,412 Views)

I'm running Opensuse 11.1 64-bit and Labview 2009 without problems.  I can't recall if I had to link any libraries initially but everything works.  Sorry I don't have a solution, I just wanted to comment that 32-bit Labview runs properly under 64-bit Opensuse.  Maybe one day we won't be having this conversation as there will be a native 64-bit Labview for Linux.

0 Kudos
Message 7 of 20
(5,415 Views)

RandyH wrote:

Also, everything else that is linked to the SO file needs to be 32-bit as well. That may be harder than it sounds.

Why is that hard?  Assuming the SO file will be accessed from C/C++ you simply need to build your project by passing -m32 to gcc.  Now I suppose the goal may be to access the SO from a scripting language like python or perl, which may make it more difficult.

--

Shawn

Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 8 of 20
(5,412 Views)

Jeff,

Have you tried building a Shared object from a VI or tried to import a Shared object into a VI. Do they work fine for you? I have been trying that since quite some time now, but it always gives me an error. I have started with a VI as simple as Adding two numeric values.

-H

0 Kudos
Message 9 of 20
(5,415 Views)

Shawn,

I guess it was not since you proved it in 4 lines. I was more concerned about how the library was going to be used. Normally, they would build a LabVIEW build SO for using with other C/C++ programs. The user would then also need to make sure that thier program is also 32-bit. This may or may not be possible. They are running 64-bit for a reason.

Anyway, thanks for chiming in and correcting me. You were always better with gcc instantiations.

Randy Hoskin

0 Kudos
Message 10 of 20
(5,412 Views)