Bug #18776 icc library dependencies in ia64 mysql RPMs
Submitted: 4 Apr 2006 16:44 Modified: 4 Jul 2007 1:31
Reporter: Hartmut Holzgraefe Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S2 (Serious)
Version:4.1.18, 5.0.30, 5.0.32 OS:Linux (linux)
Assigned to: Kent Boortz CPU Architecture:Any
Tags: bfsm_2007_02_01, bfsm_2007_04_05, bfsm_2007_05_31

[4 Apr 2006 16:44] Hartmut Holzgraefe
Description:
The 4.1.18 RPMs are compiled using the Intel icc compiler,
when trying to compile PHP using gcc configure fails with
several 

  undefined reference to `?1__serial_memmove'

linker errors in the mysqli tests.

Configure can be fixed by prepending it with

  LDFLAGS='-L/opt/intel/cc/9.0/lib/ -lirc' LIBS='-L/opt/intel/cc/9.0/lib/ -lirc' configure ...

but then the final linking stage once again fails with the
same errors and requires direct Makefile editing to resolve
(which is a problem with the library order generated by PHP
configure)

So compiling PHP with mysqli support one needs the libirc.a 
library from the icc distribution for ?1__serial_memmove
and also needs to manually specify it in several places

How to repeat:
see above

Suggested fix:
remove libirc.a dependency from libmysqlclient.a
[25 Sep 2006 9:08] Valeriy Kravchuk
Bug #22637 was marked as a duplicate of this one. Is it for IA64 only, or fall all build that use ICC?
[5 Jun 2007 15:55] Heinz Bast
The Intel compiler for all platforms ( that is including IA64) offers a switch -i_static to link in statically all objects from libraries provided by Intel while all the rest is linked dynamically. The name of the switch is being renamed to -static-intel in the coming (June 2007) 10.0 release but -i-static will be continue to be accepted for some time. 
Using -i_static will prevent to have any dependencies to Intel libraries. For MySQL this includes the mysqld-daemon, the clients and even the libraries like libmysqlclient.so. Thus this will 100% solve the issue described here and there is nothing left to be done regarding a compiler change. 

However: MySQL is using 'libtool' for all linking steps. This tools 'swallows' the  -i-static switch and thus some care has to be taken to make sure, the switch is passed to all link-steps. I tested successfully two workarounds:

1. Use -i-static as part of the compiler name.s That is :

CC="icc -i-static" \
CFLAGS="-O2 -g" \
CXX="icpc -i-static" \
CXXFLAGS="-O2 -g" \
./configure --prefix=xxx \
            --enable-thread-safe-client ... ( etc - as usual)

2. Change 'libtool' to not remove this option. MySQL 'configure' generates the 'libtool' command from file  ltmain.sh. In this step, the change should be integrated. For release 1.5.22 ( part of MySQL 5.0.41) the diff looks like:
1602a1603,1609
>      -static-intel|-i_static)
>       compile_command="$compile_command $arg"
>       compiler_flags="$compiler_flags $arg"
>       finalize_command="$finalize_command $arg"
>       continue
>       ;;

In this case, the configure call can use LDFLAGS similar to:

CC="icc" \
CFLAGS="-O2 -g" \
CXX="icpc" \
CXXFLAGS="-O2 -g" \
LDFLAGS="-i-static" \
./configure ....

Even better would be to get this permanently changed in the next libtool distributions. 

Anyway - I think one of the workarounds can easily be used in particular for the  official distributions of MySQL. This will avoid the problems described above. In this context, I don't see anything left to be done from Intel's side.
[6 Jun 2007 18:45] Joerg Bruehe
This issue is solved.

The dependency on the Intel runtime libraries existed in the 
"shared-*" RPMs for the ia64 CPU of some versions of MySQL 4.1
(4.1.16, 4.1.20, and 4.1.22).

From there, it had propagated into the ia64 "shared-compat" RPMs 
of MySQL versions 5.0.30sp1 and 5.0.32.

By now, this has been fixed,
and the upcoming 4.1.23 RPMs for ia64 will not have this dependency.
[4 Jul 2007 1:31] Paul DuBois
Noted in 4.1.23 changelog.

A dependency on the Intel runtime libraries existed in the shared-xxx
RPMs for the IA-64 CPU of some versions of MySQL 4.1 (4.1.16, 4.1.20,
and 4.1.22). This has been resolved.