undefined reference to `__intel_sse2_strcpy'

[oger__luc]

when I tried tom compile under linux 64 bits, i got this error during the link process :
"/opt/intel/composerxe-2011.1.107/compiler/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__issue_diagnostic':
for_diags_intel.c:(.text+0x1259): undefined reference to `__intel_sse2_strcpy' "

is it a bug or is some option missing in my linking command.

NB the previous version of omposerxe-2011.1.084 was working

[TimP]

I've seen this in my installation. Setting default options (-msse2 or even -msse3) with normal optimization will result in a call to this function, while the corresponding library isn't present in the compiler installation. In my installation, the libraries supported ssse3 and sse4 versions of this function, so compiling your code with ssse3, sse4.1, or sse4.2 options would avoid the problem. If you need to support sse2 or sse3, this is a compiler packaging bug. I suppose you could work around it by using the libraries from your 2011.1.084 installation.

[jellerknorr]

I have a similar problem. I've been trying to compile the FAST simulator from NREL.org in Matlab (Sfunctions for Simulink).

When I try to execute the compiled mex file I get the following:

/opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libifcoremt.so.5:undefined symbol: __intel_sse2_strcpy.

The library does indeed have undefined symbols.

$:/opt/intel/lib/intel64$ nm libifcoremt.so.5 | grep __intel

U __intel_sse2_strcpy

U __intel_sse2_strlen

However the symbol __intel_sse2_strcpy is in libirc.so:

$:/opt/intel/lib/intel64$ nm libirc.so | grep __intel_sse2_strcpy

000000000001a500 T __intel_sse2_strcpy

The source is compiled with the flags

[bash]-c -fPIC -fno-omit-frame-pointer -reentrancy threaded -real-size 64 -msse4.2 -xSSE4.2[/bash]

The source is linked with the flags

[bash]-shared -pthread -Wl,--version-script,/home/knorr/Programmer/matlab/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -g -lirc -msse4.2 -xSSE4.2 -lmx -lmex -lmat[/bash]

I have tried with and with out the sse4.2 optimizations, same result.

[bash]$:~/Desktop/fast/Simulink/Source$ ldd FAST_SFunc.mexa64 
	linux-vdso.so.1 =>  (0x00007fff25da9000)
	libirc.so => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libirc.so (0x00007f52e77b5000)
	libmx.so => not found
	libmex.so => not found
	libmat.so => not found
	libm.so.6 => /lib/libm.so.6 (0x00007f52e7514000)
	libifport.so.5 => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libifport.so.5 (0x00007f52e73da000)
	libifcoremt.so.5 => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libifcoremt.so.5 (0x00007f52e714a000)
	libimf.so => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libimf.so (0x00007f52e6d67000)
	libsvml.so => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libsvml.so (0x00007f52e66be000)
	libintlc.so.5 => /opt/intel/composerxe-2011.2.137/compiler/lib/intel64/libintlc.so.5 (0x00007f52e656f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f52e6351000)
	libc.so.6 => /lib/libc.so.6 (0x00007f52e5fce000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f52e5db8000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f52e5bb4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f52e7d33000)
[/bash]

Shows that libirc.so is indeed linked in, but apparently it's symbols cannot be used.

Don't mind that libmx, libmex and libmat is not found, as the path is set in the Matlab environment, when running mex.

I don't know if this problem is related to Matlab, FAST or ifort. But this thread is the only mention of the problem I was able to find.

[TimP]

Thanks for pointing this out. I'm sure it's not related to your choice Matlab or FAST.
The reference to the sse2_str functions could come from a .o file which was made with lower than ssse3 optimizations, so you might expect trouble with a generic compiled library, or it could come about as an unsatisfied dependency from libifcore, in which case ifortmay beto blame.
If the problem is still present, could you show the screen echo from the link step with -# added to the options? I suppose -lirc isn't supplied automatically at the correct point (a link order problem?). We shouldn't have to deal with this ourselves, but would moving -lircto the end help?

[jellerknorr]

I tried moving -lirc to the end to no avail.

Here's the output from the linking with -#

