Hello Jose,

Cactus uses the C++ compiler to link things. 

This is controlled by the LD option list option.

In your option list (thank you for including it) you do not set it, so
it should default to the value of CXX.

However if there is an environment variable LD set, then this will
override the option list default (you'd see eg LD in the output of the
env command).

So as a first try, I'd add 

LD = g++

to your option list and recompile from scratch.

If that does not help, then more information will be required. Please
see:

http://einsteintoolkit.org/support.html#general-guidelines-for-questions

for what to include.

Yours,
Roland

On Wed, 12 Jun 2024 15:51:13 +0100, José Ferreira wrote:

Dear toolkit users and developers,


With the latest update of GCC to version 14, there is a known error
that prevents the compilation from taking place, preventing me from
compiling the toolkit.

I’ve been trying to do something which I probably should have some
time ago to avoid this kind of issues, while also granting some
portability between machines, which is to setup a virtual environment
using Conda to compile the toolkit.


I am sending you this e-mail because I’ve failed to compile the
toolkit in a virtual environment, where I am currently stuck with an
error during the linking phase. Before the update to GCC 14, and
without the virtual environment, I was able of compiling the toolkit
without any issue.

Here are the steps that I have performed:

1.

Activate an empty virtual environment managed by a conda (or a
drop-in replacement) with the conda-forge repository configured

2.

|conda install gcc gxx gfortran openmpi openmpi-mpicc
openmpi-mpicxx openmpi-mpifort binutils|

3.

Compile the toolkit with an empty thornlist, attached in
|empty.th|, and an option file that points towards the virtual
environment that is activated, attached in |venv.cfg|

4.

Get the following error from |ld| (the full log for making the
config and the binary are attached in |cactus_empty.log|)

|Creating cactus_empty in /home/undercover/projects/cactus/exe from
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
unrecognised emulation mode: arch=native Supported emulations:
elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: ***
[/home/undercover/projects/cactus/lib/make/make.configuration:150:
/home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
[Makefile:265: empty] Error 2 |


To me, the previous error indicates that something is passing the
wrong flags to |ld|, because even if the emulation mode was not
recognized it should give the error |ld: unrecognised emulation mode:
<something>| instead of |ld: unrecognised emulation mode:
arch=<something>|.

Removing the flag |-march=native| from the compilers confirms my
guess by revealing a different error at the same stage

|Creating cactus_empty in /home/undercover/projects/cactus/exe from
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
unrecognized option '-DMPICH_IGNORE_CXX_SEEK'
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
use the --help option for usage information make[1]: ***
[/home/undercover/projects/cactus/lib/make/make.configuration:150:
/home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
[Makefile:265: empty] Error 2 |

and if I were to remove the corresponding flag in the config file,
|ld| will complain about something else.

It really seems like something is passing the flags onto |ld| where
it shouldn’t, but I cannot tell who and where.


I should note that compiling very basic programs in C in the virtual
environment doesn’t raise any issues, although I haven’t tested it
very thoroughly.

Please do let me know if you have any issues in rendering this e-mail!


Best regards,

José Ferreira


​