Install/use Shared Library on cRIO-9039

[PJS]

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

I did a git on GCC.   git clone --recursive  git://gcc.gnu.org/git/gcc.git.

I also installed build-essential

then I tried to follow the instructions on http://gfortran.meteodat.ch/download/x86_64/PLEASE_README.txt.

Attached is the config.log that results

[BradM]

In response to the strace snippet posted, ld.so.preload is perfectly normal, it is an optional system-wide way to specify libraries to load prior to running. The error that it's not found is perfectly fine to ignore.

Instead, looking at the SIGSEGV that ends the execution, we see that the code returned is SEGV_MAPERR, a quick googling shows that this is the code returned when you're attempting to access memory that isn't married to your assocation. The si_addr of 0x8 indicates likely an attempt to reference a member of a structure pointer, located 8 bytes in, of a structure pointer that is NULL.

[BradM]

On the topic of compiling a toolchain on the target for use on the target, this is a fairly advanced and error-prone proposition, as you're finding. This is before you even need to contend with the stack and memory management policies put in place for the sake of the RTness of the system.

I hate to discourage people, and I've been wrong in the past, but it feels like you're seeing yourself up for frustration by taking one of the least straightforward approaches to the problem, especially given that the crash seems that it is related to (relatively) simple memory reference issues. I still recommend trying to use gdb (with a debug version of the library) to get a bit better off a picture as to what is going wrong in the library

[PJS]

BradM wrote:

On the topic of compiling a toolchain on the target for use on the target, this is a fairly advanced and error-prone proposition, as you're finding. This is before you even need to contend with the stack and memory management policies put in place for the sake of the RTness of the system.

I hate to discourage people, and I've been wrong in the past, but it feels like you're seeing yourself up for frustration by taking one of the least straightforward approaches to the problem, especially given that the crash seems that it is related to (relatively) simple memory reference issues. I still recommend trying to use gdb (with a debug version of the library) to get a bit better off a picture as to what is going wrong in the library

All of this is a bit above my head.  But then again, so was LabVIEW when I delved in.  Unfortunately, I do not have a week to take the 'primer' course at this point.  I was hoping to take what was started here and run with it. 

[ScotSalmon]

The basics of gdb are not as hard as you might fear, and shouldn't take a week. Give this a shot, on the affected target:

admin@...# opkg update

admin@...# opkg install gdb

admin@...# cd <your_program_location>

admin@...# gdb ./<your_program_filename>

(gdb) run <your_program_command_line_arguments>

It'll be a lot more helpful if you have the ability to use a debug build of the affected program. But just give that a try and post the results. Overall while it's possible that the GCC distribution isn't compatible as suggested in your original post, it wouldn't be my first suspect for this type of crash, and maybe there will be a quick diagnosis. No promises though!

[PJS]

ScotSalmon wrote:

The basics of gdb are not as hard as you might fear, and shouldn't take a week. Give this a shot, on the affected target:

admin@...# opkg update

admin@...# opkg install gdb

admin@...# cd <your_program_location>

admin@...# gdb ./<your_program_filename>

(gdb) run <your_program_command_line_arguments>

It'll be a lot more helpful if you have the ability to use a debug build of the affected program. But just give that a try and post the results. Overall while it's possible that the GCC distribution isn't compatible as suggested in your original post, it wouldn't be my first suspect for this type of crash, and maybe there will be a quick diagnosis. No promises though!

Not sure what went south here.  Below is a copy of the cmds and responses.

----------------------------------------------------------------------------------------------------------------------------------

admin@NI-cRIO-9039-01B54B5A:~/bin# ls

fortest

admin@NI-cRIO-9039-01B54B5A:~/bin# gdb ./fortest

GNU gdb (GDB) 7.7.1

Copyright (C) 2014 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-nilrt-linux".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

"/home/admin/bin/./fortest": not in executable format: File format not recognized

----------------------------------------------------------------------------------------------------------------------------------

try without the ./

----------------------------------------------------------------------------------------------------------------------------------

# gdb fortest

GNU gdb (GDB) 7.7.1

Copyright (C) 2014 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-nilrt-linux".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

"/home/admin/bin/fortest": not in executable format: File format not recognized

--------------------------------------------------------

gdb run the program

--------------------------------------------------------

(gdb) run ./fortest

Starting program:  ./fortest

No executable file specified.

Use the "file" or "exec-file" command.

(gdb) exec-file fortest

"/home/admin/bin/fortest": not in executable format: File format not recognized

(gdb) quit

--------------------------------------------------------

So what is in the local directory?  List:

--------------------------------------------------------

admin@NI-cRIO-9039-01B54B5A:~/bin# ls

fortest

--------------------------------------------------------

Execute the file:

--------------------------------------------------------

admin@NI-cRIO-9039-01B54B5A:~/bin# ./fortest

Segmentation fault

admin@NI-cRIO-9039-01B54B5A:~/bin#

--------------------------------------------------------

So not sure why gdb fails.

[ScotSalmon]

Can you try ldd?

opkg install ldd

ldd ./fortest

[PJS]

ScotSalmon wrote:

Can you try ldd?

opkg install ldd

ldd ./fortest

admin@NI-cRIO-9039-01B54B5A:~/bin# ldd ./fortest

        statically linked

admin@NI-cRIO-9039-01B54B5A:~/bin#

[ScotSalmon]

I'm slightly suspicious of a 32- vs. 64-bit mismatch. The same file runs okay on your Ubuntu system, right? Can you do "uname -a" on the Ubuntu system? Also "file <path_to_your_program>" on the Ubuntu system. (If it's consistently 64-bit everywhere there's another relevant difference between OpenEmbedded distros like ours and Ubuntu distros, which is the path to the 64-bit libraries, but I don't recall the exact fix off the top of my head and don't have access to my system right now to check. But with the binary being statically linked hopefully that's not it anyway.)

[PJS]

ScotSalmon wrote:

I'm slightly suspicious of a 32- vs. 64-bit mismatch. The same file runs okay on your Ubuntu system, right? Can you do "uname -a" on the Ubuntu system? Also "file <path_to_your_program>" on the Ubuntu system. (If it's consistently 64-bit everywhere there's another relevant difference between OpenEmbedded distros like ours and Ubuntu distros, which is the path to the 64-bit libraries, but I don't recall the exact fix off the top of my head and don't have access to my system right now to check. But with the binary being statically linked hopefully that's not it anyway.)

I am working directly in the terminal.  so I made a screen shot of the requested information.