Problems when installing MOOSE offline

[Ethan-xj]

Check these boxes if you have followed the posting rules.

• I have consulted the Posting Guidelines.
• I have searched the Discussions Forum and MOOSE Framework Troubleshooting and have not found what I was looking for
• Q&A Getting Started is the most appropriate category for my question (trouble installing, beginner user, ...)

Issue or question about MOOSE

I followed the official offline installation guide and successfully built the PETSc library, but encountered issues when building the Libmesh library. I'm wondering if I might not have correctly understood the guide. Do I also need to manually download the dependencies required by Libmesh? I only downloaded the dependencies needed for PETSc using the ./scripts/update_and_rebuild_petsc.sh --CC=$CC --CXX=$CXX --FC=$FC --with-packages-download-dir=~/projects/downloads command and then directly ran the ./update_and_rebuild_libmesh.sh --skip-submodule-update command.

Ethan

(Optional) code in question / simulation log / errors

No response

Encountering Errors? Please include diagnostic output

No response

[GiudGiud]

Hello

When you download moose before going offline, this part git submodule foreach --recursive git submodule update --init should have taken care of downloading all the libmesh dependencies

[Ethan-xj]

@milljm My openssl is like:

[hpc4123303047@ln08 scripts]$ openssl version
OpenSSL 1.1.1l  24 Aug 2021

I installed it recently.
And for the boost locations. It seems there is an older version of boost in the /usr directory, but I don't have access to that directory. Therefore, I installed a newer version in a different directory and specified my installation path during the configure process. Given that, it shouldn't be causing any issues.

[milljm]

Part of the issue I've noticed with libraries libMesh picks up in system locations, is that it now needs to include those with -L/usr/lib etc etc. And by doing so, it'll link with other libraries it may also need which are discovered in these locations. Usually this seems to be an issue with Boost and MPI (using system MPI grabs Boost also in this location by accident). But for your issue, it feels like something else is drawing its attention there.

Log example:

configure:35539: mpicxx -o conftest -g -O2  -Wall   -L/home/hpc4123303047/ZXY/MOOSE/packages/openssl-3.0.2/build/lib -L/lib64 conftest.o -lboost_system  >&5
/lib64/libboost_system.so: undefined reference to `operator delete(void*)@GLIBCXX_3.4'
/lib64/libboost_system.so: undefined reference to `__cxa_guard_release@CXXABI_1.3'
/lib64/libboost_system.so: undefined reference to `__cxa_guard_acquire@CXXABI_1.3'
/lib64/libboost_system.so: undefined reference to `vtable for __cxxabiv1::__class_type_info@CXXABI_1.3'
/lib64/libboost_system.so: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@GLIBCXX_3.4'

Edit:
I made mention of OpenSSL, because I feel like its the one doing it...

[Ethan-xj]

If the issue is with OpenSSL, and I have installed OpenSSL in the path /home/hpc4123303047/ZXY/MOOSE/packages/openssl-1.1.1l, what should I do next? Could the issue be related to the version of OpenSSL?

[milljm]

I don't think its a version of OpenSSL that is the issue, but perhaps by building your own, that in order to use it, it is requiring that we link to things in system locations (or something like that). I am not familiar with OpenSSL enough to know what it may be doing this for.

I only find it odd that in the config.log file, while I scroll through it quickly, I only see this link line pertaining to a custom OpenSSL version. Even though I would expect to see more (like all the other custom libraries you built manually).

[milljm]

Perhaps dropping this:

LDFLAGS='-L/home/hpc4123303047/ZXY/MOOSE/packages/openssl-3.0.2/build/lib'

[Ethan-xj]

My fault. Sry for that. I just realize that the config.log is changed.
Here is the new one:
config.log

[milljm]

I was just going to report that, yes. Everything looked fine up until the contribs began to config.

Add a prefix argument:

--prefix=/home/hpc4123303047/ZXY/MOOSE/packages/libmesh

(just a guess as to where you want libmesh). Basically, I would place it right along side where ever you installed PETSc.

Where ever the location you pick, you'll want to then set LIBMESH_DIR= to point to this location, when you eventually get to the step of building MOOSE.

So all in all, in the end (if the above works):

export PETSC_DIR=/some/path/to/where/you/installed/petsc
export LIBMESH_DIR=/home/hpc4123303047/ZXY/MOOSE/packages/libmesh
cd ~/projects/moose/test
make

Edit: UGH... I always forget WASP :) You'll need to build WASP, and then set WASP_DIR= much in the same way above. And then you can build MOOSE.

[Ethan-xj]

@milljm I'm afraid the issue still hasn't been resolved. I've set all the paths, including the prefix and specified the Boost path. However, it still throws errors. I ran the configure directly in the metaphysiclfolder(/home/hpc4123303047/projects/moose/libmesh/contrib/metaphysicl) and the config.log is here:
config.log
Could you find any clues from it?

[Ethan-xj]

Could it be an issue with libboost_system-mt.so? I noticed that it appears multiple times in the config.log, but I don't see this file in my boost/build/lib folder.

[Ethan-xj]

The problem is solved. I use ./configure --help to check the rules of the metaphysic's configuration. I should use --with--boost=/root/to/boost. And it succeeds. Thank you all :)

[GiudGiud]

so you had to configure metaphysicl individually? The boost options did not propagate from libmesh?

[Ethan-xj]

No, I was just saying that I discovered the issue when compiling metaphysic separately. When I used the shell script ./update_and_rebuild_libmesh.sh --skip-submodule-update with the --with-boost option, I successfully compiled libMesh, and I also successfully installed MOOSE and passed the tests.
Thank you all :)

Ethan