Go to Post I'm not the programmer, thank god. - Veselin Kolev [more]
Home
Go Back   Chief Delphi > Technical > Programming > C/C++
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 15-01-2017, 00:42
Thomas DeSilva's Avatar
Thomas DeSilva Thomas DeSilva is offline
Programming Fury
FRC #1983 (Skunkworks)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Des Moines, WA
Posts: 22
Thomas DeSilva is on a distinguished road
libNiFpgaLv.so has wrong SONAME in ELF header?

I'm currently trying to get Google Test to work with a WPILib project so we can have tests integrated smoothly into our codebase (the rationale here could be a thread of its own, so let's not get into it). I've managed to get an executable compiled and linked, but I've been struggling to get the loader to cooperate. My procedure thus far:

1. Install qemu-user, the current FRC C++ toolchain, Eclipse, and the WPILib plugin on an Ubuntu machine.
2. Create a build configuration in Eclipse which links with both WPILib and gtest, with the test executable as the build artifact.
3. Build the executable.
4. Consolidate all relevant shared object files in one directory so that qemu's loader can find them.
5. Set up symlinks for the libraries that came with WPILib (the symlinks between different versions of libraries, e.g. libi2c.so -> libi2c.so.2, were created as regular files by the Eclipse plugin installer, so I wrote a script to remake them).
5. Run the executable using qemu-arm with a sufficiently large kernel version number and the loader path set to the directory containing the consolidated shared object files.

On the last step, qemu throws an error which reads, "src/eclipse/2017Steamworks/test/Test: error while loading shared libraries: libNiFpgaLv.so.13: cannot open shared object file: No such file or directory". I found it strange that it was trying to load that version of the library, as the one that WPILib comes with is 16.0.0, not 13. However, when I checked the ELF header of the library, I found that the SONAME doesn't match the filename:

Code:
$ readelf -d libNiFpgaLv.so.16.0.0 
Dynamic section at offset 0xc3a0 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libNiFpga.so.13]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libNiFpgaLv.so.13]
This also seems to be the case for some other NI libraries, like NiFpga and NiRioSrv. Is this intentional? How does the RoboRIO's loader handle this without having the same failure I am?
__________________
Programmer 2009-2011
Driver 2011
WPI Class of 2015

Last edited by Thomas DeSilva : 15-01-2017 at 00:52.
Reply With Quote
  #2   Spotlight this post!  
Unread 15-01-2017, 02:11
Peter Johnson Peter Johnson is offline
WPILib Developer
FRC #0294 (Beach Cities Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Redondo Beach, CA
Posts: 256
Peter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud ofPeter Johnson has much to be proud of
Re: libNiFpgaLv.so has wrong SONAME in ELF header?

Quote:
Originally Posted by Thomas DeSilva View Post
This also seems to be the case for some other NI libraries, like NiFpga and NiRioSrv. Is this intentional? How does the RoboRIO's loader handle this without having the same failure I am?
If you look in /usr/local/natinst/lib/ on the roboRIO, you'll find symlinks from the foo.13 versions to the foo.16.0.0 versions (e.g. libNiFpga.so.13 is symlinked to libNiFpga.so.16.0.0).
__________________
Author of cscore - WPILib CameraServer for 2017+
Author of ntcore - WPILib NetworkTables for 2016+
Creator of RobotPy - Python for FRC

2010 FRC World Champions (294, 67, 177)
2007 FTC World Champions (30, 74, 23)
2001 FRC National Champions (71, 294, 125, 365, 279)
Reply With Quote
  #3   Spotlight this post!  
Unread 15-01-2017, 02:19
Thomas DeSilva's Avatar
Thomas DeSilva Thomas DeSilva is offline
Programming Fury
FRC #1983 (Skunkworks)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Des Moines, WA
Posts: 22
Thomas DeSilva is on a distinguished road
Re: libNiFpgaLv.so has wrong SONAME in ELF header?

Quote:
Originally Posted by Peter Johnson View Post
If you look in /usr/local/natinst/lib/ on the roboRIO, you'll find symlinks from the foo.13 versions to the foo.16.0.0 versions (e.g. libNiFpga.so.13 is symlinked to libNiFpga.so.16.0.0).
Great, thanks. I'll have to poke around its file system on Monday and see if I can get this working.
__________________
Programmer 2009-2011
Driver 2011
WPI Class of 2015
Reply With Quote
  #4   Spotlight this post!  
