Thread Subject: mex file--use of Fortran intrinsic functions gives undefined symbol error

Hi there,

when using Fortran intrinsic functions in my mex-files
(e.g., log), I get an invalid mex-file error from Matlab
(R2007b) which complains about an unresolved symbol
(__svml_log2 in the example).

The question is: is there something that can be done during
compilation/linking to ensure that the Fortran intrinsic is
used (__svml_log2 sounds suspiciously like Intel Vector Math
Library)? Or, if that's not possible, which is the library
containing svml_log2 one needs to link against?

Thanks in advance for any suggestions,

Joachim

On Jan 14, 9:05 pm, "Joachim " <a...@b.com> wrote:
> Hi there,
>
> when using Fortran intrinsic functions in my mex-files
> (e.g., log), I get an invalid mex-file error from Matlab
> (R2007b) which complains about an unresolved symbol
> (__svml_log2 in the example).
>
> The question is: is there something that can be done during
> compilation/linking to ensure that the Fortran intrinsic is
> used (__svml_log2 sounds suspiciously like Intel Vector Math
> Library)? Or, if that's not possible, which is the library
> containing svml_log2 one needs to link against?

Google seems to indicate that libsvml would contain that library and
is confirmed on Linux at least. How are you doing the compiling/
linking? Most compilers will add their libraries on the link line as
is the case below.

[chulbert@hulbert64 ~]$ cat test.f90
SUBROUTINE test
 REAL(8) :: x(100),y(100)
 y = LOG(x)
END SUBROUTINE
[chulbert@hulbert64 ~]$ ifort -v -shared -fpic -o test.so test.f90
Version 10.0
/opt/intel/fce/10.0.023/bin/fortcom -D__INTEL_COMPILER=1000 -D_MT -
D__ELF__ -D__INTEL_COMPILER_BUILD_DATE=20070426 -D__PIC__ -D__pic__ -
D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -Dunix -
Dlinux -D__x86_64 -D__x86_64__ -mGLOB_pack_sort_init_list -I. -I/opt/
intel/fce/10.0.023/include -I/opt/intel/fce/10.0.023/
substitute_headers -I/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include -I/
usr/local/include -I/usr/include -I/usr/lib/gcc/x86_64-redhat-linux/
4.1.2/include "-fp_modspec fp_speculation_FAST" -O2 -
mP1OPT_version=1000 -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 -
mGLOB_tune_for_fort -mGLOB_use_fort_dope_vector -
mP2OPT_static_promotion -mP1OPT_print_version=FALSE -
mP3OPT_use_mspp_call_convention -mCG_use_gas_got_workaround=F -
mP2OPT_align_option_used=TRUE "-mGLOB_options_string=-v -shared -fpic -
o test.so" -mGLOB_position_independent_code -mGLOB_preemption_model=3 -
mGLOB_cxx_limited_range=FALSE -mP2OPT_eh_nirvana -mGLOB_diag_file=/tmp/
iforto9RWzd.diag -mGLOB_as_output_backup_file_name=/tmp/
ifortahVM6Tas_.s -mGLOB_machine_model=GLOB_MACHINE_MODEL_EFI2 -
mGLOB_fp_speculation=GLOB_FP_SPECULATION_FAST -
mGLOB_extended_instructions=0x8 -mP2OPT_subs_out_of_bound=FALSE -
mGLOB_ansi_alias -mIPOPT_ninl_user_level=2 -mIPOPT_args_in_regs=0 -
mPGOPTI_value_profile_use=T -mIPOPT_activate -mIPOPT_lite -
mP2OPT_hlo_level=2 -mP2OPT_hlo -mPAROPT_par_report=1 -
mIPOPT_obj_output_file_name=/tmp/iforto9RWzd.o "-
mGLOB_linker_version=2.17.50.0.6-5.el5 20061020" -
mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS -mGLOB_obj_output_file=/tmp/
iforto9RWzd.o -mGLOB_source_dialect=GLOB_SOURCE_DIALECT_FORTRAN -
mP1OPT_source_file_name=test.f90 test.f90
test.f90(3): (col. 2) remark: LOOP WAS VECTORIZED.
ld /usr/lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/
crtbeginS.o --eh-frame-hdr -shared -o test.so /tmp/iforto9RWzd.o -L/
opt/intel/fce/10.0.023/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/ -
L/usr/lib64 -lifport -lifcore -limf -lsvml -lm -lipgo -lintlc -lc -
lgcc_s -lirc_s -ldl -lc /usr/lib/gcc/x86_64-redhat-linux/4.1.2/
crtendS.o /usr/lib64/crtn.o --sort-section name
rm /tmp/ifortmNvzCSgnudirs

