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.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.044 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.