[bash]-> ifort -g -shared -pthread -# -Wl,--version-script,/home/knorr/Programmer/matlab/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -msse4.2 -xSSE4.2 -o  "FAST_SFunc.mexa64"  DoubPrec.o SysMatlab.o NWTC_IO.o NWTC_Num.o NWTC_Aero.o NWTC_Library.o SharedInflowDefs.o HHWind.o FFWind.o FDWind.o CTWind.o UserWind.o InflowWindMod.o SharedTypes.o AeroMods.o GenSubs.o AeroSubs.o AeroDyn.o FAST_Mods.o Noise.o fftpack.o FFTMod.o HydroCalc.o AeroCalc.o FAST_IO.o FAST.o PitchCntrl_ACH.o SetVersion.o UserSubs.o UserVSCont_KP.o FASTSimulink.o FASTGateway.o  -Wl,-rpath-link,/home/knorr/Programmer/matlab/bin/glnxa64 -L/home/knorr/Programmer/matlab/bin/glnxa64 -lmx -lmex -lmat -lm -lirc

ifort: command line remark #10010: option '-pthread' is deprecated and will be removed in a future release. See '-help deprecated'
/opt/intel/composerxe-2011.2.137/bin/intel64/fortcom  
    -mP1OPT_version=12.0-intel64 
    -mGLOB_diag_file=DoubPrec.diag 
    -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 
    -mGLOB_tune_for_fort 
    -mGLOB_use_fort_dope_vector 
    -mP2OPT_static_promotion 
    -mP1OPT_print_version=FALSE 
    -mCG_use_gas_got_workaround=F 
    -mP2OPT_align_option_used=TRUE 
    -mGLOB_gcc_version=450 
    "-mGLOB_options_string=-g -shared -pthread -# -Wl,--version-script,/home/knorr/Programmer/matlab/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -msse4.2 -xSSE4.2 -o FAST_SFunc.mexa64 -Wl,-rpath-link,/home/knorr/Programmer/matlab/bin/glnxa64 -L/home/knorr/Programmer/matlab/bin/glnxa64 -lmx -lmex -lmat -lm -lirc" 
    -mGLOB_cxx_limited_range=FALSE 
    -mP3OPT_emit_line_numbers 
    -mGLOB_debug_target=GLOB_DEBUG_TARGET_ALL 
    -mGLOB_debug_format=GLOB_DEBUG_FORMAT_DWARF20 
    -mGLOB_as_output_backup_file_name=/tmp/iforttW0MAnas_.s 
    -mIPOPT_activate 
    -mGLOB_machine_model=GLOB_MACHINE_MODEL_EFI2 
    -mGLOB_product_id_code=0x22001de7 
    -mGLOB_extended_instructions=0x400 
    -mGLOB_advanced_optim=TRUE 
    -mP3OPT_use_mspp_call_convention 
    -mP2OPT_subs_out_of_bound=FALSE 
    -mGLOB_ansi_alias 
    -mPGOPTI_value_profile_use=T 
    -mP2OPT_il0_array_sections=TRUE 
    -mP2OPT_hlo 
    -mP2OPT_hpo_rtt_control=0 
    -mIPOPT_args_in_regs=0 
    -mIPOPT_link 
    -mIPOPT_ipo_activate 
    -mIPOPT_mo_activate 
    -mIPOPT_source_files_list=/tmp/ifortvvx4EPslis 
    -mIPOPT_mo_global_data 
    -mIPOPT_link_script_file=/tmp/ifortRE66X0script 
    -mIPOPT_link_version=2.21 
    "-mIPOPT_cmdline_link="/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crti.o" "/usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtbeginS.o" "--eh-frame-hdr" "-shared" "-L/home/knorr/Programmer/matlab/bin/glnxa64" "-o" "FAST_SFunc.mexa64" "-L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64" "-L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64" "-L/opt/intel/composerxe-2011.2.137/mkl/lib/intel64" "-L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64" "-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2" "-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64" "-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib" "-L/lib/../lib64" "-L/lib/../lib" "-L/usr/lib/../lib64" "-L/usr/lib/../lib" "-L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64" "-L/opt/intel/composerxe-2011.2.137/mkl/lib/intel64" "-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../.." "-L/lib64" "-L/lib" "-L/usr/lib64" "-L/usr/lib" "-L/usr/lib/x86_64-linux-gnu" "--version-script" "/home/knorr/Programmer/matlab/extern/lib/glnxa64/fexport.map" "--no-undefined" "DoubPrec.o" "SysMatlab.o" "NWTC_IO.o" "NWTC_Num.o" "NWTC_Aero.o" "NWTC_Library.o" "SharedInflowDefs.o" "HHWind.o" "FFWind.o" "FDWind.o" "CTWind.o" "UserWind.o" "InflowWindMod.o" "SharedTypes.o" "AeroMods.o" "GenSubs.o" "AeroSubs.o" "AeroDyn.o" "FAST_Mods.o" "Noise.o" "fftpack.o" "FFTMod.o" "HydroCalc.o" "AeroCalc.o" "FAST_IO.o" "FAST.o" "PitchCntrl_ACH.o" "SetVersion.o" "UserSubs.o" "UserVSCont_KP.o" "FASTSimulink.o" "FASTGateway.o" "-rpath-link" "/home/knorr/Programmer/matlab/bin/glnxa64" "-lmx" "-lmex" "-lmat" "-L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64" "-Bstatic" "-limf" "-Bdynamic" "-lm" "-lirc" "-lifport" "-lifcoremt" "-limf" "-lsvml" "-lm" "-lipgo" "-lintlc" "-u" "__pthread_once" "-lpthread" "-lc" "-lgcc_s" "-lirc_s" "-ldl" "-lc" "/usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtendS.o" "/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crtn.o"" 
    -mIPOPT_il_in_obj 
    -mIPOPT_ipo_activate_warn=FALSE 
    -mIPOPT_obj_output_file_name=/tmp/ipo_ifortg1uUOJ.o 
    -mGLOB_linker_version=2.21 
    -mGLOB_long_size_64 
    -mGLOB_routine_pointer_size_64 
    -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS 
    -mGLOB_obj_output_file=/tmp/ipo_ifortg1uUOJ.o 
    -mP1OPT_source_file_name=ipo_out.f 
    -mP2OPT_symtab_type_copy=true 
    DoubPrec.o 
    SysMatlab.o 
    NWTC_IO.o 
    NWTC_Num.o 
    NWTC_Aero.o 
    NWTC_Library.o 
    SharedInflowDefs.o 
    HHWind.o 
    FFWind.o 
    FDWind.o 
    CTWind.o 
    UserWind.o 
    InflowWindMod.o 
    SharedTypes.o 
    AeroMods.o 
    GenSubs.o 
    AeroSubs.o 
    AeroDyn.o 
    FAST_Mods.o 
    Noise.o 
    fftpack.o 
    FFTMod.o 
    HydroCalc.o 
    AeroCalc.o 
    FAST_IO.o 
    FAST.o 
    PitchCntrl_ACH.o 
    SetVersion.o 
    UserSubs.o 
    UserVSCont_KP.o 
    FASTSimulink.o 
    FASTGateway.o 
    -mIPOPT_object_files=/tmp/ifort2MsV7Uolis 
    -mIPOPT_assembly_files=/tmp/ifortUBSWq6alis 
    -mIPOPT_generated_tempfiles=/tmp/ifortCZyYJhelis 
    -mIPOPT_embedded_object_base_name=/tmp/ifort4sg02seobj 
    -mIPOPT_cmdline_link_new_name=/tmp/ifortykg2lEllis

