Intel® Fortran Compiler for Mac OS*: $non_lazy_ptr unresolved references from linking

When linking an application on Mac OS* with the Intel® Fortran Compiler errors involving the $non_lazy_ptr ocurr.

This error is usually resolved by adding a -c to libtool (or ranlib if you use ar and ranlib to create the library) to include common symbols in the archives definitions table.

More details on the cause:

By default libtool (or ranlib if you use ar+ranlib) does not include
common symbols in archive's definitions table. This is documented behavior.
To link with common symbols defined in a library there
is -c option (works with ranlib as well).

Here is a part of man page for libtool:

  The following options pertain to the table of contents for  an  archive
       library, and apply to both libtool -static and ranlib:

   ...

       -c     Include  common symbols as definitions with respect to the table
              of contents.  This is seldom the intended behavior  for  linking
              from  a  library,  as  it forces the linking of a library member
              just because it uses an uninitialized global that  is  undefined
              at  that  point  in  the  linking.  This option is included only
              because this was the original behavior of ranlib.   This  option
              is not the default.


Below is a log which shows what the problem is.
First look at object symbol tables. We can see that
_lazyptr_private_mp_test1_ is a common symbol listed in lazyptr_private.o object's
symbol table.

$ nm *.o
 
lazyptr_private.o:
00000000 T _lazyptr_private._
00000010 C _lazyptr_private_mp_test1_
 
lazyptr_sub.o:
000000a0 s STRLITPACK_0.0
000000b4 d STRLITPACK_2.0.1
000000bc d STRLITPACK_3.0.1
         U _for_write_seq_lis
         U _for_write_seq_lis_xmit
         U _lazyptr_private_mp_test1_
00000000 T _test1sub_
 
lazyptr_test.o:
00000194 s LITPACK_0.0.2
0000019c s STRLITPACK_0.0
000001b0 d STRLITPACK_2.0.1
000001b8 d STRLITPACK_3.0.1
00000000 T _MAIN__
         U ___intel_new_proc_init_P
         U _for_set_reentrancy
         U _for_write_seq_lis
         U _for_write_seq_lis_xmit
         U _lazyptr_private_mp_test1_
000000f0 T _test1sub_


Table of contents of liblazyptr.a library built with libtool with default settings:

$ libtool  -o liblazyptr.a lazyptr_private.o lazyptr_sub.o                                                                                                   
$ otool -S liblazyptr.a -v
Archive : liblazyptr.a
Table of contents from: liblazyptr.a(__.SYMDEF SORTED)
size of ranlib structures: 16 (number 2)
size of strings: 32
object           symbol name
lazyptr_private.o _lazyptr_private._
lazyptr_sub.o    _test1sub_
$


When we add -c option to libtool _lazyptr_private_mp_test1_ symbol appears in
the library's table of contents:

$ libtool -c -o liblazyptr.a lazyptr_private.o lazyptr_sub.o
$ otool -S liblazyptr.a -v
Archive : liblazyptr.a
Table of contents from: liblazyptr.a(__.SYMDEF SORTED)
size of ranlib structures: 24 (number 3)
size of strings: 64
object           symbol name
lazyptr_private.o _lazyptr_private._
lazyptr_private.o _lazyptr_private_mp_test1_
lazyptr_sub.o    _test1sub_
$ libtool  -o liblazyptr.a lazyptr_private.o lazyptr_sub.o                                                                                                   
$ otool -S liblazyptr.a -v
Archive : liblazyptr.a
Table of contents from: liblazyptr.a(__.SYMDEF SORTED)
size of ranlib structures: 16 (number 2)
size of strings: 32
object           symbol name
lazyptr_private.o _lazyptr_private._
lazyptr_sub.o    _test1sub_


So to resolve problem just add -c option to libtool call in makefile.

有关编译器优化的更完整信息,请参阅优化通知