icpc generates invalid symbol

[ed_rosenbloom]

I am using icpc 11.1.073. I have seen this same behavior with other versions as well. In my cross compilation env, building for SLES11 SP1, icpc generates the following symbol:  _ZNSi5seekgElSt12_Ios_Seekdir 

I link w/ libstdc++ and all is well.

If I use the same compiler and build for RHEL 6.2.0, icpc generates the following symbol for the same source code:

_ZNSi5seekgExSt12_Ios_Seekdir. 

This symbol is not found in libstdc++.  Strangely, this definition is used in the 32bit version of libstdc++.

All compilation is done for 64-bit output.

Any ideas what might cause this discrepancy?

[Shenghong_G_Intel]

Hi,

if you de-mangle the names, you may see the differences:

$ c++filt _ZNSi5seekgExSt12_Ios_Seekdir
std::basic_istream<char, std::char_traits<char> >::seekg(long long, std::_Ios_Seekdir)
$ c++filt _ZNSi5seekgElSt12_Ios_Seekdir
std::basic_istream<char, std::char_traits<char> >::seekg(long, std::_Ios_Seekdir)
$

It looks more like to be an issue in your std::iostream (guess from the function names...) header, make sure your headers and libraries in your cross environment matches. I guess the issue is not Intel compiler specific.

Let me know if you have more issues.

Thanks,

Shenghong

[Shenghong_G_Intel]

More information:

$ cat temp.cpp
#include <iostream>

void foo(long long) {
}

void bar(long) {
}

int main() {
        std::cout<<sizeof(long)<<std::endl;
        std::cout<<sizeof(long long)<<std::endl;
        return 0;
}
$ g++ temp.cpp
$ nm a.out | grep foo
00000000004008d4 t _GLOBAL__sub_I__Z3foox
0000000000400840 T _Z3foox
$ nm a.out | grep bar
000000000040084a T _Z3barl
$ icpc temp.cpp
$ nm a.out | grep foo
0000000000400db0 T _Z3foox
$ nm a.out | grep bar
0000000000400dc0 T _Z3barl
$ ./a.out
8
8
$

You'll see the "x" means "long long", and "l" means "long", which has the same differences with your cases...So, I guess your issue is because, your header file and your libstdc++ lib file does not match itself, please double confirm with your vendor who provides the "SDKs" for your cross environment.

Thanks,

Shenghong

[ed_rosenbloom]

I ran your sample program - the symbols generated are the same using both gcc and icc for foo* and bar*.

Here is the line in my code that is causing the problem:

 stream.seekg(0, std::ios::beg); // Set stream position to beginning

under g++:

 nm CollselExtension.o |grep Ios_Seek | c++filt
                 U std::basic_istream<char, std::char_traits<char> >::seekg(long, std::_Ios_Seekdir)

under icpc:

nm CollselExtension.o |grep Ios_Seek | c++filt
                 U std::basic_istream<char, std::char_traits<char> >::seekg(long long, std::_Ios_Seekdir)

as you can see, the same line of code generates different symbols.

the env:  gcc 4.4.7/  icpc 11.1.073

under this env the code works fine in either case:

gcc 4.3.4 /  icpc 11.1.073

[Shenghong_G_Intel]

Thank you for the information, but as you see that it works differently with different GCC version (providing different headers). Intel compiler does not provide this fstream header, so all depends on what you have. It "works" with gcc4.3.4, maybe because the header in that file have a proptype of "long long", which is just same with the libstdc++.so you have....

As I said, this seems like not related to compiler issue, instead, it may be something related to the "match" of the libstdc++ library and the libstdc++ header. As you mentioned you are using "cross-compile", could you let me know how you set up this cross compile environment? Using a "official SDK" or set all these by yourself? If possible, you may provide me your "cross-environment sdk" (package it and send it to me, I'll clarify more based on it. :)

By the way, Intel compiler in Intel Parallel Studio does not support cross-compile officially, instead, Intel System Studio is the correct product to do this. I am also interested on how you are using it for cross compile (make sure you are using cross-toolchains headers instead of your host system's, which may cause a conflict in header function proptype and cause the issue you have...)

Please provide more information on your environment. Thank you very much.

Thanks,

Shenghong

[Shenghong_G_Intel]

By the way, you may check with "-E" to generate preprocess file, to understand which header is used for the compilation, and check the proptype of seekg (long or long long). And compare it with the proptype in your libstdc++ (nm/objdump).

Thanks,

Shenghong