new libtool breaks nagfor

[ohl]

The following is new:

/bin/sh ../libtool   --mode=link /opt/NAG/5.2/686/bin/nagfor  -O0 -gline -f2003 -C=all -pg   -o libomega_core.la -rpath /home/ohl/physics/omega/_inst_nag/lib/omega kinds.lo constants.lo omega_spinors.lo omega_bispinors.lo omega_vectors.lo omega_vectorspinors.lo omega_tensors.lo omega_couplings.lo omega_spinor_couplings.lo omega_bispinor_couplings.lo omega_polarizations.lo omega_polarizations_madgraph.lo omega_tensor_polarizations.lo omega_vspinor_polarizations.lo omega_utils.lo omega95.lo omega95_bispinors.lo   
libtool: link: /opt/NAG/5.2/686/bin/nagfor -shared  .libs/kinds.o .libs/constants.o .libs/omega_spinors.o .libs/omega_bispinors.o .libs/omega_vectors.o .libs/omega_vectorspinors.o .libs/omega_tensors.o .libs/omega_couplings.o .libs/omega_spinor_couplings.o .libs/omega_bispinor_couplings.o .libs/omega_polarizations.o .libs/omega_polarizations_madgraph.o .libs/omega_tensor_polarizations.o .libs/omega_vspinor_polarizations.o .libs/omega_utils.o .libs/omega95.o .libs/omega95_bispinors.o     -pg   -soname libomega_core.so.0 -o .libs/libomega_core.so.0.0.0
NAG Fortran Compiler Release 5.2(686)
Option warning: Unrecognised option -shared passed to loader
Option warning: Unrecognised option -soname passed to loader
gcc: libomega_core.so.0: No such file or directory
gcc: unrecognized option '-soname'
make[1]: *** [libomega_core.la] Error 1
make[1]: Leaving directory `/scratch/ohl/omega/_build_nag/src'

Apparently, nagfor doesn't like -soname and libtool started to insist on using it. Unlike -shared, it can not be ignored, because it takes an argument.

I've never had this before. It must have happened while I was hacking the cache files and building w/gfortran exclusively. The log entries for r1549 and r1550 look suspicious.

[ohl]

Comparing with r1548, it appears that

-soname libomega_core.so.0

should be replaced by

-Wl,-Wl,,-soname -Wl,-Wl,,libomega_core.so.0

Gotta hunt it down in libtool .

[Juergen Reuter]

The last fact makes me a little bit suspicious whether this could be the same problem as Ticket #135!?!?!?

[ohl]

Fixed in r1566: r1549 had thrashed WK's nagfor support which was fixed in r1550 only in the main package, not in the omega subdirectory.

Closing the ticket.

[sschmidt]

compilation with nagfor stops with the error maessage given in the first post

Option warning: Unrecognised option -shared passed to loader
Option warning: Unrecognised option -soname passed to loader

in case nagfor is not executed as nagfor but using any other name, e.g. I have a script called nagfo

#!/bin/bash

nagfor "$@"

in my ~/bin directory and trying to compile with FC=nagfo gives the aforementioned error. (Renaming gfortran in an anlogously works, so I hope I'm not doing any bash related errors.) The corresponding config.log files look different.

[sschmidt]

interesting part of the diff of the two log files

[Christian Speckner]

I'm pretty sure this is no defect but broken by design: libtool identifies the compiler by the executable name and substitutes arguments as necessary; renaming the compiler bypasses this mechanism. Renaming works with gfortran only because it doesn't need any replacements. I would suggest to close this as wontfix.

[kilian]

I agree. Currently any compiler starting with nagfor (nagfor, nagfor-foo, nagfor.MINE) will be identified as nagfor. I see no way to improve this, closing the ticket again.

[Juergen Reuter]

Milestone v2.0.0final deleted