[AlmostSurelyRob]

I am having another quarrel with wmake... I would be obliged for advice.

Following this thread:

http://www.cfd-online.com/Forums/ope...oam-2-1-x.html

I was able to install and run OpenFOAM on my Arch Linux computer. Everything was going fine but recently wmake started giving me this error when linking.

/usr/bin/ld: /home/c111269/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so: version node not found for symbol _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: error: ld returned 1 exit status
make: *** [/home/c111269/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so] Error 1

This error is not reproduced on the same code on my laptop which is also running Arch Linux (both x86_64). I am running a comparative check of packages at the moment, but please let me ask: has anyone experienced a similar problem? I am not an expert on linking, what does this error actually mean?

[wyldckat]

Hi Robert,

Mmm... well, it's time for another version checking:

1. Do the laptop and the workstation have the same up-to-date ArchLinux?
2. Do both have the same architecture installed? Namely i?86 or x86_64?
3. Are they both on the same git commit? Run this to check:

   git log -n 1

Best regards,
Bruno

[AlmostSurelyRob]

Many thanks for the reply.

Originally Posted by wyldckat

Do the laptop and the workstation have the same up-to-date ArchLinux?

Yes! Just before you posted I actually did a risky update of my laptop AL and the code still compiles. When I "vimdiffed" my package lists I have only discovered some minor differences related to incscape installation on my desktop.

Originally Posted by wyldckat

Do both have the same architecture installed? Namely i?86 or x86_64?

Yes!

Originally Posted by wyldckat

Are they both on the same git commit?

Apparently they aren't. Laptop has a commit from March whilst Desktop has a commit from May the 4th, but I don't think this is the issue, since I pulled after I started getting this problem.

[wyldckat]

Mmm... now that I think about it a bit more, last time I saw something similar was because the Ubuntu and compiler versions weren't 100% identical on both machines.

In your case, it could be two problems:

1. The more recent git pull could have changed parts of code in OpenFOAM or maybe in the wmake rules that have affected how things are meant to be built. And a failure to detect timestamps in files might also lead to this problem.
2. A seamlessly minor update to your machine that has the problem, might be the reason why you're having troubles.

Either way, when in doubt: clean up and rebuild!

foam
wclean all
wmSET #update the OpenFOAM shell environment...
export WM_NCOMPPROCS=4
./Allwmake

[AlmostSurelyRob]

Thanks! Alas, wmake is not satisfied with a clean compilation. I reproduced your steps exactly but wmake is still complaining about dynamic section sizes. Just to be on the safe side I removed and checked out a new version completely and started the compilation process again, but I am not extremely hopeful there. We shall see.

[AlmostSurelyRob]

I've just discovered that after I source OF bashrc I get

/usr/lib/paraview-3.14/paraview: symbol lookup error: /usr/lib/openmpi/libmpi_cxx.so.1: undefined symbol

would that be a clue in this investigation?

It's clear to me that at some point I've made some change to my libraries, but I can't trace this. None of these issues appear on my laptop which had Arch installed at roughly the same time.

[wyldckat]

That error message is because the ParaView version is checked by running paraview with the relevant version option. But this means that the ParaView version you have installed isn't 100% compatible with the OpenMPI installed, i.e., not the same expected binaries.

Right now there are only a few things that come to my mind:

1. Something was updated without you knowing.
2. The machine might be exhibiting hardware problems.
3. You might have copied something to your personal or global working area that was built elsewhere and isn't 100% compatible with everything else.

[AlmostSurelyRob]

This morning I reinstalled Arch. I was dreading the prospect but it turned out to be quite straightforward. I checked out from git and it built in one go. All is well and I'll try be cautious and check my code in caase the problem resurfacing.

Before reinstalling I created a new user account and run it there thnking that it might be something in my home but it also failed.

Thanks for the comments!

[wyldckat]

Hi Robert,

I'm glad you've got it up and running without any major problems

My suspicion is that you might have built one too many things as root and one or more of those things corrupted the files provided by the standard ArchLinux packages.

The advices I think that are usually given for system-wide installations are:

1. If you're going to build something new, do it in your own user space.
2. If you want to make it available to everyone, do it in your user space and then copy/move it to a respective folder in "/opt/". Don't forget to reassign permissions.
3. If you have more experience, then use "/usr/local/" as a prefix for the installation. If you don't know what I mean by prefix, then you're not experienced enough
4. If you really know what you're doing... you'll do it first on a VM or jail root (chroot) to test if it really works.
5. When you reeeeaaaally know what you're doing, then and only then you can install in "/usr/"
6. Install in "/", only if you're a systems integrator

Best regards,
Bruno