rm /tmp/ifortSAVpxygas

rm /tmp/ifortahVM6Tas_.s

rm /tmp/iforteYQbGfldashv

rm /tmp/iforthIHeFAarg

rm /tmp/ifortCUReKVgnudirs

rm /tmp/iforto9RWzd.o

[chulbert@hulbert64 ~]$ ldd test.so
        libifport.so.5 => /opt/intel/fce/10.0.023/lib/libifport.so.5
(0x00002aaaaacae000)
        libifcore.so.5 => /opt/intel/fce/10.0.023/lib/libifcore.so.5
(0x00002aaaaade4000)
        libimf.so => /opt/intel/cce/10.0.023/lib/libimf.so
(0x00002aaaaafda000)
        libsvml.so => /opt/intel/cce/10.0.023/lib/libsvml.so
(0x00002aaaab33c000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaab4d8000)
        libintlc.so.5 => /opt/intel/cce/10.0.023/lib/libintlc.so.5
(0x00002aaaab75b000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab895000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaabbe5000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabdf3000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)


Chris


>
> Thanks in advance for any suggestions,
>
> Joachim

Chris Hulbert wrote in message
> Google seems to indicate that libsvml would contain that
library and
> is confirmed on Linux at least. How are you doing the
compiling/
> linking? Most compilers will add their libraries on the
link line as
> is the case below.
>
> Chris
>

Thanks, Chris!

I hadn't had internet access for awhile--thus the late reply.

The following is the build command:

ifort -O3 -shared -fexceptions -fPIC -warn
-fno-omit-frame-pointer -DMX_COMPAT_32 testmex.F90
-I/usr/local/matlab75/extern/include -o testmex.mexa64

The output of "ldd testmex.mexa64" is

        libifport.so.5 =>
/opt/intel/fce/10.1.011/lib/libifport.so.5 (0x00002b7175419000)
        libifcore.so.5 =>
/opt/intel/fce/10.1.011/lib/libifcore.so.5 (0x00002b717554f000)
        libimf.so => /opt/intel/fce/10.1.011/lib/libimf.so
(0x00002b7175754000)
        libsvml.so => /opt/intel/fce/10.1.011/lib/libsvml.so
(0x00002b7175ab7000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b7175c61000)
        libintlc.so.5 =>
