Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Ralf Wildenhues]

* Vincent Lefevre wrote on Tue, Jun 24, 2008 at 03:19:25AM CEST:
> On 2008-06-23 20:00:43 +0200, Ralf Wildenhues wrote:
> > - put its $bindir early in PATH, or set LIBTOOLIZE=$bindir/libtoolize,
> 
> I did: export LIBTOOLIZE=$HOME/x86_64/libtool-snapshot/bin/libtoolize
> 
> >   and
> > - either add a line containing the path $libtool_prefix/share/aclocal to
> >   the file $automake_prefix/share/aclocal/dirlist,
> 
> I can't modify it.

One (non-cheap) alternative is to install Autoconf and Automake under
the same prefix as Libtool.

> >   or use 'libtoolize --install' to install libtool.m4 etc. into your
> >   project m4/ directory prior to running autoreconf,
> 
> Running
> 
>   $HOME/x86_64/libtool-snapshot/bin/libtoolize --install
> 
> just installs a symlink ltmain.sh to
> /home/vlefevre/x86_64/libtool-snapshot/share/libtool/config/ltmain.sh

Ah, sorry about that.  I somehow assumed your project uses something
like AC_CONFIG_MACRO_DIR([m4]) in configure.ac and
'ACLOCAL_AMFLAGS = -I m4' in Makefile.am.

> >   or set ACLOCAL="aclocal -I $libtool_prefix/share/aclocal".
> 
> I had already tried that manually, but I'm not sure this one solves
> the problem either:
> 
> $ export ACLOCAL="aclocal -I $HOME/x86_64/libtool-snapshot/share/aclocal"
> $ autoreconf
> /usr/share/aclocal/snacc.m4:24: warning: underquoted definition of 
> AM_PATH_SNACC
> /usr/share/aclocal/snacc.m4:24:   run info '(automake)Extending aclocal'
> /usr/share/aclocal/snacc.m4:24:   or see 
> http://sources.redhat.com/automake/automake.html#Extending-aclocal

The warning is harmless, unlike the rest:

> and aclocal.m4 still contains the libtool.m4 data from Debian's libtool.
> In fact it contains both:
> 
> # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
> 
> # serial 52 Debian 1.5.26-4 AC_PROG_LIBTOOL
> [...]
> # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
> #
> #   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
> # 2006, 2007, 2008 Free Software Foundation, Inc.
> [...]
> 
> Is that correct?

That looks wrong.  Hmm, weird.  Could be a bug in libtool.m4, I'd need
to test that.

> >   make check TESTSUITEFLAGS=-V TESTS=tests/sh.test VERBOSE=yes
> 
> /usr/bin/make  check-TESTS check-local
> make[3]: Entering directory `/home/vlefevre/software/libtool-2.2.5a'
> sh.test: ===  Running sh.test
> /home/vlefevre/software/libtool-2.2.5a/libltdl/config/ltmain.sh:3008: 
>if test $? -eq 0 && test -n "${func_to_host_path_tmp1}"; then
> use `test "$..."' instead of `test $'
> FAIL: tests/sh.test

OK thanks, will fix this (harmless) issue.

Cheers,
Ralf

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Vincent Lefevre]

On 2008-06-23 20:00:43 +0200, Ralf Wildenhues wrote:
> - put its $bindir early in PATH, or set LIBTOOLIZE=$bindir/libtoolize,

I did: export LIBTOOLIZE=$HOME/x86_64/libtool-snapshot/bin/libtoolize

>   and
> - either add a line containing the path $libtool_prefix/share/aclocal to
>   the file $automake_prefix/share/aclocal/dirlist,

I can't modify it.

>   or use 'libtoolize --install' to install libtool.m4 etc. into your
>   project m4/ directory prior to running autoreconf,

Running

  $HOME/x86_64/libtool-snapshot/bin/libtoolize --install

just installs a symlink ltmain.sh to
/home/vlefevre/x86_64/libtool-snapshot/share/libtool/config/ltmain.sh

>   or set ACLOCAL="aclocal -I $libtool_prefix/share/aclocal".

I had already tried that manually, but I'm not sure this one solves
the problem either:

$ export ACLOCAL="aclocal -I $HOME/x86_64/libtool-snapshot/share/aclocal"
$ autoreconf
/usr/share/aclocal/snacc.m4:24: warning: underquoted definition of AM_PATH_SNACC
/usr/share/aclocal/snacc.m4:24:   run info '(automake)Extending aclocal'
/usr/share/aclocal/snacc.m4:24:   or see 
http://sources.redhat.com/automake/automake.html#Extending-aclocal

and aclocal.m4 still contains the libtool.m4 data from Debian's libtool.
In fact it contains both:

# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-

# serial 52 Debian 1.5.26-4 AC_PROG_LIBTOOL
[...]
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
#
#   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
# 2006, 2007, 2008 Free Software Foundation, Inc.
[...]