ld  
    /usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crti.o 
    /usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtbeginS.o 
    --eh-frame-hdr 
    -shared 
    -L/home/knorr/Programmer/matlab/bin/glnxa64 
    -o 
    FAST_SFunc.mexa64 
    -L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64 
    -L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64 
    -L/opt/intel/composerxe-2011.2.137/mkl/lib/intel64 
    -L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64 
    -L/usr/lib/gcc/x86_64-linux-gnu/4.5.2 
    -L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64 
    -L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib 
    -L/lib/../lib64 
    -L/lib/../lib 
    -L/usr/lib/../lib64 
    -L/usr/lib/../lib 
    -L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64 
    -L/opt/intel/composerxe-2011.2.137/mkl/lib/intel64 
    -L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../.. 
    -L/lib64 
    -L/lib 
    -L/usr/lib64 
    -L/usr/lib 
    -L/usr/lib/x86_64-linux-gnu 
    --version-script 
    /home/knorr/Programmer/matlab/extern/lib/glnxa64/fexport.map 
    --no-undefined 
    DoubPrec.o 
    SysMatlab.o 
    NWTC_IO.o 
    NWTC_Num.o 
    NWTC_Aero.o 
    NWTC_Library.o 
    SharedInflowDefs.o 
    HHWind.o 
    FFWind.o 
    FDWind.o 
    CTWind.o 
    UserWind.o 
    InflowWindMod.o 
    SharedTypes.o 
    AeroMods.o 
    GenSubs.o 
    AeroSubs.o 
    AeroDyn.o 
    FAST_Mods.o 
    Noise.o 
    fftpack.o 
    FFTMod.o 
    HydroCalc.o 
    AeroCalc.o 
    FAST_IO.o 
    FAST.o 
    PitchCntrl_ACH.o 
    SetVersion.o 
    UserSubs.o 
    UserVSCont_KP.o 
    FASTSimulink.o 
    FASTGateway.o 
    -rpath-link 
    /home/knorr/Programmer/matlab/bin/glnxa64 
    -lmx 
    -lmex 
    -lmat 
    -L/opt/intel/composerxe-2011.2.137/compiler/lib/intel64 
    -Bstatic 
    -limf 
    -Bdynamic 
    -lm 
    -lirc 
    -lifport 
    -lifcoremt 
    -limf 
    -lsvml 
    -lm 
    -lipgo 
    -lintlc 
    -u 
    __pthread_once 
    -lpthread 
    -lc 
    -lgcc_s 
    -lirc_s 
    -ldl 
    -lc 
    /usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtendS.o 
    /usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crtn.o

