Segment Fault Error when Linking to Dynamic Library in Linux

[Andrew_W_2]

Hello!

I am attempting to interface an old Fortan77 code to a newer code base written in Fortran90 by linking as a dynamic library.  I have been able to succefully compile and link using Fortran 10.6.3 in OSX (Yosemite 10.10.5), and the code runs without error.  Also, one of my associates has been able to compile, link, and run without errors in Windows7 using a DLL. However, in Linux (Elementary OS-64bit, Ubuntu variant) using Fortan 17.0.1, I encouter a segmentation fault error when the linked code is executed.

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
mcan.lin  00000000005B2421  Unknown               Unknown  Unknown
mcan.lin  00000000005B055B  Unknown               Unknown  Unknown
mcan.lin  000000000055A0B4  Unknown               Unknown  Unknown
mcan.lin  0000000000559EC6  Unknown               Unknown  Unknown
mcan.lin  00000000004F0DB9  Unknown               Unknown  Unknown
mcan.lin  00000000004F80B6  Unknown               Unknown  Unknown
libpthread-2.15.s  00002ABC3FB40CB0  Unknown               Unknown  Unknown
libscram_api.s  00002ABC35F39C9F  ggeni_                    241  ggeni.for

Here are the commands used to generate the Linux f77 library:

ifort -O0 -fltconsistency -save -c -fpic -I$include -debug all -traceback -check all -CB -g *.for
ld -nofor_main -shared -fpic --no-omagic -o libscram_api.so *.o

and to link to the f90 code:

ifort *.o -L. -lscram_api -o mcan

A couple other items to note are:

- The old f77 code has a single f90 file for wrapper to expose the interface. So, it is technically mixed f77/f90.

- The old f77 code has multiple common block and local variables that do not have explicity typing.  Could this be the issue? I have tried explicitly typing the lines near the segment fault but the issue persists.  Also, explicity typing all the variables in the entire code is a not a realistic solution - it would literally take months of work given the size of the code base.

- The code segment faults in the same location when I attempted to link in OSX via a static library or fully compile the f77 code with the f90 code.

So my question is this: why does the code segment fault in Linux and not in OSX or Windows? Is there a flag that I am missing that would resolve the issue?

Best regards,
Andy

[mecej4]

There are bugs that the compiler may be able to catch, other bugs that may be caught at run time, and other bugs that my be very difficult to catch. There is no magical compiler flag that will help you to identify such bugs.

Furthermore, such bugs are very much dependent on the contents of the source file(s) in question. Therefore, mere error reports without accompanying source code are not something that one can act upon. Usually, a complete "reproducer" -- consisting of complete self-contained code, with any data and include files if needed, and instructions to build and run -- is needed to establish even the mere existence of a bug.

[Kevin_D_Intel]

We often refer people to Determining Root Cause of Segmentation Faults SIGSEGV or SIGBUS errors. Sometimes this error relates to the smaller shell stack size.

Not suggesting it matters, instead I just wanted to understand the build, do you use ‘ld’ to link as shown or ifort for the F77 library?

If you’re interested in having the file/line number details added to the traceback, adding  –g –traceback to the mcan link.

Just curious, what is Fortran 10.6.3?

[Andrew_W_2]

Thank you, Kevin.  The segment fault error was generated using Fortan 17.0.1 for Linux.  Also, I did use "ld" to link the F77 library.

I have previously looked over the "Determining Root Cause of Segmentation Faults SIGSEGV or SIGBUS errors" link and checked the stack size.  I will review again and see if I missed anything.

Best regards,

Andy

[Kevin_D_Intel]

Try using ifort to drive the link for the shared library and not ld to ensure the necessary linkage is made to the Intel Fortran runtime libraries. A shared is allowed to have unresolved references at link-time; however, there could be a connection to the Intel runtime that's missing from using ld.

You need to change the command-line slightly to pass the --no-omagic as follows:

ifort -nofor_main -shared -fpic -Wl,--no-omagic -o libscram_api.so *.o

--no-omagic is not something I typically see used. Has this option always been used for this library/app build?