Is that correct?

> * Vincent Lefevre wrote on Mon, Jun 23, 2008 at 01:07:53PM CEST:
> > Concerning the testsuite with icc (CC=icc ./configure), I get the
> > following failure (but this isn't related to icc):
> > 
> > FAIL: tests/sh.test
> 
> Please post output of
>   make check TESTSUITEFLAGS=-V TESTS=tests/sh.test VERBOSE=yes

/usr/bin/make  check-TESTS check-local
make[3]: Entering directory `/home/vlefevre/software/libtool-2.2.5a'
sh.test: ===  Running sh.test
/home/vlefevre/software/libtool-2.2.5a/libltdl/config/ltmain.sh:3008:   
 if test $? -eq 0 && test -n "${func_to_host_path_tmp1}"; then
use `test "$..."' instead of `test $'
FAIL: tests/sh.test

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Ralf Wildenhues]

* Vincent Lefevre wrote on Mon, Jun 23, 2008 at 10:26:45AM CEST:
> On 2008-06-23 07:25:59 +0200, Ralf Wildenhues wrote:
> > What I'd like to know is if mpfr works with patched Libtool, and how the
> > Libtool testsuite fares with icc (see README for how to invoke it).
> 
> I have installed the patched libtool from http://pogma.com/libtool/
> in my home directory, but I don't know how to tell autoreconf to
> use it instead of the system one.

- put its $bindir early in PATH, or set LIBTOOLIZE=$bindir/libtoolize,
  and
- either add a line containing the path $libtool_prefix/share/aclocal to
  the file $automake_prefix/share/aclocal/dirlist,
  or use 'libtoolize --install' to install libtool.m4 etc. into your
  project m4/ directory prior to running autoreconf,
  or set ACLOCAL="aclocal -I $libtool_prefix/share/aclocal".

Hope that helps.

* Vincent Lefevre wrote on Mon, Jun 23, 2008 at 01:07:53PM CEST:
> Concerning the testsuite with icc (CC=icc ./configure), I get the
> following failure (but this isn't related to icc):
> 
> FAIL: tests/sh.test

Please post output of
  make check TESTSUITEFLAGS=-V TESTS=tests/sh.test VERBOSE=yes

Thanks,
Ralf

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Vincent Lefevre]

On 2008-06-23 07:25:59 +0200, Ralf Wildenhues wrote:
> What I'd like to know is if mpfr works with patched Libtool, and how the
> Libtool testsuite fares with icc (see README for how to invoke it).

Concerning the testsuite with icc (CC=icc ./configure), I get the
following failure (but this isn't related to icc):

FAIL: tests/sh.test

1 of 114 tests failed
(10 tests were not run)

71 tests behaved as expected.
2 tests were skipped.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Vincent Lefevre]

On 2008-06-23 07:25:59 +0200, Ralf Wildenhues wrote:
> What I'd like to know is if mpfr works with patched Libtool, and how the
> Libtool testsuite fares with icc (see README for how to invoke it).

I have installed the patched libtool from http://pogma.com/libtool/
in my home directory, but I don't know how to tell autoreconf to
use it instead of the system one.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Ralf Wildenhues]

* Vincent Lefevre wrote on Mon, Jun 23, 2008 at 03:08:17AM CEST:
> 
> OK, finally I've just seen that on the other machine I mentioned
> (itanium), the old libtool was working, i.e. it selected -fPIC. If
> I understand the libtool code, libtool was selecting -KPIC only if
> the GCC test failed, and this would mean that this test was failing
> on x86_64 with icc 10.1 20080312.

What I'd like to know is if mpfr works with patched Libtool, and how the
Libtool testsuite fares with icc (see README for how to invoke it).

Thanks,
Ralf

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Vincent Lefevre]

On 2008-06-19 19:39:09 +0200, Ralf Wildenhues wrote:
> > Unfortunately I can't try the patch on the same machine because the
> > icc license has expired a few days ago (it was just an evaluation
> > version). However I have access to another machine with icc installed;
> > this is a different version, but it's also a version that doesn't
> > accept -KPIC, so I assume the test will be significant.
> 
> I've applied the patch with the above fixed now.  I'll find a system or
> a person to test this for me.

OK, finally I've just seen that on the other machine I mentioned
(itanium), the old libtool was working, i.e. it selected -fPIC. If
I understand the libtool code, libtool was selecting -KPIC only if
the GCC test failed, and this would mean that this test was failing
on x86_64 with icc 10.1 20080312. I was wondering why, and this is
because MPFR's configure.in unsets GCC if __ICC is defined (I don't
know why, I didn't write this code). It is defined on x86_64, but
not on itanium!!! The icc version is a bit older on itanium, but
this code was written on 2004-09-20 anyway.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Ralf Wildenhues]