rm /tmp/ifortYFdkdnlibgcc

rm /tmp/ifortLfAUvygnudirs

rm /tmp/ifort2MsV7Uolis

rm /tmp/ifortUBSWq6alis

rm /tmp/ifortCZyYJhelis

rm /tmp/ifortykg2lEllis

rm /tmp/ifortvvx4EPslis

rm /tmp/ifortRE66X0script

rm /tmp/ipo_ifortg1uUOJ.o

rm /tmp/ifortxnfahcgas

rm /tmp/iforttW0MAnas_.s

rm /tmp/ifortgH2qUyldashv

rm /tmp/ifortqtjzeKgnudirs

rm /tmp/ifortTTltzVarg

mex completed: FAST_SFunc.mexa64 has been created.
>> 
[/bash]

[TimP]

I see that the ifort generated link script links libirc before libifcoremt, which looks wrong to me, given that the latter could introduce dependencies on the former. It seems to be a different problem witha similarsymptom as the one I saw for myself with an earlier 12.0 version.
It may be possible to test this by constructing the linker script and feeding it directly to gnu ld, then changing the order to see if that will help. This is a lot to ask, when the compiler should be getting it right without such effort.
We should get attention to this question from the compiler library team. If you care to submit a test case on premier.intel.com, you would not necessarily need to provide all sources; the ifortlink command and the files required for it may be sufficient.

[jellerknorr]

I took the ld command, moved lirc to come after lifcoremt and run ld again. Still undefined reference to __intel_sse2_strcpy

I'm not able to login to premier.intel.com, should I do something different from here?

[tried100times]

I'm getting the same problem trying to build a Matlab mex file. Even manually adding -lirc to the mex options, I get the above undefined symbol error for __intel_sse2_strcpy.

I am using ifort 12.0.3.

Is there any way around this problem?

Thanks

[mecej4]

Tim,

Here are some points that may help pinpoint the problem. I have not experienced the problem myself, and what I write below is based on what I read in this thread and based on what symbols I see in the shared libraries. Please feel free to critique the analysis.

i) The problem occurs only when the 64-bit shared version of, e.g., libifcoremt.so, is used in the link. This library wants to import __intel_sse2_strcpy, which is found in libintlc.so.5 and in libirc.so. However, running ldd on libifcoremt.so shows only libintlc.so.5 listed as a prerequisite and NOT libirc.so.

ii) If any executable is built against the 64-bit libifcoremt.so, including libirc.so, libirc.a, etc. in the link will make no difference because __intel_sse2_strcpy is not an unsatisfied external in any of the user's objects.

iii) when the user runs the just-built executable, an attempt is made to load libifcoremt.so when demanded. It is at this point that failure occurs, for reasons that I do not understand; perhaps because libintlc.so.5 is not available or is not properly listed as a dependency in libifcoremt.so, or because libifcoremt.so is flawed or corrupted.

