Project

General

Profile

Bug #1165

avoid -lm with Intel compiler

Added by Jim Phillips almost 3 years ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Machine Layers
Target version:
Start date:
08/16/2016
Due date:
% Done:

0%


Description

It is advised to not explicitly link to -lm with the Intel compiler as this may override the faster Intel math library. Currently charmc automatically adds -lm to the end of every link line. This should be moved to the compiler-specific files so that it can be included for gcc (where it is needed) but not for Intel (where it is not).

History

#1 Updated by Eric Bohm almost 3 years ago

  • Assignee set to Garima Lalwani

#2 Updated by Phil Miller almost 2 years ago

  • Assignee changed from Garima Lalwani to Phil Miller

With some changes from a Charmworks intern, Ani, coming down the pike, this gets much easier to accommodate - we'll have all of the gcc-using builds described by a common cc-gcc.sh, and the same for others.

#3 Updated by Phil Miller over 1 year ago

  • Assignee changed from Phil Miller to Evan Ramos

#4 Updated by Evan Ramos over 1 year ago

  • Status changed from New to In Progress

https://charm.cs.illinois.edu/gerrit/3477 is the first half of a fix for this, removing `-lm` from link line. However, the patch was validated by testing in this state. What is a case where the build should fail without `-lm` and with a compiler other than Intel's?

#5 Updated by Jim Phillips over 1 year ago

You would need to link something that calls a math function in libm such as sin, cos, etc.

#6 Updated by Jim Phillips over 1 year ago

Doing a little experimenting, I only see the link error for gcc on a C file, not for g++ on a C++ file:

jim@tulsa$cat foo.c

#include <math.h>

int main(int argc, char **argv) {

  double a;
  a = sin(argc);
  return (int)a;

}

jim@tulsa$diff foo.c foo.C
jim@tulsa$gcc foo.c
/tmp/cc6J8Dby.o: In function `main':
foo.c:(.text+0x15): undefined reference to `sin'
collect2: error: ld returned 1 exit status
jim@tulsa$gcc foo.c -lm
jim@tulsa$g++ foo.C
jim@tulsa$g++ foo.C -lm

#7 Updated by Evan Ramos over 1 year ago

Jim Phillips wrote:

Doing a little experimenting, I only see the link error for gcc on a C file, not for g++ on a C++ file:

Confirmed. Trying the same test with ICC, the build succeeds with or without `-lm`. More interestingly, the resulting binaries are identical.

$ icc -v
icc version 18.0.0 (gcc version 4.9.4 compatibility)
$ icc foo.c -lm -o foo_lm
$ icc foo.c -o foo
$ cmp foo foo_lm
$ echo $?
0
$ ldd foo
    linux-vdso.so.1 =>  (0x00002af75fb12000)
    libm.so.6 => /lib64/libm.so.6 (0x00002af75fd15000)
    libgcc_s.so.1 => /usr/local/gcc/gcc-4.9.4/lib64/libgcc_s.so.1 (0x00002af75ff99000)
    libc.so.6 => /lib64/libc.so.6 (0x00002af7601b1000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002af760545000)
    /lib64/ld-linux-x86-64.so.2 (0x00002af75faf2000)

This is on iForge (the only access I have to ICC) and I have not found a way to completely remove gcc from $PATH. I have no idea if that makes a difference here.

Is there anything else that could be affecting my result?

#8 Updated by Jim Phillips 7 months ago

This may have been old advice. Intel's meager docs say to use mathifm.h and even then I need -limf to get any Intel libraries to show up in ldd.
Go ahead and drop this.

#9 Updated by Evan Ramos 7 months ago

Does the presence of -lm on the command line interfere with -limf? If not, I'll drop this issue and the patch I started.

#10 Updated by Jim Phillips 7 months ago

It's really hard to tell. Does the -lm get inserted before or after the user-provided libraries? Assuming first-match if the -lm comes last it shouldn't matter. How can you tell which version was linked?

#11 Updated by Evan Ramos 7 months ago

  • Target version set to 6.9.1
  • Status changed from In Progress to Resolved

First-match of libraries on the link line is my understanding.

I think the math library in use can be determined by which comes first in the output of ldd, and it definitely can by breaking on a math function in GDB.

-lm first:

$ gcc foo.c -g -L/usr/local/intel-2018-U3/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin/ -lm -limf
$ ldd ./a.out 
    linux-vdso.so.1 =>  (0x00007ffd4bbfc000)
    libm.so.6 => /lib64/libm.so.6 (0x00002b7f792e7000)
    libimf.so => /usr/local/intel-2018-U3/lib/intel64/libimf.so (0x00002b7f7956b000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b7f79aff000)
    libintlc.so.5 => /usr/local/intel-2018-U3/lib/intel64/libintlc.so.5 (0x00002b7f79e93000)
    /lib64/ld-linux-x86-64.so.2 (0x000055601fbe2000)
$ gdb ./a.out 
GNU gdb (GDB) 7.12
...
Reading symbols from ./a.out...done.
(gdb) b sin
Breakpoint 1 at 0x4005c0
(gdb) r
Starting program: ./a.out 

Breakpoint 1, 0x00002aaaaacea750 in sin () from /lib64/libm.so.6

-limf first:

$ gcc foo.c -g -L/usr/local/intel-2018-U3/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin/ -limf -lm
$ ldd ./a.out 
    linux-vdso.so.1 =>  (0x00007ffe391d2000)
    libimf.so => /usr/local/intel-2018-U3/lib/intel64/libimf.so (0x00002b38b5778000)
    libm.so.6 => /lib64/libm.so.6 (0x00002b38b5d34000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b38b5fb9000)
    libintlc.so.5 => /usr/local/intel-2018-U3/lib/intel64/libintlc.so.5 (0x00002b38b634d000)
    /lib64/ld-linux-x86-64.so.2 (0x000056493c161000)
$ gdb ./a.out 
GNU gdb (GDB) 7.12
...
Reading symbols from ./a.out...done.
(gdb) b sin
Breakpoint 1 at 0x4005a0
(gdb) r
Starting program: ./a.out 

Breakpoint 1, 0x00002aaaaaceed80 in sin () from /usr/local/intel-2018-U3/lib/intel64/libimf.so

It looks like libraries manually specified to charmc are added to the link line before -lm, so it should work. Marking this resolved.

Also available in: Atom PDF