>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@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:
_______________________________________________
freebsd-ports-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe@freebsd.org"