Install/use Shared Library on cRIO-9039

[PJS]

I want to install a fortran shared library.  I have compiled it on an Ubuntu distro and get a segmentation fault.  I believe that the GCC distributrion is not compatible... I believe the best solution would be to compile the shared libary on the cRIO using gFortran and GCC.  Ideas on rectifying the segmentation fault or pointing me towards a repository that contains GCC and GFortran or any other help would be appreciated.

[BradM]

PJS,

One of the issues that you'll face is that the toolchain that is build and put in the NI Linux RT feeds for installation is not configured for FORTRAN. From a quick peek at the OpenEmbedded recipe that provides gcc, it seems that it is a package that is built but we don't seem to put the gfortran tools on the feed repo.

If you're feeling adventurous, you can download and configure the GCC sources to give exactly what you need, but the difficulty there is needing to manage the two different compile systems in a clean way (e.g. what do you do when you're done building the new toolchain with fortran support? Install to the side? Remove the opkg-installed toolchain?). It can get messy.

Another option would be to use some tools to try to determine why the shared library is crashing. How are calling the library? I'd take a look at using strace or gdb to get a better idea of what leads up to the crash.

[BradM]

PJS,

Out of curiosity, I dug in a bit further and it seems that you'd need to change the gcc recipe that is used to build the toolchain that is put on the NI Linux RT feed repository to  actually enable fortran. I made this modification locally and built the gcc recipe and it did indeed result in a gfortran (and gfortran-symlinks) package that provides the tools needed to build fortran code. I have not tested the packages as I don't have an x64 target handy.

This is still orthogonal to the question that I posed previously: How are you calling the library? It also doesn't affect some of the basic suggestions to better characterize the failure with some additional tools.

[Sev_K]

Hi Brad,

Could you clarify what do you mean by " change the gcc recipe that is used to build the toolchain "?

Are you referring to configure flags that will enable fortran support (ex. ./configure  --enable-languages=c,c++,fortran)

Thanks,

Sev

[BradM]

Sev_K wrote:

Hi Brad,

Could you clarify what do you mean by " change the gcc recipe that is used to build the toolchain "?

Are you referring to configure flags that will enable fortran support (ex. ./configure  --enable-languages=c,c++,fortran)

Thanks,

Sev

Sev_K, that's precisely what I mean: adjusting the OE bitbake recipe for gcc (for the version that is used in building the image that is used for NI Linux RT targets) to enable fortran when configuring the recipe.

[Sev_K]

Ok, I've tried recompiling gcc-4.8.3 (which is slightly newer what we have in the NI Linux RT repo gcc-4.8.2) and I got a seg fault somewhere in the middle of the "make":

I've tried a couple of other versions of gcc and they all had the same issue. I think it might be that the version of glibc is older than what is expected for gfortran (based on: http://gfortran.meteodat.ch/download/x86_64/PLEASE_README.txt)

A lot of other programs rely of glibc so it's kind of hard to uninstall. Is there an easy way to upgrade glibc?

-Sev

[BradM]

This is likely a stack issue. By default, NI Linux RT limits the stack size (as has been covered in a few of the discussions in these forums). From the shell that you're launching the build process from, run the command

ulimit -s unlimited

first. Note that you may also want to consider adding swap to your system (again, this has been covered in some of the other discussions in these forums)

[PJS]

I am on the limits of my comfort zone at this point.  I have never compiled a program until this project.  When compiling on Unbuntu, I need only find the missing packages and install them.  With the RT system, I have had to hunt for repositories, which I believe has led to mixed versions of some stuff.   However to your post,

Running STRACE on the test program yields:

-----

strace ./bin/fortest

execve("./bin/fortest", ["./bin/fortest"], [/* 17 vars */]) = 0

brk(0)                                  = 0x860000

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd                            4029ab000

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd                            4029aa000

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd                            4029a9000

arch_prctl(ARCH_SET_FS, 0x7fd4029aa680) = 0

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---

+++ killed by SIGSEGV +++

Segmentation fault

-----

the ld.so.preload appears to be something unique to strace as I could not find any reference to a system that has this installed.

[PJS]

I am calling the library using a test program that was compiled on my Ubuntu VM.  It runs a few calculations that verify that the shared object I build is working.  The Fortran code is not mine and I did not modify it from the original supplied.

The supplied source is 'word of God' and can not be 'rewritten'.  It is supplied by NIST.  I can make the source code and instructions I used to compile this in Ubuntu available via email or FTP.  Due to licensing agreements, I can not post the source here.  However, the basic instructions are found here:  https://github.com/jowr/librefprop.so

[PJS]

BradM wrote:

Sev_K wrote:

Hi Brad,

Could you clarify what do you mean by " change the gcc recipe that is used to build the toolchain "?

Are you referring to configure flags that will enable fortran support (ex. ./configure  --enable-languages=c,c++,fortran)

Thanks,

Sev

Sev_K, that's precisely what I mean: adjusting the OE bitbake recipe for gcc (for the version that is used in building the image that is used for NI Linux RT targets) to enable fortran when configuring the recipe.

To confirm, this command would be executed after downloading the GCC source?  If so, what version are we looking at using.  I do not believe the code I am compiling is going to be extremely particular.