[ET Trac] #2553: Cactus' link command used CPPFLAGS and CXXFLAGS

[Roland Haas]

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS

 Reporter: Roland Haas
   Status: new
Milestone: 
  Version: development version
     Type: bug
 Priority: minor
Component: Cactus

Comment (by Roland Haas):

I see. I had not thought of link time optimizations.

To me it seems that passing CCPFLAGS to the compiler call makes since we actually call the compiler driver which internally first preprocesses the code \(with cpp\) and then calls the actual compiler \(cc1\). This is different from say FPP where Cactus explicitly calls the preprocessor and then passes the output file to Fortran compiler \(though by now it seems that many Fortran compiler drivers can also call the C preprocessor internally\).

Right not the linking stage in Cactus is really just linking object files and library files into the executable and does not include any compilation so the compiler and preprocessor options  are \(except for LTO\) not needed.

The cases where this matters are probably limited and I would have though that one should be able to use g\+\+ to link CUDA code, but at least my initial tries failed until I used nvcc to link \(otherwise it would report undefined symbols for some CUDA using code. Not for libcuda or libcudart though, which I already included in LIBS\).

I will try and see if the build system / option lists would support having `LDFLAGS` default to `$(CPPFLAGS) $(CXXFLAGS)` so that one can override its value completely via an option list. Currently it is impossible to remove `$(CXXFLAGS)` from the linker command line.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-command-used-cppflags-and
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/trac/attachments/20210811/611acf00/attachment.html