Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Fortran 77 Source coide need compilation

Kesavan_K_
Beginner
1,010 Views

We have a legacy fortran 77 source files, which are compiled to construct a shared dynamic library using Solaris Dev Studio11 fortran 95 compilers under Soalris 10(sparc). Issue now is we want to compile this source under RHEL6 using fortran compiler , which does that. We are testing with Gfortran and Solaris Studio 12(f95) compiler . Even though the compilation and creation of library succeeds , when called for by PL/SQL routing using external library , it throws out undefined source symbols error.. Decided to try our hand with Intel fortran . Original program compiled under Solaris used the following flags to construct  create the dynamic  library  " Kpic  xarch=generic64  -s -G ext_names=plain  -U '.  Also options "-o filename -h name" used to match Oracle Library Path... Our question is , what are the corresponding flags or options in ifort for the one mentioned here.. 

0 Kudos
8 Replies
Kevin_D_Intel
Employee
1,010 Views

Based on this Sun Fortran User's Guide, http://docs.oracle.com/cd/E19422-01/819-3686/, I took at stab at identifying the corresponding ifort options below.

Please refer to the Intel Fortran compiler User’s Guide for more details, https://software.intel.com/en-us/intel-fortran-compiler-17.0-user-and-reference-guide.

Solaris           ifort
-------           ---------
Kpic              -fpic  (produce position independent code)

xarch=generic64   -arch AVX (Best to refer to the ifort UG to decide what's appropriate. Initially you might not use a substitute option with ifort and accept the default generated code for the host platform you are compiling on)

-s                Use same option w/ifort. (This is a linker option to strip symbols from the executable. ifort passes -s to ld)

-G                -shared  (Produce a shared library)

ext_names=plain   -assume nounderscore (The option does not add trailing underscores. You might leave the option off and use the default w/ifor, which adds a trailing underscore, but if for some reason those need to be removed then use the -assume option noted.)

-U                -names as_is   (This Solaris option recognizes upper and lower case as distinct. If needed with ifort then use the -names option noted)

-o                Use the same option w/ifort. (Both compilers use this option to name the executable/lib/object file)

-h name           No equivalent ifort option. (This Solaris option names the shared library. Do not use w/ifort. Just use -o with ifort to name the shared lib)

0 Kudos
mecej4
Honored Contributor III
1,010 Views

Kesavan: Please show the exact error message that you saw regarding the undefined sources. Check if something similar is available in your shared library by running

     nm -g <our_dll.so> | grep "<symbol_name>" .

 

0 Kudos
Kesavan_K_
Beginner
1,010 Views
Getting following error, when compiling with following options.
 
 
/tmp/> for i in `ls *.for`; do ifort -fpic -arch AVX -s -shared-c $i -lc -z defs -f77rtl ; done
 
--------------------------^
FORWRD3D.for(2): remark #7841: DLL IMPORT/EXPORT is not supported on this platform.   [DLLEXPORT]
!DEC$ ATTRIBUTES DLLEXPORT :: forwrd3d
-----------------^
INVERS3D.for(1): remark #7841: DLL IMPORT/EXPORT is not supported on this platform.   [DLLEXPORT]
!DEC$ ATTRIBUTES DLLEXPORT :: invers3d
-----------------^
INVERSE.for(1): remark #7841: DLL IMPORT/EXPORT is not supported on this platform.   [DLLEXPORT]
!DEC$ ATTRIBUTES DLLEXPORT :: inverse
-----------------^
/tmp>
Above is with ifort.
 
 
With Gfortran, it compiles and creates the library. But when called by PL\SQL external library process, throws undefined symbols . while nm -g ran aganist those Gfortran compiled library, it shows following as undefined symbols.
 
/home/oracle/app> nm -g XXX.so |grep "U"
                 U asin@@GLIBC_2.2.5
                 U atan2@@GLIBC_2.2.5
                 U atan@@GLIBC_2.2.5
                 U cos@@GLIBC_2.2.5
                 U sin@@GLIBC_2.2.5
/home/oracle/app> nm -g YYY.so |grep "U"
                 U _gfortran_st_write@@GFORTRAN_1.0
                 U _gfortran_st_write_done@@GFORTRAN_1.0
                 U acos@@GLIBC_2.2.5
                 U atan2@@GLIBC_2.2.5
                 U atan@@GLIBC_2.2.5
                 U cos@@GLIBC_2.2.5
                 U fmod@@GLIBC_2.2.5
                 U pow@@GLIBC_2.2.5
                 U sin@@GLIBC_2.2.5
 
 
 
 
 
 
 
 
 
0 Kudos
Kevin_D_Intel
Employee
1,010 Views

Those are only remarks from ifort not errors so they wouldn't prevent successful compilation. There is a space missing between -shared and -c, but to compile and create the library using a single ifort command line you need to drop the -c as that's compiling to object only and thus not creating the shared library. Try something of the form: ifort -shared -o testlib.so src1.f90 src2.f90

0 Kudos
mecej4
Honored Contributor III
1,010 Views

Most of the unsatisfied externals listed in #4 are to entries in libm.so/libm.a; two others are to libgfortran.

In older versions of Unix, BSD, SunOS, etc, you had to ask for libm by using the -lm option explicitly when running the C compiler. Perhaps, the PL/SQL system needs to be told to use this flag when auto-building the external library.

0 Kudos
Kesavan_K_
Beginner
1,010 Views

Thanks Mecej4, for all your replies.. I was able to compile using g77 fortran compiler on the host without issues. But when invoked by PL/SQL library by external library call process , PL /SQL throws following error.

 

ORA-06521: PL/SQL: Error mapping function
ORA-06522: /home/oracle/app/XXX.so: undefined symbol: INVERS

Spoke to DBA about -lm option, but they are not sure of how to use that option . Any help on that... 

 

 

 

 

 

0 Kudos
Kesavan_K_
Beginner
1,010 Views

Thanks Kevin.. I will try compiling with ifort too and update the results soon.

0 Kudos
mecej4
Honored Contributor III
1,010 Views

This is a guess: On Unix and derivatives, external symbols are subject to changing case and addition of underscores either before or after the symbol name. Typically, Fortran externals are given an underscore as a suffix and converted to lowercase.

G77, Solaris f95 and Intel Fortran may not use the same conventions. You need to read all the relevant documentation and establish consistency as to symbol names.

Most Unix Fortran compilers would regard !DEC ... directives as just comments and interpret those lines no more after they see the leading '!'. Intel Fortran, with one foot in the Windows world, is trying to help people porting from Windows to Linux by issuing warnings that such directives have no effect in Linux and any desired consequences of these directives will fail to materialize.

 

0 Kudos
Reply