undefined reference to `_Locksyslock' and `_intel_fast_memcmp'

[Robert_M_Intel4]

I am involved in developing a product (ATOM) that when used runs gnu or icc to compile a user's portion of a binary instrumentation tool. Not that important, but relevant in that we must build a driver and runtime, and provide a .o wrapper that is linked with the user's code.

We have been using icc 8.066 successfully, but I'm having trouble "supporting" 8.1. Two problems (that I am aware of :o)

Undefined references to _Locksyslock and _Unlocksyslock

This I believe is because the product that we ship is built with 8.0. The BOM includes a .o (with the entry point main - see output below) and many libraries that the 8.1 user must link with when they compile their component with 8.1. This error first appeared as an error in "main", which is shipped as a .o that is a wrapper for the user-written and compiled code. As I re-build portions of what we ship with 8.1, these undefined errors move to the next library it seems. So if I build the main wrapper routine with 8.1, the sametwo errors occur in one of our libraries. WhenI build that one with 8.1, it moves to the next. I've tried many scenarios with PATH and LD_LIBRARY_PATH at the user's compilation time, but this just seems to be an incompatibility between 8.0 and 8.1 objects. Is this true? Can 8.0 compiled .so's be used to link with 8.1 objects and .so's?

Undefined reference to _intel_fast_memcmp

