ICC compilation issues
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| igraph |
Fix Committed
|
Low
|
Gábor Csárdi | ||
Bug Description
Boyan Bejanov reported this issue:
I ran into some trouble compiling and installing the igraph package in linux (RHEL 5.8) using the Intel compiler collection (the Cluster Studio XE 2013). You are probably aware that there is a problem with the stpcpy() function. The man page for stpcpy says
“This function is not part of the ANSI or POSIX standards, and is not customary on Unix systems, but is not a GNU invention either. Perhaps it comes from MS-DOS. “
I know that stpcpy is provided by the glibc library and gcc is happy to provide a definition for it in string.h and to link it successfully. When the Intel compiler runs in gcc-compatibility mode, it fails to provide stpcpy (in my opinion, this is Intel’s problem, I will be e-mailing them shortly), although it manages to trick the preprocessor into thinking that this is the gnu compiler running, and so the compilation fails.
I modified the foreign-*-parser.c files to check explicitly for the Intel compiler. Specifically, in foreign-
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE
to
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE && !defined __INTEL_COMPILER
and identical one-line changes in the other foreign-*-parser.c files. With these changes the igraph package compiled and installed successfully.
...
I installed the latest version available on CRAN, R-2.15.3 and igraph_0.6.5-1.
...
| description: | updated |
| Changed in igraph: | |
| importance: | Undecided → Low |
| status: | New → Confirmed |
| assignee: | nobody → Gábor Csárdi (gabor.csardi) |
| milestone: | none → 0.7 |
| Gábor Csárdi (gabor.csardi) wrote | #1 |
| Changed in igraph: | |
| status: | Confirmed → Fix Committed |
| Gábor Csárdi (gabor.csardi) wrote Continue on github | #2 |
Fixed in 56e1baac51bd705
We cannot change the foreign-*-parser.c files because those are auto-generated. But that would be a good fix anyway, because ICC actually does provide a version of stpcpy, but does not provide a signature in the string.h header file (or anywhere else).
We already had a check for stpcpy in igraph, and also a replacement if not available, but we tested the library not the header. So what happened was that the test passed as stpcpy was available, but then its signature was wrong because it wasn't in the headers, and this caused errors.
Now we test for the signature in the header as well, and provide a signature if it is missing, so it should be all good.