[tried100times]

As an update - I tried to build with -static-intel (which caused another problem whereby the _pic libraries aren't chosen automatically and have to be specified by hand). But even with that I get the same error:



-> /opt/intel/bin/ifort -c -I/usr/local/MATLAB/R2010b/extern/include -I/usr/local/MATLAB/R2010b/simulink/include -xhost -fexceptions -fpp -fPIC -static-intel -DMX_COMPAT_32 -O2 "MatlabAPI_real.f"

-> /opt/intel/bin/ifort -O2 -xhost -fPIC -static-intel -pthread -shared -Wl,--version-script,/usr/local/MATLAB/R2010b/extern/lib/glnxa64/fexport.map -Wl,--no-undefined -o "MatlabAPI_real.mexa64" MatlabAPI_real.o "MatlabAPImex.o" "MatlabAPImx.o" /opt/intel/lib/intel64/libifcoremt_pic.a -Wl,-rpath-link,/usr/local/MATLAB/R2010b/bin/glnxa64 -L/usr/local/MATLAB/R2010b/bin/glnxa64 -lmx -lmex -lmat -L/opt/intel/lib/intel64 -lm -lirc

ifort: command line remark #10010: option '-pthread' is deprecated and will be removed in a future release. See '-help deprecated'

>> MatlabAPI_real
??? Invalid MEX-file
'/home/robince/src/MatlabAPI_20091219/MatlabAPI_real.mexa64':
/home/robince/src/MatlabAPI_20091219/MatlabAPI_real.mexa64: undefined
symbol: __intel_sse2_strcpy.

robince@linux407:~/src/MatlabAPI_20091219$ ldd MatlabAPI_real.mexa64
linux-vdso.so.1 => (0x00007fffba8dc000)
libmx.so => not found
libmex.so => not found
libmat.so => not found
libm.so.6 => /lib/libm.so.6 (0x00007fcf4f407000)
libirc.so => /opt/intel/lib/intel64/libirc.so (0x00007fcf4f2b7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fcf4f099000)
libc.so.6 => /lib/libc.so.6 (0x00007fcf4ed16000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fcf4eb00000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fcf4e8fb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcf4f9c0000)

It would be great if there was anything else I could try?

[tried100times]

I made a mistake! I was still manually adding -lirc from the other problem, it seems to be this library that has the undefined symbol. When I removed it the static version seems to work.

It would still be nice to get the dynamic version working though.

[_samuel_]

Hello everybody,
I spent quit some time with more or less the same problem. Mercej4 analyse is probably correct I think (thank you!) at least it brougth me to a

solution:

link (dynamically) with the library libifcoremt.so
followed by a static link to libirc(.a)

in my case this looks like this:
... -L/soft/intel/composerxe-2011.3.174/compiler/lib/intel64/ -lifcoremt -Bstatic -lirc -Bdynamic ...

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


->What I think why it doesn't work if we don't link these two libraries:
at runtime libifcoremt.so is loaded containing __intel_sse2_strcpy as an undefined Symbol as you can see:

$ nm /soft/intel/composerxe-2011.3.174/compiler/lib/intel64/libifcoremt.so.5 | grep __intel_
U __intel_sse2_strcpy
U __intel_sse2_strlen

(Note: my executable looked like this:
$ nm MPI_MEX_Init.mexa64 | grep __intel_
U __intel_sse2_strlen
)


->What I think why it works if we link these two libraries:
linking libifcoremt.so with your executable will show the linker this undefined symbols and he will try to resolve them with the libraries following. So, when we then statically link the libirc(.a) library he will copy this symbols into your executable.
(my executable looked then like this:
$ nm MPI_MEX_Init.mexa64 | grep __intel_sse
0000000000002e20 T __intel_sse2_strcpy
0000000000003090 T __intel_sse2_strlen
0000000000002f70 T __intel_sse4_strcpy
00000000000030c0 T __intel_sse4_strlen


->Final note: If you only (statically) link libirc, only the __intel_sse2_strlen is showed to the linker as unknown (by some other libraries probably) and so only this symbol will be copied into your executable. The __intel_sse2_strcpy symbol however will still appear as missing at runtime when libifcoremt.so is loaded.


I would be pleased to read a more sophisticated analyse why my solution works :) Mercej4 your turn again!;)