Unread 15-01-2017, 11:01
codedr codedr is offline
Registered User
FRC #0537
Team Role: Mentor
 
Join Date: Mar 2010
Rookie Year: 2009
Location: Wisconsin
Posts: 71
codedr will become famous soon enoughcodedr will become famous soon enough
Re: libNiFpgaLv.so has wrong SONAME in ELF header?

It doesn't matter what the file name is, the runtime linker is going to want the library that the executable was built with that is embedded in the executable that calls itself libxxx.13.so by the name inbedded in the library file.

The name in the executable can be found with ldd or readelf.
Reply With Quote
  #5   Spotlight this post!  
Unread 17-01-2017, 00:00
Thomas DeSilva's Avatar
Thomas DeSilva Thomas DeSilva is offline
Programming Fury
FRC #1983 (Skunkworks)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Des Moines, WA
Posts: 22
Thomas DeSilva is on a distinguished road
Re: libNiFpgaLv.so has wrong SONAME in ELF header?

I moved all the libraries from the RoboRIO into my library search path, which solved the issue in my original post. However, now I have a different problem:
Code:
symbol lookup error: /lib/libHALAthena.so: undefined symbol: _ZN5nFPGA16nFRC_2017_17_0_220g_currentTargetClassE
I searched all of the libraries I have for this symbol and found it in libFRC_NetworkCommunicationLV.so.17.0.0, but libHALAthena.so doesn't require it:

Code:
$ readelf -dW /usr/arm-frc-linux-gnueabi/lib/libHALAthena.so

Dynamic section at offset 0x42434 contains 37 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libFRC_NetworkCommunication.so.17]
 0x00000001 (NEEDED)                     Shared library: [libi2c.so.2]
 0x00000001 (NEEDED)                     Shared library: [libRoboRIO_FRC_ChipObject.so.17]
 0x00000001 (NEEDED)                     Shared library: [libspi.so.1]
 0x00000001 (NEEDED)                     Shared library: [libvisa.so]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libMathParser_gcc-4.4-arm_v3_0_NI.so]
 0x00000001 (NEEDED)                     Shared library: [libwpiutil.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libHALAthena.so]
Code:
$ readelf -sW wpilib/cpp/current/lib/libFRC_NetworkCommunication.so.17.0.0 | grep FPGA
    37: 00066948    41 OBJECT  WEAK   DEFAULT   12 _ZTS38NetCommRPC_getFPGAHardwareVersion_args
    45: 00067198    42 OBJECT  WEAK   DEFAULT   12 _ZTS39NetCommRPC_getFPGAHardwareVersion_pargs
    48: 0007ce80     8 OBJECT  WEAK   DEFAULT   18 _ZTI40NetCommRPC_getFPGAHardwareVersion_result
   233: 0006716c    44 OBJECT  WEAK   DEFAULT   12 _ZTS41NetCommRPC_getFPGAHardwareVersion_presult
   314: 0007ce68     8 OBJECT  WEAK   DEFAULT   18 _ZTI38NetCommRPC_getFPGAHardwareVersion_args
   317: 00066974    43 OBJECT  WEAK   DEFAULT   12 _ZTS40NetCommRPC_getFPGAHardwareVersion_result
   339: 0000d098    32 FUNC    GLOBAL DEFAULT   10 getFPGAHardwareVersion
   432: 0007d348     8 OBJECT  WEAK   DEFAULT   18 _ZTI39NetCommRPC_getFPGAHardwareVersion_pargs
   440: 0007c240     8 OBJECT  WEAK   DEFAULT   18 _ZTI11FPGAVersion
   449: 000657f0    14 OBJECT  WEAK   DEFAULT   12 _ZTS11FPGAVersion
   537: 0007d330     8 OBJECT  WEAK   DEFAULT   18 _ZTI41NetCommRPC_getFPGAHardwareVersion_presult

$ readelf -sW wpilib/cpp/current/lib/libFRC_NetworkCommunicationLV.so.17.0.0 | grep FPGA
     3: 00000000     0 OBJECT  GLOBAL DEFAULT  UND _ZN5nFPGA16nFRC_2017_17_0_220g_currentTargetClassE
__________________
Programmer 2009-2011
Driver 2011
WPI Class of 2015
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 13:59.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi