Dear Jeremy- The solution you provided worked. Thank you very much! I also want to put a couple of takeaways on Building NekTar++ on macos with Monterey (in case someone wants to build NekTar++ on macos with Moterey) 1) Boost Installation with -DTHIRDPARTY_BUILD_BOOST=ON will throw the error as BOOST has some issues with clag and figuring out the darwin version. It is better if you install BOOST using port and Homebrew "brew install boost" or should port install boost 2) System Installation of TINYXML using brew or macport is not working as nektar+ tracebacks throwing error that some of the macros are redfiend in TinyXML. Therefore I uninstall systemwide TINXML and installed with NEKTAR++ tried -DTHIRDPARTY_BUILD_TINYXML=ON. NekTar++ got successfully installed. Thanks! Regards Raj On Sun, Aug 14, 2022 at 7:26 AM Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

Dear Jeremy- Thank you very much! 1) Yes, I am using the master branch cloned from gitlab. 2) I am building it on an Apple machine with itel processors. I will try the solutions which you provided and get back to you.

Thanks! Regards Raj

On Sun, Aug 14, 2022 at 12:01 AM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:

...

Dear Raj,

Thanks for reporting this issue. Are you building the code from the master branch of the source code from GitLab, or building a release version of Nektar++?

Can you also confirm whether you’re building on an Intel or Apple Silicon-based Mac?

It looks like this is caused by clang in Xcode 13 now generating a warning for this deprecated case, where previous clang versions didn’t. The warning is then interpreted as an error via the use of -Werror.

We’ll need to investigate this and look at implementing an update to resolve this issue. As a workaround, I think you may be able to add the “-Wno-deprecated-copy” flag to the compile options so that you can get a working build.

It should be possible to do this by adding the flag to the CMake configuration options for compiler flags. However, there are lots of different options. An easier way may be to edit the cmake/NektarCommon.cmake file in the Nektar++ source tree to set this globally. If you’re using the source code from master, you should see that line 116 of that file is "TARGET_COMPILE_OPTIONS(${name} PRIVATE -Werror)”. Add a new line directly after this one (with the same level of indentation) with the following content:

TARGET_COMPILE_OPTIONS(${name} PRIVATE -Wno-deprecated-copy)

This should add the -Wno-deprecated-copy to the compile options and prevent the warning being triggered. You’ll probably need to clean your build directory and re-run CMake, starting the build from scratch for this to take effect.

I don’t have access to a Mac with Monterey installed to test this but let us know if this resolves the issue for now.

Best wishes, Jeremy

On 13 Aug 2022, at 12:14, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

This email from khemraj_shukla@brown.edu originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.

Dear All- I have to add a couple of cpp routines to NeTar++ and I was trying to compile the NekTar++ on my MacOS monterey. I am landing up in the following issue. I am using the Clang compiler. I also switched it to the gcc compiler but in that case the issue was coming from the Boost Library. I tried to compile Boost from source but no luck. Therefore I had to switch to clang and installed it through macport.

I will appreciate your help in this regard.

Thanks! Raj /nektar++/library/LibUtilities/SimdLib/scalar.hpp:124:12: error: definition of implicit copy assignment operator for 'scalarT<unsigned long long, void>' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy] inline scalarT(const scalarT &rhs) = default; ^ _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users

Thanks Jeremy! Just wanted to put the error thrown by clang or gcc by installing it with -DTHIRDPARTY_BUILD_BOOST=ON. Basically -coalesce-templates flag was not recognized. Thanks! " darwin.compile.c++ build-boost/boost/bin.v2/libs/filesystem/build/darwin -11.0.3/release/cxxstd-17-iso/threading-multi/visibility-hidden/codecvt_error_category.o clang: error: unknown argument: '-fcoalesce-templates' ...failed darwin.compile.c++ build-boost/boost/bin.v2/libs/filesystem/build/darwin -11.0.3/release/cxxstd-17-iso/threading-multi/visibility-hidden/ codecvt_error_category.o... " On Sun, Aug 14, 2022 at 12:28 PM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:

Dear Raj,

Great to hear that adding the additional compile flag resolves the build issue you were experiencing. I’ve opened an issue in GitLab for this case ( https://gitlab.nektar.info/nektar/nektar/-/issues/301) and we’ll look at getting this fixed as soon as possible.

Many thanks for the helpful pointers for others attempting to build Nektar++ from source on macOS Monterey. To resolve the third party Boost issue, I suspect we’d need to switch to a newer third party version of Boost which may cause issues for other operating systems so installing via Homebrew or MacPorts is definitely the recommended option here.

The tinyxml issue sounds like something that it might be possible to resolve in the nektar++ code but this will need investigating.

Thanks again for the information.

Kind regards, Jeremy

On 14 Aug 2022, at 07:17, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

Dear Jeremy- The solution you provided worked. Thank you very much! I also want to put a couple of takeaways on Building NekTar++ on macos with Monterey (in case someone wants to build NekTar++ on macos with Moterey)

1) Boost Installation with -DTHIRDPARTY_BUILD_BOOST=ON will throw the error as BOOST has some issues with clag and figuring out the darwin version. It is better if you install BOOST using port and Homebrew "brew install boost" or should port install boost