I've read about this in the compiler's release notes in the past. We have seen this in the past when not using icpc to link things. We've left ld behind due to this and have not seen this problem re-appear until now. The odd thing is that the undefined reference comes from libcprts.so.5 in the 8.1 libraries. I've changed LD_LIBRARY_PATH around so that the 8.1 libraries are first but this does not seem to matter. (Note that we ship some Intel libraries with the product because we need them and we want to be able to run on systems that do not have the Intel compiler on them. So, there is kindof a battle here between the icc libraries that we ship (8.0) and the ones on an 8.1 user's system (8.1).

I don't know where libcprts.so.5 is being brought into the action here, and since it is, it is being found in /opt/intel_cc_81/lib, which is also where libirc.a is, which has this entry in the 8.1 version. 8.0's libirc.a is missing this entry.

So, it seems like I am getting the 8.1 version of libcprts.so.5 in with the reference, but getting the 8.0 version of libirc.a in that does not have the definition.

Not sure if that makes much sense, but am at the "hair on fire" stage here. This is the output.

Thanks.

Bob Mance

nht7311 remance >atom hello ptrace.c ptrace.**bleep**.c -v -vmore -clearcache

icc -shared -c -I /home/nsl/remance/AtomDiricc-7311/include -o /tmp/atomrENstM/ptrace.o ptrace.c -v

Version 8.1
/opt/intel_cc_81/bin/mcpcom -_g -mP3OPT_inline_alloca -D__HONOR_STD -D__ICC=810 -D__INTEL_COMPILER=810 -D__INTEL_COMPILER_BUILD_DATE=20040803 "-_Asystem(unix)" -D__ELF__ "-_Acpu(i386)" "-_Amachine(i386)" -D__PTRDIFF_TYPE__=int -D__SIZE_TYPE__=unsigned "-D__WCHAR_TYPE__=long int" "-D__WINT_TYPE__=unsigned int" -D__OPTIMIZE__ -D__NO_MATH_INLINE S -D__NO_STRING_INLINES -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__NO_INLINE__ -D__extension__= -D__GXX_ABI_VERSION=102 -D__USER_LABEL_PREFIX__= -D__REGISTER_PREFIX__= -D__INTEL_RTTI__ -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -B -Dunix -Dlinux -D__i386 -D__i386__ -Di386 -_3 -_b -_W7 --mspp --gnu_version=323 -I/home/nsl/remance/AtomDiricc-7311/include -mP1OPT_version=810 -mP1OPT_print_version=FALSE -mP3OPT_use_mspp_call_convention -mCG_use_gas_got_workaround=F "-mGLOB_options_string=-I /home/nsl/remance/AtomDiricc-7311/include -long_double -shared -c -o /tmp/atomrENstM/ptrace.o -v" -mGLOB_cxx_limited_range=FALSE -mGLOB_as_output_backup_file_name=/tmp/iccPD5jBQas_ -mGLOB_machine_model=GLOB_MACHINE_MODEL_IA32_NONE -mIPOPT_obj_output_file_name=/tmp/atomrENstM/ptrace.o -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS -mGLOB_obj_output_file=/tmp/atomrENstM/ptrace.o -mP1OPT_source_file_name=ptrace.c ptrace.c
/opt/intel_cc_81/include
/opt/intel_cc_81/substitute_headers
/usr/include
rm /tmp/icc0b7XvNgas

rm /tmp/iccPD5jBQas_

rm /tmp/iccqiPMGTarg


icpc -shared /tmp/atomrENstM/ptrace.o -o /site/spt/usr4/remance/ptrace.so


icpc /home/nsl/remance/AtomDiricc-7311/bin/atommain.o /site/spt/usr4/remance/ptrace.so /home/nsl/remance/AtomDiricc-7311/lib/libatom.so -Qoption,ld,-v -L /home/nsl/remance/AtomDiricc-7311/lib -ldecoder -lencoder -lBistro_dll -lDebugInfo -lProject -o /site/spt/usr4/remance/ptrace.tool -v

Version 8.1
ld /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/crtbegin.o --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.2 -m elf_i386 -v -o /site/spt/usr4/remance/ptrace.tool /home/nsl/remance/AtomDiricc-7311/bin/atommain.o /site/spt/usr4/remance/ptrace.so /home/nsl/remance/AtomDiricc-7311/lib/libatom.so -L /home/nsl/remance/AtomDiricc-7311/lib -ldecoder -lencoder -lBistro_dll -lDebugInfo -lProject -Qy -L/opt/intel_cc_81/lib -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3 -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/../../.. -L/usr/lib -Bstatic -limf -Bdynamic -lm -Bdynamic -lstdc++ -Bdynamic -lgcc_s -Bstatic -lgcc -Bdynamic -lcxaguard -Bstatic -lirc -Bdynamic -lc -Bdynamic -lgcc_s -Bstatic -lgcc -Bstatic -lirc_s /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/crtend.o /usr/lib/crtn.o
GNU ld version 2.14.90.0.4 20030523
/home/nsl/remance/AtomDiricc-7311/bin/atommain.o(.gnu.linkonce.t._ZNSt7_LockitC9Ei+0x15): In function `main':
/opt/intel_cc_80/include/c++/xlocale:119: undefined reference to `_Locksyslock'
/home/nsl/remance/AtomDiricc-7311/bin/atommain.o(.gnu.linkonce.t._ZNSt7_LockitD9Ev+0x16): In function `main':
/opt/intel_cc_80/include/c++/ostream:81: undefined reference to `_Unlocksyslock'
/opt/intel_cc_81/lib/libcprts.so.5: undefined reference to `_intel_fast_memcmp'
Error: Problem building the instrumentation routine.
nht7311 remance >

[bjornw]

I just encountered the same problem testing out the 8.1 compiler linking against 8.0 compiled static libraries.

Seems like the _Locksyslock and the _Unlocksyslock functions lived in global namespace for the 8.0, but now live in std:: namespace.

8.1 compiler >

nm -C /opt/intel_cc_81/lib/libcprts.so.5|grep _Locksyslock
0005e80a T std::_Locksyslock(int)
00081690 d _ZSt12_Locksyslocki$$LSDA

8.0 compiler>

nm -C /opt/intel_cc_80/lib/libcprts.so.5|grep _Locksyslock
0005ba8a T _Locksyslock

[Robert_M_Intel4]

There has been confirmation on this from the compiler folks and they have a change in the works. Not sure about its ETA.

fwiw, one of my problems here, the undefined reference to _intel_fast_memcmp is resolved by using icpc (instead of icc) in the final linking step that links an 8.0 object, an 8.0 shared library and 8.1 shared libraries. Since we do not have the option of re-compiling our 8.0 components I also have to specify -cxxlib-icc in this final link on the 8.1 system to over-ride the new default that is in the 8.1 compiler (-cxxlib-gcc). When I do these two things the undefined reference to _intel_fast_memcmp goes away.

The undefined references to _Locksyslock and _Unlocksyslock remain. Duplication materials are available, along with this readme.

Code:

Duplication material for Tracker #
 
Bob Mance
603-886-7663
robert.mance@intel.com
 
This example illustrates a problem when linking objects built with icc 8.0, with  
objects built with icc 8.1.  The example mirrors what Intel ATOM does in terms of
what software is distributed with ATOM and what the ATOM user compiles and linkswith it.
 
The example looks long, but it's not.  Three simple steps:
 
1) An object file and a shared library are built on a system using
   icc 8.0.  These are built from C++ sources.
 
2) On a system using 8.1 a C program is compiled then linked to create a shared
   library.
 
3) Then, on the 8.1 system, the 8.0 object, the 8.0 shared library, and the 8.1
   shared library are linked to create an executable.
 
-------------------------------------------------------------------------------
 
In a directory icc-incompat:
 
main80.cpp      C++ program - will be compiled to an object with icc 8.0
 
GetStuff80.cpp  C++ program - will be compiled/linked to a shared libray
                              with icc 8.0
 
instrument81.c  C program   - will be compiled/linked to a shared library
                              with icc 8.1
 
build-80        Script used to build the 8.0 components
build-81-good   Script used to build the 8.1 components that works
build-81-bad    Script used to build the 8.1 components that does not work
 
-------------------------------------------------------------------------------
nht7311 iccbug >cat /etc/motd
nht7311
redhat-release-3AS-1
Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
 
nht7311 icc-incompat >icc -V
Intel C++ Compiler for 32-bit applications, Version 8.0   Build 20040122Z Package ID: l_cc_pc_8.0.059
Copyright (C) 1985-2004 Intel Corporation.  All rights reserved.
 
nht7311 remance >icc -V
 Intel C++ Compiler for 32-bit applications, Version 8.1    Build 20040803Z Package ID: l_cc_p_8.1.021
Copyright (C) 1985-2004 Intel Corporation.  All rights reserved.
 
-------------------------------------------------------------------------------
 
To duplicate the problem:
 
 
1) On a system with icc 8.0 installed in /opt/intel_cc_80, run the build-80
   script.  The output we are looking for is one object file and one shared library.
 
    echo $LD_LIBRARY_PATH
    ./:/opt/intel_cc_80/lib
    icc -v
    Version 8.0
 
    
main80.cpp       -->  icc  --------------->  main80.o
 
    GetStuff80.cpp   -->  icc  -->  GetStuff80.o
    GetStuff80.o     -->  icc  --------------->  lib80.so
 
2) On a system with icc 8.1 installed in /opt/intel_cc_81, run the build-81-bad
   script.  The output we are interested in is one shared library that is created.
 
   The script then attempts to create an executable called 'tool81' by
   linking the shared library created with the 8.0 object file and shared library
   created in the build-80 script.
 
    echo $LD_LIBRARY_PATH
    ./:/opt/intel_cc_81/lib
    icc -v
    Version 8.1
 
    instrument81.c   -->  icc  -->  instrument81.o
    instrument81.o   -->  icc  --------------->  instrument81.so
 
                           -----------
    main80.o         -->  |          |
    instrument81.so  -->  |    icc   |   --------------->  tool81
    lib80.so         -->  |          |
                           -----------
 
    This is what the failed output looks like when run on EL3.0:
 
    >./build-81-bad
    main80.o(.gnu.linkonce.t._ZNSt7_LockitC9Ei+0x15): In function `main':
    /opt/intel_cc_80/include/c++/xlocale:119: undefined reference to `_Locksyslock'
 main80.o(.gnu.linkonce.t._ZNSt7_LockitD9Ev+0x16): In function `main':
    /opt/intel_cc_80/include/c++/ostream:452: undefined reference to `_Unlocksyslock'
    /opt/intel_cc_81/lib/libcprts.so.5: undefined reference to `_intel_fast_memcmp'
 
    This is what the failed output looks like when run on RH7.3:
 
    main80.o: In function `main':
    /site/spt/usr4/remance/icc-incompat/main80.cpp:16: undefined reference to `_Locksyslock'
    /site/spt/usr4/remance/icc-incompat/main80.cpp:16: undefined reference to `_Unlocksyslock'
 
3) Repeat this using the script build-81-good.  build-81-good succeeds in
   creating the 'tool81' file.
 
   The only difference in the good and bad scripts is that the good script
   includes a -L /opt/intel_cc_80/lib -lcprts switch on the linking command
   line.  This directs the linker to pick up libcprts from the 8.0 icc library
   rather than from the 8.1 icc library.
 
   Running the successfully built tool should echo argc/argv:
 
>tool81 this is a test
Test to show possible 8.0 and 8.1 binary incompatibility.
This is argc and argv:
   
argc    is 5
argv[0] is tool81
argv[1] is this
argv[2] is is
argv[3] is a
argv[4] is test
 
 
Note that the contents of LD_LIBRARY_PATH does not seem to affect the behavior
of the linker.  The bad scripts fails with LD_LIBRARY_PATH contains
/opt/intel_cc_80/lib and when it contains /opt/intel_cc_81/lib.
 
-------------------------------------------------------------------------------
build-80
-------------------------------------------------------------------------------
 
#!/bin/csh
#
# Build the icc 8.0 components.
#
# Compile the main wrapper routine to be distributed
#
icc -shared -c -g -o main80.o main80.cpp
#
#
#
# Compile the library to be distributed
#
icc -shared -c -g -o GetStuff80.o GetStuff80.cpp
icc -shared       -o lib80.so     GetStuff80.o
 
-------------------------------------------------------------------------------
build-81-good
-------------------------------------------------------------------------------
 
#!/bin/csh
#
# Build the icc 8.1 components.
# This build works because of the addition of -L /opt/intel_cc_80/lib -lcprts
#
# Build the user's instrument routine to be linked with the 8
.0 components.
#
icc -shared -c -o instrument81.o   instrument81.c
icc -shared    -o instrument81.so  instrument81.o
#
#
# Now link the distributed 8.0 object and shared library with the 8.1 shared library.
#
icpc main80.o instrument81.so lib80.so -o tool81 -cxxlib-icc -L /opt/intel_cc_80/lib -lcprts
 
-------------------------------------------------------------------------------
build-81-bad
-------------------------------------------------------------------------------
 
#!/bin/csh
#
# Build the icc 8.1 components.
# This build does not work.
#
# Build the user's instrument routine to be linked with the 8.0 components.
#
icc -shared -c -o instrument81.o   instrument81.c
icc -shared    -o instrument81.so  instrument81.o
#
#
# Now link the distributed 8.0 object and shared library with the 8.1 shared library.
#
icpc main80.o instrument81.so lib80.so -o tool81 -cxxlib-icc
 
-------------------------------------------------------------------------------
main80.cpp
-------------------------------------------------------------------------------
  
#include 
#include 
#include 
#include 
#include 
using std::cout;
using std::endl;
  
extern "C" void Instrument( int, char **, char * );
  
int main( int argc,   const char **argv )
{
    cout << "Test to show possible 8.0 and 8.1 binary incompatibility." << endl;  
    Instrument( argc, const_cast< char ** >(argv), "This is argc and argv:" );
  
    try
    {
  
        if( argc < 1 )
        {
            printf("Uhh, that's impossible." );
            throw( "Cant_happen" );
        }
  
    }
  
    catch (const char *func)
    {
        printf( "The impossible error has happened, again." );
    }
  
    return (0);
}
-------------------------------------------------------------------------------
GetStuff80.cpp
-------------------------------------------------------------------------------
#include 
  
extern "C" void GetStuff();
  
void GetStuff()
{
        return;
}
-------------------------------------------------------------------------------
instrument81.c
-------------------------------------------------------------------------------
#include 
#include 
#include 
#include 
#include 
using std::cout;
using std::endl;
  
extern "C" void Instrument( int, char **, char * );
  
int main( int argc,   const char **argv )
{
    cout << "Test to show possible 8.0 and 8.1 binary incompatibility." << endl;  
    Instrument( argc, const_cast< char ** >(argv), "This is argc and argv:" );
  
    try
    {
  
        if( argc < 1 )
        {
            printf("Uhh, that's impossible." );
            throw( "Cant_happen" );
        }
  
    }
  
    catch (const char *func)
    {
        printf( "The impossible error has happened, again." );
    }
  
    return (0);
}
-------------------------------------------------------------------------------
GetStuff80.cpp
-------------------------------------------------------------------------------
#include 
  
extern "C" void GetStuff();
  
void GetStuff()
{
        return;
}
-------------------------------------------------------------------------------
instrument81.c
-------------------------------------------------------------------------------
#include 
  
extern  void GetStuff();
  
void Instr
ument( int argc, char **argv, char * message )
{
    int i;
  
    GetStuff();
  
    printf( message );
    printf( "
 
" );
    printf("argc    is %d 
", argc);
  
    for ( i = 0; i < argc;  i++ )
        printf( "argv[%d] is %s
", i, argv );
    printf( "
" );
    return;
}
-------------------------------------------------------------------------------

[Intel_C_Intel]

I get this problem in a much simpler case. This is a simple test
program I wrote to test formatting with std::ostringstream. When I
compile it like this:

icpc stltest2.cpp -o stltest2 -cxxlib-icc

I get this output when I run it:

./stltest2
./stltest2: relocation error: ./stltest2: undefined symbol: _ZSt12_Locksyslocki

If I instead compile without the "-csslib-icc" option:

icpc stltest2.cpp -o stltest2

It works:

./stltest2
"1.23457" "4.34535e+07" "43453451.2434"
min=-2147483647
max=2147483647
diff=4294967294
val1=1
i=0
i=1
i=2
i=3
i=4
i=5
i=6
i=7
i=8
i=9

But, if I try to use a hash_map by adding #include to
stltest2.cpp, I get this:

icpc stltest2.cpp -o stltest2
stltest2.cpp(10): catastrophic error: could not open source file "hash_map"
#include

It will still compile with the -cxxlib-icc flag:

icpc stltest2.cpp -o stltest2 -cxxlib-icc

But it still gets the runtime error:

./stltest2
./stltest2: relocation error: ./stltest2: undefined symbol: _ZSt12_Locksyslocki

I'm testing this stuff on a Linux Red Hat 9 installation with icc 8.1.

icc -V
Intel C++ Compiler for 32-bit applications, Version 8.1 Build 20041019Z Package ID: l_cc_pu_8.1.024
Copyright (C) 1985-2004 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY

uname -a
Linux localhost.localdomain 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 i686 i386 GNU/Linux

gcc --version
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For now, I'm switching back to intel 8.0.

-Bob

[Intel_C_Intel]

I tried the same test on a machine running RHEL instead of
RH 9, and it works. That is, compiling like this:

icpc stltest2.cpp -o stltest2 -cxxlib-icc

works fine and gets no _ZSt12_Locksyslocki error.

The machine where it works is this:

cat /proc/version
Linux version 2.4.21-20.0.1.ELsmp (bhcompile@tweety.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47)) #1 SMP Wed Nov 24 20:34:01 EST 2004

Any ideas?

-Bob