/opt/intel/fce/10.1.011/lib/libintlc.so.5 (0x00002b7175eb4000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b7175ff0000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1
(0x00002b7176335000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b7176543000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

So the symbols appear resolved. But when calling testmex
from Matlab, I get the error

??? Invalid MEX-file '/home/joachim/testmex.mexa64':
/home/joachim/testmex.mexa64: undefined symbol: __svml_log2.

I just figured: the problem with using log only occurs when
optimization options are turned on, i.e. when the compiler
vectorizes the loop containing the log statement.

The offending mex-file is reproduced below.

#include "fintrf.h"

subroutine mexfunction(nlhs, plhs, nrhs, prhs)

implicit none

interface
  subroutine testmex(y,x)
    real(8), dimension(:,:,:), intent(out) :: y
    real(8), dimension(:,:,:), intent(in) :: x
  end subroutine testmex
end interface

integer(4), intent(in) :: nlhs, nrhs
mwpointer, intent(in), dimension(*) :: prhs
mwpointer, dimension(*) :: plhs
mwpointer :: mxgetdimensions
mwpointer :: mxGetPr
mwpointer :: mxCreateNumericArray
integer(4) :: mxClassIDFromClassName
mwsize, dimension(3) :: dims

real(8), dimension(:,:,:), allocatable :: x,y

! Check for correct no. of input arguments
if(nrhs/=1) then
  call mexErrMsgTxt('one input required.')
else if(nlhs/=1) then
  call mexErrMsgTxt('one output required.')
endif

call mxcopyptrtointeger4(mxgetdimensions(prhs(1)),dims,3) !
assume, don't check that input is 3-D

if(dims(3)/=3) then
  call mexErrMsgTxt('size of xall must be (ipg1 x ipg2 x 3)')
endif

allocate(x(dims(1),dims(2),3))
allocate(y(dims(1),dims(2),3))

! copy pointers (right-hand side arguments) to Fortran arrays
call mxCopyPtrToReal8(mxGetPr(prhs(1)),x,product(dims))

! create pointers to left-han side arguments
plhs(1) =
mxCreateNumericArray(3,dims,mxClassIDFromClassName('double'),0)

! call the computational routine.
call testmex(y,x)

! copy left-hand side argument to Matlab
call mxCopyReal8ToPtr(y,mxGetPr(plhs(1)),product(dims))

! free memory
deallocate(x,y)

end subroutine mexfunction

subroutine testmex(y,x)

implicit none

real(8), dimension(:,:,:), intent(in) :: x
real(8), dimension(:,:,:), intent(out) :: y

integer(4) :: i1,i2,i3

!$omp parallel do
do i1=1,size(x,1)
  do i2=1,size(x,2)
    do i3=1,size(x,3)
      y(i1,i2,i3)=log(x(i1,i2,i3))
    enddo
  enddo
enddo
!$omp end parallel do


end subroutine testmex

"Joachim " <a@b.com> wrote in message <fmh4cg$hes$1@fred.mathworks.com>...
> Hi there,
>
> when using Fortran intrinsic functions in my mex-files
> (e.g., log), I get an invalid mex-file error from Matlab
> (R2007b) which complains about an unresolved symbol
> (__svml_log2 in the example).
>
> The question is: is there something that can be done during
> compilation/linking to ensure that the Fortran intrinsic is
> used (__svml_log2 sounds suspiciously like Intel Vector Math
> Library)? Or, if that's not possible, which is the library
> containing svml_log2 one needs to link against?
>
> Thanks in advance for any suggestions,
>
> Joachim

Hi Joachim, did you ever resolve this issue? I'm having the same problem as you describe when I turn the optimizations on when compiling my .mex file.

many thanks, Chris

I know I'm resurrecting an old thread, but I found a solution to this problem, which I was having too. Thought I'd record it for posterity...

Discussion on this page helps:
http://software.intel.com/en-us/forums/intel-c-compiler/topic/60482/

The sum of the parts is that you need to add the -shared-intel flag to the compiler command.

In my case, I compile mex files from the command line (see below for commands that work for my current project) but I presume that if you use the mex command, that you give the option to that, too, to be passed down to the compiler.

The -shared-intel flag basically builds the libraries into the mex file at compile-time, so it doesn't matter if you don't have the correct libraries set up at run time. I think it's amore robust way of doing things anyway, but it does increase the size of the mex file a bit.

COMPILE
'ifort -c -O3 -fast -static-intel -I/usr/matlab7.6/extern/include -I/usr/matlab7.6/simulink/include -fexceptions -fPIC -DMX_COMPAT_32 "my_mex_file.F90"')

LINK
'ifort -O3 -fast -static-intel -shared -m32 -Wl, --version-script,/usr/matlab7.6/extern/lib/glnx86/fexport.map -Wl,--no-undefined -o "my_mex_file.mexglx" my_mex_file.o "/usr/matlab7.6/extern/lib/glnx86/version4.o" -Wl,-rpath-link,/usr/matlab7.6/bin/glnx86 -L/usr/matlab7.6/bin/glnx86 -lmx -lmex -lmat -lm -L/usr/g95-x86-linux/g95-install/lib/gcc-lib/i686-suse-linux-gnu/4.0.3 -lf95');