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..
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.
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)
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>" .
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
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.
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...
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.