Best regards, Sam

[faughta]

It looks like I am having a similar problem to what has been described in this thread. Execuse my ignorance on your proposed solution, Sam, but I don't fully understand the statement

"in my case this looks like this:
... -L/soft/intel/composerxe-2011.3.174/compiler/lib/intel64/ -lifcoremt -Bstatic -lirc -Bdynamic ..."

Is this the command that you used to establish the link? I'm very new to unix, and trying to resolve this problem with little understanding of the workings has been a challenge. Also, how does lifcoremt and lirc differ from libifcoremt and libirc? Are these the links being established? I'm assuming that /soft/intel/composerxe-2011.3.174/compiler/lib/intel64 is the location of the libraries.

Thanks for any clarifications people can offer.

Best,

Austin

[TimP]

The linker instructions such as -lifcoremt are standard gnu linker abbreviations to be filled out as libifcoremt.[a|so], using the specified -L paths. So you need to look in your installation to verify the actual paths. When you use the Intel compiler to drive the link, if you haven't moved it from the path where you originally installed it, the -L paths will be supplied automatically. You can see them by adding the -# option to your ifort/icc/icpc link command.
If you want the Intel compiler in a different path from where you originally installed it, you should uninstall and repeat the installation. Then you will not need to know the Intel compiler library paths unless you are asking a tool other than the Intel compilers to do the link.

[faughta]

Thanks, Tim. I don't believe the paths are the issue though. If my understanding of the problem is correct, the strcpy (or strcat in my case) command is being looked for in libifcoremt where it is undefined. Instead the command is defined in libirc, so as a result there needs to be some means for pointing to libirc. I thought that this was the link that a previous commenter was trying to establish. Again, I'm quite new to Unix environments, so my interpretation of the problem and solution could be off base.

I'm running a mex file in MATLAB that uses Fortran compiler, and I'm unclear of whether the link between libraries needs to be established within MATLAB or Unix.

-Austin

[TimP]

If you link in the supported manner, the ifort libraries should be searched in the correct order. Again, you could set -# to verify that ifort gives proper instructions to ld. There was a single released version where sse2_strcpy() was missing, but you indicate that it is present.

[faughta]

I tried wiping and re-installing the compiler to get a fresh start in case I messed something up while trying to resolve the issue. I continue to get a message when trying to run my MATLAB executable that there is an undefeined symbol __intel_sse2_strcat in libifcoremt.so.5. When using grep to check, this is in fact the case and the symbol is instead defined in libirc.

I'm really quite confused at this point as to what needs to be done to get the compiler to look at libirc instead of or after libifcoremt when looking for this symbol. I thought that this is where the linking came in, and I could establish that with an appropriate command through the Unix command line. Is it instead something that needs to be passed to the excutable when calling on the compiler? Again, I apologize for my cluelessness, but I just recently inherited this machine/project, and I've never used a Linux machine before this.

Thanks,

Austin

[Steven_L_Intel1]

You should use the ifort command to do the linking. Normally, both libifcoremt and libirc are used.

[faughta]

I've managed to find the linking commands within MATLAB's mex function, and I linked with the path to the libraries (-L/opt/intel/composer_xe_2011_sp1.8.273/compiler/lib/intel64) followed by the libraries to be linked (-lifcoremt -lirc). This doesn't seem to fix the problem as when executing the mex file I'm still getting the error message that there is an undefined symbol within libifcoremt.so.5: _intel_sse2_strcat. As I mentioned I've confirmed that strcat is not defined within libifcoremt.so.5 through use of the grep command and that it is defined in libirc.so. If I have linked both of these libraries during compiling why does 1) The mex file attempt to find strcat in libifcoremt.so.5 2) It not look at libirc after failing to find the symbol in libifcoremt 3) If a path to the intel libraries is provided, shouldn't this be sufficient for the compiler to link all libraries within the specified path? Is there a header within a file somewhere that instructs which libraries should be searched for specific symbols? If so I feel like I should be able to change something within this part to point to libirc instead of libifcoremt when looking up strcat. Thanks again for all help and attention and I apologize if this is an error relating to the MATLAB end of my work.

Note: The full linking portion of the command would be: -L/opt/intel/composer_xe_2011_sp1.8.273/compiler/lib/intel64 -lm -lifcoremt -lirc