search

igraph / rigraph

igraph R package
https://r.igraph.org
551 stars 200 forks source link

can't mix gfortran and clang on linux #1269

Closed CdeMills closed 8 months ago

CdeMills commented 8 months ago

build failure ...

Under CentOS Stream9, compiling with gcc + gfortran is fine. Yet I prefer to use clang which has a few more security options. But nor flang, nor flang-new are available under CentOS (It's a "won't fix" from the maintainers). The compilation fails at the linking stage with "igraph/libs/igraph.so: undefined symbol: igraphdsortr_" Meaning it's probably some export issue between gfortran and clang.

To Reproduce

1) clone from github; "cd" into the new dir; "git checkout v2.0.2"; 2) R CMD build .

I didn't find a way to keep the tmp files in case of build failure to determine under which name fortran subroutines are exported.

TIA

Pascal

szhorvat commented 8 months ago

Clang and gfortran do normally work well together. Can you give specific step-by-step instructions to reproduce the problem, including your specific OS version, GCC version, Clang version, any custom Makevars file you might have, and all commands you executed to build igraph? Please also include the full build log.

szhorvat commented 8 months ago

Yet I prefer to use clang which has a few more security options.

I should point out that I think this is not a valid motivation. If you are running igraph in a security critical environment (e.g. you are running it on a server and allow anyone on the internet to submit arbitrary data files or run arbitrary igraph commands), you should be sandboxing it.

igraph is research software developed with limited resources. The top priority is not security, but mathematical correctness. Don't expect it to be bullet proof from a security standpoint.

CdeMills commented 8 months ago

Hello for the first question: I searched in the manuals, but did not find a way to keep the build dir. From the checked out github dir, I did "R CMD build --log ." Now I looked at ~/.R/Makevars, and found:

FFLAGS = -O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/re dhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protec tion -fcf-protection --no-optimize-sibling-calls $(LTO_FC)

which contains a few specific switches from flang. I pruned it to FFLAGS = -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -spec s=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf- protection -I/usr/lib64/gfortran/modules

essentially removing the lto switches. With that change, igraph compiles fine using gfortran and clang. Sorry for the noise.

CdeMills commented 8 months ago

And about security: I run rstudio on ordinary desktop machines. Nothing is critical; but I prefer to reduce the chances of issues due to stack overflow and similar.

Regards

Pascal

szhorvat commented 8 months ago

Yes, LTO would be incompatible between Clang and GCC.

A word of warning in case you try with a non-GCC Fortran compiler: that may or may not work. igraph is currently compiled with specific assumptions about gfortran's calling conventions, and is currently not being tested with any other Fortran compiler than gfortran. This applies for compiling the Fortran sources only, not to C.