ports/85513: Intel C++ compiler not 100% binary compatible with system compiler
Bradley T Hughes
bhughes at trolltech.com
Wed Aug 31 09:00:29 UTC 2005
>Number: 85513
>Category: ports
>Synopsis: Intel C++ compiler not 100% binary compatible with system compiler
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Aug 31 09:00:27 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator: Bradley T Hughes
>Release: 6.0-BETA3
>Organization:
Trolltech AS
>Environment:
FreeBSD reticent.troll.no 6.0-BETA3 FreeBSD 6.0-BETA3 #2: Mon Aug 29 09:25:17 CEST 2005 root at reticent.troll.no:/usr/obj/usr/src/sys/RETICENT i386
>Description:
The Intel C++ compiler is supposed to be 100% binary compatible with gcc 3.4. However, this isn't the case in one specific situaion: if a shared library is compiled with the Intel compiler, an app linked with the library and then run-time linked with a library build with g++, the dynamic linker can't find the __intel_cpu_indicator symbol.
>How-To-Repeat:
Download, and untar http://trolls.troll.no/bhughes/icpc_bug4.tar.gz. In the icpc_bug4 directory, type 'make' - this will build libgo.so using icc, then build and link app with the icc version of libgo.so, then it removes and rebuids libgo.so with g++.
>Fix:
If it was possible to link with the libimf.so library shipped with the intel compiler, the problem would be solved, but we used the static version, and the link places the __intel_cpu_indicator symbol in the shared library instead of the executable. One possible solution would be to have a small shared library that defines the __intel_cpu_indicator symbol, and link that before the static libimf.a library.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list