2) System Installation of TINYXML using brew or macport is not working as nektar+ tracebacks throwing error that some of the macros are redfiend in TinyXML. Therefore I uninstall systemwide TINXML and installed with NEKTAR++ tried -DTHIRDPARTY_BUILD_TINYXML=ON. NekTar++ got successfully installed.

Thanks! Regards Raj

On Sun, Aug 14, 2022 at 7:26 AM Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

...

Dear Jeremy- Thank you very much! 1) Yes, I am using the master branch cloned from gitlab. 2) I am building it on an Apple machine with itel processors. I will try the solutions which you provided and get back to you.

Thanks! Regards Raj

On Sun, Aug 14, 2022 at 12:01 AM Jeremy Cohen < jeremy.cohen@imperial.ac.uk> wrote:

...

Dear Raj,

Thanks for reporting this issue. Are you building the code from the master branch of the source code from GitLab, or building a release version of Nektar++?

Can you also confirm whether you’re building on an Intel or Apple Silicon-based Mac?

It looks like this is caused by clang in Xcode 13 now generating a warning for this deprecated case, where previous clang versions didn’t. The warning is then interpreted as an error via the use of -Werror.

We’ll need to investigate this and look at implementing an update to resolve this issue. As a workaround, I think you may be able to add the “-Wno-deprecated-copy” flag to the compile options so that you can get a working build.

It should be possible to do this by adding the flag to the CMake configuration options for compiler flags. However, there are lots of different options. An easier way may be to edit the cmake/NektarCommon.cmake file in the Nektar++ source tree to set this globally. If you’re using the source code from master, you should see that line 116 of that file is "TARGET_COMPILE_OPTIONS(${name} PRIVATE -Werror)”. Add a new line directly after this one (with the same level of indentation) with the following content:

TARGET_COMPILE_OPTIONS(${name} PRIVATE -Wno-deprecated-copy)

This should add the -Wno-deprecated-copy to the compile options and prevent the warning being triggered. You’ll probably need to clean your build directory and re-run CMake, starting the build from scratch for this to take effect.

I don’t have access to a Mac with Monterey installed to test this but let us know if this resolves the issue for now.

Best wishes, Jeremy

On 13 Aug 2022, at 12:14, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

This email from khemraj_shukla@brown.edu originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.

Dear All- I have to add a couple of cpp routines to NeTar++ and I was trying to compile the NekTar++ on my MacOS monterey. I am landing up in the following issue. I am using the Clang compiler. I also switched it to the gcc compiler but in that case the issue was coming from the Boost Library. I tried to compile Boost from source but no luck. Therefore I had to switch to clang and installed it through macport.

I will appreciate your help in this regard.

Thanks! Raj /nektar++/library/LibUtilities/SimdLib/scalar.hpp:124:12: error: definition of implicit copy assignment operator for 'scalarT<unsigned long long, void>' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy] inline scalarT(const scalarT &rhs) = default; ^ _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users

Thanks Jeremy! Tha will be very helpful! I was also able to install NekTar++ with singularity on the cluster without any hiccups, specifically on brown's CLuster OSCAR and ANL's theta machine, they ran like charms. I can pass on those instructions as well. Thanks! Regards Raj On Tue, Aug 16, 2022 at 10:34 PM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:

Many thanks for the information Raj.

It looks like the issue with this flag may have been fixed in the following boost build system pull request: https://github.com/boostorg/build/pull/560

I’m guessing the changes in that PR aren’t included in the version of boost we’re currently using for the third party build. I’ll check that I can reproduce this and then we can look at whether there may be an option to add a patch to apply for builds on newer versions of macOS or simply update the third party version of boost.

I know that more recent versions of boost are increasingly using newer C++ syntax so we need to ensure that the version of boost being provided for the third party build also works on some of the older Linux distros that are also still being supported.

Thanks again, Jeremy

On 16 Aug 2022, at 21:19, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

Thanks Jeremy! Just wanted to put the error thrown by clang or gcc by installing it with -DTHIRDPARTY_BUILD_BOOST=ON. Basically -coalesce-templates flag was not recognized.