* Vincent Lefevre wrote on Wed, Jun 18, 2008 at 11:32:08PM CEST:
> On 2008-06-18 22:31:49 +0200, Ralf Wildenhues wrote:
> > + icpc* )
> > +   # Intel C++, used to be incompatible with GCC.
> > +   # ICC 10 doesn't accept -KPIC any more.
> > _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> > _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
>   ^
> Shouldn't it be '-fPIC'?

Yes, thanks for proofreading.

> Unfortunately I can't try the patch on the same machine because the
> icc license has expired a few days ago (it was just an evaluation
> version). However I have access to another machine with icc installed;
> this is a different version, but it's also a version that doesn't
> accept -KPIC, so I assume the test will be significant.

I've applied the patch with the above fixed now.  I'll find a system or
a person to test this for me.

Cheers,
Ralf

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Vincent Lefevre]

Hi Ralf,

On 2008-06-18 22:31:49 +0200, Ralf Wildenhues wrote:
> diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
> index a2a4534..4a8d3e5 100644
> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -3703,8 +3703,15 @@ m4_if([$1], [CXX], [
>   _LT_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
>   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
>   ;;
> -   icpc* | ecpc* )
> - # Intel C++
> +   ecpc* )
> + # old Intel C++ for x86_64 which still supported -KPIC.
> + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
> + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
> + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
> + ;;
> +   icpc* )
> + # Intel C++, used to be incompatible with GCC.
> + # ICC 10 doesn't accept -KPIC any more.
>   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
>   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  ^
Shouldn't it be '-fPIC'?

Unfortunately I can't try the patch on the same machine because the
icc license has expired a few days ago (it was just an evaluation
version). However I have access to another machine with icc installed;
this is a different version, but it's also a version that doesn't
accept -KPIC, so I assume the test will be significant.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

[Ralf Wildenhues]

[  ]

Hello Vincent, and sorry for the slow reply,

* Vincent Lefevre wrote on Mon, Jun 09, 2008 at 02:45:11PM CEST:
> On 2008-06-09 14:24:00 +0200, Ralf Wildenhues wrote:
> > Sigh.  They can't even keep compatibility with their own compiler.
> > (IIRC at the point this code was introduced, -KPIC worked and -fPIC
> > didn't.)
> 
> Didn't they mark it as deprecated before being removed?

They did.  So?  What's the cost of Just Supporting It Indefinitely?
In this case, my guess is: close to zero.

If they didn't like -KPIC, why didn't they use -fPIC right from the
start?  (No need to answer, it's a long story, buying KCC and so on...)

See, even with them marking it as deprecated, and adding a warning
option and all, here, there's really no point in introducing
incompatible command line API changes.  I mean heck, ICC for years just
worked to emulate GCC's command line API, using such despicable
strategies such as ignoring unknown options matching '-f*' without an
error return:

> icpc: command line warning #10006: ignoring unknown option '-frpath'

but when it comes to their own, documented options, they introduce hard
failures.  That's just inconsistent in the extreme.

> icpc: error #10014: problem during multi-file optimization compilation
> (code 4)

That looks like you have a broken icpc installation.

Anyway, this is the patch I'd like to apply, plus put you in THANKS.
Please give it a whirl.

Thanks,
Ralf

2008-06-18  Ralf Wildenhues  <[EMAIL PROTECTED]>

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] :
Use -fPIC, newer Intel compilers (icc 10, ifort 9) reject -KPIC.
* tests/localization.at: Skip test if the compiler fails merely
due to the locale setting.
* THANKS: Update.
Report by Vincent Lefevre.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a2a4534..4a8d3e5 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3703,8 +3703,15 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
;;
- icpc* | ecpc* )
-   # Intel C++
+ ecpc* )
+   # old Intel C++ for x86_64 which still supported -KPIC.
+   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+   _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+   ;;
+ icpc* )
+   # Intel C++, used to be incompatible with GCC.
+   # ICC 10 doesn't accept -KPIC any more.
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
@@ -3974,12 +3981,15 @@ m4_if([$1], [CXX], [
 
 linux* | k*bsd*-gnu)
   case $cc_basename in
-  icc* | ecc*)
+  # old Intel for x86_64 which still supported -KPIC.
+  ecc*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
 ;;
-  ifort*)
+  # icc used to be incompatible with GCC.
+  # ICC 10 doesn't accept -KPIC any more.
+  icc* | ifort*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
diff --git a/tests/localization.at b/tests/localization.at
index 311aca7..d489fef 100644
--- a/tests/localization.at
+++ b/tests/localization.at
@@ -38,6 +38,10 @@ AT_DATA([b.c],
 [[int y;
 ]])
 
+# First see if setting a locale is accepted at all.
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c b.c || exit 77], [], [stdout], [stderr])
+
+# Find out about expected output.
 AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c || exit 1], [1], [stdout], [stderr])
 mv -f stdout expected-stdout
 mv -f stderr expected-stderr