Unsure about /usr/lib vs /usr/local/lib when building packages

[tpc1095]

We are porting "suricata" to the cRIO-9033 and ended up downloading the source for roughly 10 different packages as .tar.gz files. We went through the usual exercise of ./configure, make, make install and the resulting image has a segmentation violation. When we looked closer, we discovered that we have packages with the same name in both /usr/lib and /usr/local/lib as well as the corresponding include directories.

We we supposed to do this?

./configure --prefix=/usr

[BradM]

First, /usr/local is correct and sane for source that you've downloaded, configured, built, and installed locally. That's what the directory is meant for. It is not the source of the segfault.

Now, as for the actual problem at hand, an issue that I've seen a few people run into that results in this mysterious segfault is the somewhat stingy process stack allotment the distribution uses as the default for all processes (basically, the process has a sufficiently deep call stack).

Basically, one thing to check would be to set the stack limit[1] from the shell/terminal that you run the resulting program (suricata) before running the program.

ulimit -s unlimited

suricata

[1] http://ss64.com/bash/ulimit.html

[tpc1095]

Hi Brad,

We'll try the "ulimit" command right after we restore our cRIO-9033 to be able to boot int RT-Linux mode. My colleague decided to try deleting and restoring parts of /usr/lib from a backup directory (from before we started this task) to try and get rid of some duplicates with what is now in /usr/local/lib and now the 9033 boots only far enough to see the LabVIEW background image.

If I uninstall then install LabVIEW Real-Time 14.0.1 will this put us back at least as far as being able to boot again? While we have backups, it would be very nice if a re-install would leave the user directories for admin and lvuser alone.

Tim

[BradM]

I would recommend the following:

• Force-boot into safemode (press-and-hold the reset button until the Status LED lights)
• Using MAX on your dev machine, turn on the SSH server (if it's not already on) and force safemode
• Reboot the controller
• Using something like Filezilla or psftp, copy the contents of the /home/admin and /home/lvuser folders to your dev machine
• From MAX, format the target and reinstall the NI software
• Copy back the contents of the home folders using the tool used before

For future reference, it's usually not a good idea to manually delete library files from /lib or /usr/lib.

[tpc1095]

In safe mode we moved the /usr and /usr/local dirs (lib and include) aside, then re-installed RT-Linux and it booted normally again.

We probably should have depended on LD_LIBRARY_PATH in case anyone else finds this:

http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

I discovered that my colleague had run  ahead and started  ./configure --prefix=/usr which has run into a few problems and may ultimately fail.

At least we can recover pretty painlessly (except for the 10 package builds.)

[BradM]

tpc1095 wrote:

...

We probably should have depended on LD_LIBRARY_PATH in case anyone else finds this:

http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared- libraries

...

This is something useful if you have libraries in a non-standard path, but /usr/local/lib is on the library search path (as provided by /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf, if the directory exists) for 2013 through 2015 (at least for the stock image, unsure if something changed in modifying your target)

[ScotSalmon]

tpc1095 wrote:

In safe mode we moved the /usr and /usr/local dirs (lib and include) aside, then re-installed RT-Linux and it booted normally again.

For others who might read this: the run-mode /usr and /usr/local are found under /mnt/userfs while in safe mode. Moving /usr and /usr/local while in safe mode modifies the in-memory copy in use by safe mode and probably would do weird things (which would get fixed by a reboot).