Thanks! " darwin.compile.c++ build-boost/boost/bin.v2/libs/filesystem/build/darwin -11.0.3/release/cxxstd-17-iso/threading-multi/visibility-hidden/codecvt_error_category.o clang: error: unknown argument: '-fcoalesce-templates' ...failed darwin.compile.c++ build-boost/boost/bin.v2/libs/filesystem/build/darwin -11.0.3/release/cxxstd-17-iso/threading-multi/visibility-hidden/ codecvt_error_category.o... "

On Sun, Aug 14, 2022 at 12:28 PM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:

...

Dear Raj,

Great to hear that adding the additional compile flag resolves the build issue you were experiencing. I’ve opened an issue in GitLab for this case ( https://gitlab.nektar.info/nektar/nektar/-/issues/301) and we’ll look at getting this fixed as soon as possible.

Many thanks for the helpful pointers for others attempting to build Nektar++ from source on macOS Monterey. To resolve the third party Boost issue, I suspect we’d need to switch to a newer third party version of Boost which may cause issues for other operating systems so installing via Homebrew or MacPorts is definitely the recommended option here.

The tinyxml issue sounds like something that it might be possible to resolve in the nektar++ code but this will need investigating.

Thanks again for the information.

Kind regards, Jeremy

On 14 Aug 2022, at 07:17, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

Dear Jeremy- The solution you provided worked. Thank you very much! I also want to put a couple of takeaways on Building NekTar++ on macos with Monterey (in case someone wants to build NekTar++ on macos with Moterey)

1) Boost Installation with -DTHIRDPARTY_BUILD_BOOST=ON will throw the error as BOOST has some issues with clag and figuring out the darwin version. It is better if you install BOOST using port and Homebrew "brew install boost" or should port install boost

2) System Installation of TINYXML using brew or macport is not working as nektar+ tracebacks throwing error that some of the macros are redfiend in TinyXML. Therefore I uninstall systemwide TINXML and installed with NEKTAR++ tried -DTHIRDPARTY_BUILD_TINYXML=ON. NekTar++ got successfully installed.

Thanks! Regards Raj

On Sun, Aug 14, 2022 at 7:26 AM Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

...

Dear Jeremy- Thank you very much! 1) Yes, I am using the master branch cloned from gitlab. 2) I am building it on an Apple machine with itel processors. I will try the solutions which you provided and get back to you.

Thanks! Regards Raj

On Sun, Aug 14, 2022 at 12:01 AM Jeremy Cohen < jeremy.cohen@imperial.ac.uk> wrote:

...

Dear Raj,

Thanks for reporting this issue. Are you building the code from the master branch of the source code from GitLab, or building a release version of Nektar++?

Can you also confirm whether you’re building on an Intel or Apple Silicon-based Mac?

It looks like this is caused by clang in Xcode 13 now generating a warning for this deprecated case, where previous clang versions didn’t. The warning is then interpreted as an error via the use of -Werror.

We’ll need to investigate this and look at implementing an update to resolve this issue. As a workaround, I think you may be able to add the “-Wno-deprecated-copy” flag to the compile options so that you can get a working build.

It should be possible to do this by adding the flag to the CMake configuration options for compiler flags. However, there are lots of different options. An easier way may be to edit the cmake/NektarCommon.cmake file in the Nektar++ source tree to set this globally. If you’re using the source code from master, you should see that line 116 of that file is "TARGET_COMPILE_OPTIONS(${name} PRIVATE -Werror)”. Add a new line directly after this one (with the same level of indentation) with the following content:

TARGET_COMPILE_OPTIONS(${name} PRIVATE -Wno-deprecated-copy)

This should add the -Wno-deprecated-copy to the compile options and prevent the warning being triggered. You’ll probably need to clean your build directory and re-run CMake, starting the build from scratch for this to take effect.

I don’t have access to a Mac with Monterey installed to test this but let us know if this resolves the issue for now.

Best wishes, Jeremy

On 13 Aug 2022, at 12:14, Shukla, Khemraj <khemraj_shukla@brown.edu> wrote:

This email from khemraj_shukla@brown.edu originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.

Dear All- I have to add a couple of cpp routines to NeTar++ and I was trying to compile the NekTar++ on my MacOS monterey. I am landing up in the following issue. I am using the Clang compiler. I also switched it to the gcc compiler but in that case the issue was coming from the Boost Library. I tried to compile Boost from source but no luck. Therefore I had to switch to clang and installed it through macport.

I will appreciate your help in this regard.

Thanks! Raj /nektar++/library/LibUtilities/SimdLib/scalar.hpp:124:12: error: definition of implicit copy assignment operator for 'scalarT<unsigned long long, void>' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy] inline scalarT(const scalarT &rhs) = default; ^ _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users