Rebuild issues on Linux #16524

dealmeidavf · 2020-12-17T05:39:38Z

dealmeidavf
Dec 17, 2020

Hello,
In a recent rebuilt of libmesh:

cd moose/
./scripts/update_and_rebuild_libmesh.sh

I noticed these lines in the screen output:

libtool: warning: '/usr/local/ompi/lib/libmpi_cxx.la' seems to be moved
libtool: warning: '/usr/local/ompi/lib/libmpi.la' seems to be moved

I verified the mpi libs are there; not sure why the above messages...

Also additional messages:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libutil.so when searching for -lutil
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libutil.a when searching for -lutil
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

Any ideas on why these are incompatible?

Proceeding to the make tests:
cd test
make -j 4

another block of incompatible messages:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libutil.so when searching for -lutil
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libutil.a when searching for -lutil
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

The tests do not run.

Is there a way to do a clean up and recompile with the existing MOOSE repo? Or should I just make a fresh git clone and start from scratch?

Thanks for inputs.

--
Valmor

Answered by cticenhour

Dec 17, 2020

You don't need to clone a fresh copy of moose in order to do a general clean.

To clean MOOSE, first make sure you stash or commit any work you might have in the moose directory tree as the next command would remove those if you don't. Then run:

git clean -xfd

in the moose directory. This will clean up libraries, test output, and other miscellaneous objects used during building. After that, I would clean out the libmesh submodule. Perform these commands within your moose directory:

git submodule deinit -f libmesh
git submodule update --init --recursive libmesh

This will clear out the libmesh directory and pull a fresh copy of the submodule. You can do the same thing with petsc (just switc…

View full answer

ngrilli · 2020-12-17T08:35:10Z

ngrilli
Dec 17, 2020

Dear @dealmeidavf

Which operating system?
I often see that libtool warning, but then my MOOSE installation works fine
on both Ubuntu 20 and CentOS 7

Best Regards,
Nicolò Grilli
National University of Singapore

1 reply

dealmeidavf Dec 17, 2020
Author

Gentoo Linux. And yes, it appears but MOOSE works.

Thanks

cticenhour · 2020-12-17T15:02:53Z

cticenhour
Dec 17, 2020
Maintainer

You don't need to clone a fresh copy of moose in order to do a general clean.

To clean MOOSE, first make sure you stash or commit any work you might have in the moose directory tree as the next command would remove those if you don't. Then run:

git clean -xfd

in the moose directory. This will clean up libraries, test output, and other miscellaneous objects used during building. After that, I would clean out the libmesh submodule. Perform these commands within your moose directory:

git submodule deinit -f libmesh
git submodule update --init --recursive libmesh

This will clear out the libmesh directory and pull a fresh copy of the submodule. You can do the same thing with petsc (just switch out petsc for libmesh in these command and you can remove --recursive).

Finally, you can navigate to test and run make clobberall. This performs much the same function as git clean, but specifically focuses on the libraries and objects made during build. I find it useful to run this just in case the git clean missed something. With all that done, you should be free to rebuild petsc, libmesh, and moose.

4 replies

cticenhour Dec 17, 2020
Maintainer

Regarding the output you are seeing during build...This could be a byproduct of something changing in your environment after you built moose previously. The cleaning should help. If cleaning doesn't stop this, then the issue is something deeper in your development stack.

dealmeidavf Dec 17, 2020
Author

Thanks for the list of commands. I did build from a fresh clone and it was fine. I believe it was an upgrade of my system where python went from 3.7 to 3.8 that caused the problem. I will make sure to clean up before rebuilding MOOSE next time.

On the incompatible command matter. There are two libX11.so built on my system; 32 and 64 bit:

-> file /usr/lib64/libX11.so.6.4.0
/usr/lib64/libX11.so.6.4.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
-> file /usr/lib/libX11.so.6.4.0
/usr/lib/libX11.so.6.4.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

The config script is probably probing all libX11 and finding that the 32bit version is incompatible. Just my guess. Apparently this is what is happening with a build of VisIt that I have been struggling with. The build_script does not find libX11. The fact that I saw the warning when building MOOSE gave me the hint for a related problem with VisIt.

Thanks.

cticenhour Dec 17, 2020
Maintainer

Glad you're able to build successfully now!

I would guess that the script is likely going with whatever libX11 it finds first, or the location listed first in your PATH. Does it consistently show up in your builds? Or is intermittent?

dealmeidavf Dec 17, 2020
Author

It always show. I just had not noticed before because the tests worked. However with the upgrade of python the tests failed and I had to go back look at the compilation messages from moose. Even this last fresh build had the skipping message. I looks like the build script is smart enough to ignore the incompatible library. However not all scripts will do that; I realize this now.
Good point will check my PATH and make sure lib64 is first; a quick look shows that this may not be the case.
Thanks.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rebuild issues on Linux #16524

{{title}}

Replies: 2 comments 5 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Rebuild issues on Linux #16524

dealmeidavf Dec 17, 2020

Replies: 2 comments · 5 replies

ngrilli Dec 17, 2020

dealmeidavf Dec 17, 2020 Author

cticenhour Dec 17, 2020 Maintainer

cticenhour Dec 17, 2020 Maintainer

dealmeidavf Dec 17, 2020 Author

cticenhour Dec 17, 2020 Maintainer

dealmeidavf Dec 17, 2020 Author

dealmeidavf
Dec 17, 2020

Replies: 2 comments 5 replies

ngrilli
Dec 17, 2020

dealmeidavf Dec 17, 2020
Author

cticenhour
Dec 17, 2020
Maintainer

cticenhour Dec 17, 2020
Maintainer

dealmeidavf Dec 17, 2020
Author

cticenhour Dec 17, 2020
Maintainer

dealmeidavf Dec 17, 2020
Author