Compiling OpenFoam from git : problem with ld
 

Hello !
This is my first post on this forum, so do not hesitate to correct me if i do something wrong ;-)
Here is my problem :
When compiling OpenFoam (Allwmake) on Kubuntu 12.04 64bit, on 6 cores, i get the following error (this is only the first one, as there is a lot of them after which seem linked with this one) :
The problem is that after this, a lot of similar errors occurs, and and other "cannot find -lsomething" error, and the compiler starts to missing a lot of things.
I am following the tutorial from http://www.openfoam.org/download/git.php, and installed it in my $home/OpenFOAM/OpenFOAM-2.1.x.
I compiled ThirdParty-2.1.x without problems ($HOME/OpenFOAM/ThirdParty-2.1.x)

Is there somebody who had the same kind of errors, or who have any idea of how resolving these ?

Thank you
Best regards,
Matthieu Borgraeve

Greetings Matthieu and welcome to the forum!

Mmm... interesting error message. OK, let's try diagnosing this without having me reproduce the same installation in a virtual machine.

1. Run Allwmake like this:
   Code:

   ---

   ./Allwmake > make.log 2>&1

   ---

2. When it's done, open the log file "make.log" and search for the first occurrence of "Error ". That should be the first problem and the one that needs to be dealt with.
3. If you're unable to figure it out, search-and-replace any sensitive data (user name, paths and so on) in that log file, packed it an attach it.
   You can pack it by running:
   Code:

   ---

   tar -czf make.log.tar.gz make.log

   ---

Now, a few more questions:

• Did you install any specific GCC version or any other building utilities? Intel compilers, LLVM or something like that?
• How are you taking advantage of the 6 cores for building OpenFOAM? Did you run, before Allwmake, this command :confused::
  Code:

  ---

  export WM_NCOMPPROCS=6

  ---

• Do you have any other OpenFOAM installations in your machine? If so, what steps have you taken for keeping them separate?

Best regards,
Bruno

More informaiton
 

Hi,
Thank you for this short reply !!
Here is more informaiton :

1. done
2. The first error is the one i gave in my first message, here is a copy of the make.log file part where it appears :
   Code:

   ---

   Note: ignore spurious  warnings about missing mpicxx.h headers
wmake libso mpi
/usr/bin/ld: error: --add-needed is not supported but is required for  libdl.so.2 in  /home/matthieu/OpenFOAM/ThirdParty-2.1.x/platforms/linux64Gcc/openmpi-1.5.3/lib/libmpi.so
collect2: ld a retourné 1 code d'état d'exécution
make: ***

   ---

3. The beggining and end of the make.log file is attached (full targzipped is 490KB...)

Concerning the others questions :

• the gcc version is 4.6.3 (given by gcc --version), but 4.4 .7is also installed as i am willing to test SpeedIT and ofgpu with openFoam (version given by gcc-4.4 --version
• I ran
  Code:

  ---

  export WM_NCOMPPROCS=6

  ---

  (not echo, but i assume you mean export)
• No, Idon't have other installation now, but i already tried a first time before, i then delete the OpenFoam folder, remove the source path/to/old/openfoam/etc/bashrc, redownload OpenFOAM from git and add the new source (/$HOME/OpenFOAM/OpenFOAM-2.1.x/etc/bashrc)

Thank you very much !


Best regards,
Matthieu Borgraeve

Yep, it's "export" not "echo" :)

Mmm, Kubuntu in French... On second thought, I'm going to give it a try in a virtual machine, because it's the second time today I see problems with Kubuntu and OpenFOAM. The other one was here: http://www.cfd-online.com/Forums/ope...tml#post375597

And from the "make.log" file you got, it's not clear as to what the specific issue is, although Open-MPI is not built using the same ld commands as OpenFOAM...

Like I wrote, I'm going to test this in a virtual machine.
In the mean time, do you have any special environment flags for building software? Such as "CFLAGS", "CXXFLAGS" and "LDFLAGS"?

Yes, i'm franch, so if you nedd me to translate some parts of the make.log, do not hesistate ;-)

I will have a look on this post, thank you !

I dont know what you mean by flags. I did not do anything approaching thant on purpose (i installed kubuntu yesterday on a new drive for testing OpenFoam and gpu computing without making a mess of the company drive disk with drivers, cuda installation and OpenFoam modifications), so unless it has been done automatically by installing NVIDIA drivers, Cuda drivers and developpment kit or installing OpenFoam and relatives, i would say no.
I may not be able to test furtermore this afternoon (the computer is needed by somebody else, with the real drive), but i will tomorrow morning at least.
Thank you for your help !
Regards,
Matthieu

Hi Matthieu,

Well, I guess NVidia is the one to be blamed... I finished testing in Kubuntu 12.04 x86_64, fully up-to-date - in both English and French - and had no problems building OpenFOAM 2.1.x.

Attached is the environment I got from my virtual machine, without the OpenFOAM environment activated; you can see yours by running:
From there you can for example use:
You should also clean up "LD_LIBRARY_PATH":
Then activate OpenFOAM's environment:
But compare your shell environment with the one attached and look for any suspicious looking stuff...

Best regards,
Bruno

Hello,
Here is some news :
whern compiling cuda applications from the Nvidia sdk examples, i get an error with mpicxx or something like that, but actually i do not manage to reproduce it (yet...), so it can confirm that Cuda & Nvidia stuff may interfer with OpenFOAM.


I compared our 'export' data, without Openfoam bashrc sourcing, and almost differences differences concern Cuda, installed on my computer, not on yours. The only other is the PWD variable, with points to my Download folder in my $HOME, as yours go to /home/myusername/OpenFOAM/OpenFOAM-2.1.x.
my log is attached if you want to see it.

I am trying to uninstall cuda and see if it changes something in compiling OpenFoam after cleaning.

After that, i will try to resintall Cuda and recompile to see if it changes something.

Another question concerning .bash_profile and .bashrc : i know rc is called while starting a bash window, and profile when starting the computer, but the openfoam's bashrc file is in the .bashrc, as the modifications for sourcing Cuda libs are in the .bash_profile. Can it change something ? (i reboot after each change of bash_profile).

Regards,
Matthieu

sorry for doubleposting, i forget the attached file...

Hi Matthieu,

If you can see the changes, then you can isolate them using aliases! Here's an long explanation I wrote sometime ago: Advanced tips for working with the OpenFOAM shell environment

Best regards,
Bruno

Hi,
Currently compiling, the problem stays the same : I have two errors :
and Tryning to run autogen.sh in ThirdParty/openmpi, it says that
Should i install it with apt-get install ?

Didn't you follow these instructions: http://www.openfoam.org/download/git.php ?

Check if the necessary packages are installed:

Yes i did, i just checked, and they are installed :

Mmm... OK, I guess it's best to go hardcore and install Ubuntu's own build of Open-MPI:

1. Edit OpenFOAM's "etc/bashrc", and change "WM_MPLIB=OPENMPI" to "WM_MPLIB=SYSTEMOPENMPI".
2. Code:

   ---

   sudo apt-get install mpi-default-bin mpi-default-dev

   ---

3. Reboot the machine, just in case... although you can try simply starting a new terminal window/tab.
4. Check if mpirun is operational:
   
   Code:

   ---

   sudo update-alternatives --config mpirun

   ---

5. Check if the proper MPI option is chosen by OpenFOAM's "bashrc":
   
   Code:

   ---

   mpirun --version
echo $FOAM_MPI
echo $PINC
echo $PLIBS
echo $MPI_ARCH_PATH

   ---

Hi,
Here are the results :
I restart Allwmake without cleaning, and it did some things more in ThirdParty, but i still get the same errors after :
and then it doen't find -lmeshtool :

EDIT : after cleaning, ThirdParty compile without any error, I am compiling OpenFoam.

Hi Matthieu,

I hate to have to say this, but either you need to try and rebuild OpenFOAM from scratch, or you might even have to reinstall Kubuntu :( And then build OpenFOAM before installing anything else CUDA related...

I don't know what it is, but something messed up your Kubuntu installation, at least when compared to a clean installation. It might have been ld or something else, I don't know and unfortunately I'm unable to diagnose it fast enough...

One last attempt - what do these commands output:
For me, on the clean installation I did with success:
I didn't even had automake installed...

I haven't looked at the environment log you posted before... I'm going to look at it now... maybe something comes to mind...

Best regards,
Bruno

Hi,
I think i have all the same than you, except from the probleming ld :
It might be that one, but i installed it copy-pasting the line on the tutorial..

Here are the others versions :

EDIT : Could you give what answer ld --help (at least the --add-needed line) ? It igave me Not Supported, and OpenFoam compiling complains about that.

EDIT2 : it is still compiling, without errors (yet...). I will tell you the state tomorrow morning ;-), and if it still crashes, i will try to reinstall Kubuntu. I am currently doing it on another computer (with a fresh kubuntu installed) also, and it does the same (but i also installed CUDA & drivers before..) I'll keep you informed !
Thank you very much for your help

EDIT : just starting to do the same problem missing -lmeshTools or others -lsomething...

Hi Matthieu,

I didn't manage to answer you sooner... attached is the full help given by "ld --help".

As for more on the ld version:
Best regards,
Bruno

Hi,
in mine, there is a line missing in yours comparing to me, as we have (nearly) the same version :
I really do not understand...

I will try to reinstall kubuntu, from a fresh downloaded ISO, with a new installation on my usbkey.

Hi,
After a clean reinstallation, the problem seems to disapear (without installing nvidia-current-updates, nor CUDA stuff).

Attached is the ld--version log, i think it is the same as you, where my --add-needed problem line is absent.

I am compiling ThirdParty, and i will compile OpenFoam during lunch time, and keep you informed. I will then try to install first nvidia-current-updates, retest it, and then try cuda.

Hi Matthieu,

I'm looking forward to it :)

My guess is that the CUDA instructions need the older variant of ld, which does a more relaxed linking strategy, while the recent versions use a very strict linking method.
Here's a little reading material about this when it was discovered in OpenFOAM:

• http://www.openfoam.org/mantisbt/view.php?id=15
• http://www.openfoam.org/mantisbt/view.php?id=316

Wait... now that I think of it... aaaarrg... it should have been as easy as removing the string "-Xlinker --add-needed -Xlinker --no-as-needed" from the rule files :(
You'll find this string in the following files:

• wmake/rules/linux64Gcc/c
• wmake/rules/linux64Gcc/c++

But still, I don't know if this would have fixed the problem... it might simply bring up some other problems :rolleyes:...


Best regards,
Bruno

Hi,

Some news i did'nt caught before : there is some errors when Allwmaking Thirdparty (attached, at the begging of the file). I am trying to compile OpenFoam.

Not much of a problem here... Open-MPI can build without these:

after a few hours compiling, it does finish, linking the elements which were missing after cuda installation.
I am following the rest of the tutorial, and it works, i manage to run the cavity test.

I just notice that before installing cudad, they ask me for installing binutils-gold, which i think is the probleming ld util.
I will look at the link ld before and after, and/or try to locate cuda/nvidia conf file for redirecting to ld-gold, and replace lthe original link in every other case.
I keep you informed ;-)

EDIT1 : Effectively, the link /usr/bin/ld point to /usr/bin/ld.bfd without binutils-gold, but it points to /usr/bin/ld.gold after installing it...
I look for a way to alias it or to edit nvidia conf files to solve it.

EDIT2 It really seems to be the problem, for now i'm testing compiling C Cuda application with the gold, and then i wxill recompile OpenFoam. Cuda C compilation fails with ld.bfd, which the standard version, but OpenCL does not complain, and the tests applications runned. I think i will have to edit the ld link each time i want to use cuda c compilation : i made an alias alias cuda ='alias ld=/usr/bin/ld.gold', the modification is apparent in a batch, but the make fails anyway. Aliases doesn't seem to interact with make... Have you any idea about how to make it quasi-automatic ?

alias won't work. You'll have to either use a wrapper script or switch OpenFOAM's build method to the old way.

Wrapper - I haven't tested this so I'm not certain it will work as intended:

1. Create a script at "$HOME/bin/ld" with these contents:
   
   Code:

   ---

   #!/bin/sh
if [ "x$LD_MODE" = "xGOLD" ]; then
  /usr/bin/ld.gold $@
else
  /usr/bin/ld.bfd $@
fi

   ---

2. Make the script executable:
   Code:

   ---

   chmod a+x $HOME/bin/ld

   ---

3. Make sure it's visible and among the first to be seen:
   Code:

   ---

   export PATH=$HOME/bin:$PATH

   ---

   Which you can embed automatically into "~/.bashrc" by running:
   Code:

   ---

   echo "export PATH=\$HOME/bin:\$PATH" >> ~/.bashrc

   ---

4. Now whenever you want to use GOLD mode, run in the terminal this command:
   Code:

   ---

   export LD_MODE=GOLD

   ---

   Then build what you want to build on that terminal.
5. You can then do the opposite by running:
   Code:

   ---

   unset LD_MODE

   ---

The other possibility and possibly the more sane one is to disable the current operational method (edit: this apparently doesn't work :():

1. Edit the files "wmake/rules/linux64Gcc/c" and "wmake/rules/linux64Gcc/c++".
2. Remove from them the following code:
   Code:

   ---

   -Xlinker --add-needed -Xlinker --no-as-needed

   ---

   Note: it's possible that you only need to remove "-Xlinker --add-needed", which I think has been deprecated...
3. You'll probably have to rebuild OpenFOAM.

Good luck!

The second options give me an error, but i'm not sure it concerns OpenFoam :

(this is the first error).

I think it will be safer to manually chane the link when compiling Cuda stuff, and then rechange it at the end to retreive the original state

Try keeping:

Hi,
Even with keeping this, i got references errors :

Hi Matthieu,

Strange... very strange... I'll try to test this in the next couple of days...

In the mean time, there is a somewhat quick way of switching between ld versions... something like this should get you in the right path:
I know there is a way to choose directly which version to use, but I don't have it memorized nor a mnemonic :(

Best regards,
Bruno

Hi Matthieu,

I've updated the instructions about creating a wrapper script for ld on post #24: http://www.cfd-online.com/Forums/ope...tml#post376235

As for this command:
It doesn't work out-of-the-box. The alternatives have to be added manually and I don't think it's worth the effort.


I think the main difference when using the gold one is that all of the library dependencies have to be explicitly declared. This is why tweaking around with "no-as-needed" won't do the trick (although I could be wrong...).
This is can be very complicated with OpenFOAM, because it relies on the feature of automatically figuring out certain library dependencies. It would require to edit most of the "Make/options" files and define in them all of the necessary library dependencies.

Best regards,
Bruno

I saw this error today. Very strange

The error might be because of the GNU gold. It seems GNU gold is still in beta. So use GNU ld instead.

Hi Daniel,

I noticed you reported this here: http://www.openfoam.org/mantisbt/view.php?id=685 :)

It's not as much of a beta issue, it's more of a decision issue... I think this could have been fixed in OpenFOAM a long time ago, but they kept taking the quickest route, or so it seemed (as seen in post #20):

• http://www.openfoam.org/mantisbt/view.php?id=15
• http://www.openfoam.org/mantisbt/view.php?id=316

In the comments of bug reports you'll find these two other important links:

• http://fedoraproject.org/wiki/Unders...gDSOLinkChange
• http://wiki.debian.org/ToolChain/DSOLinking

It basically leads all down to a single paradoxal premise:

• OpenFOAM relies on inherited library dependencies, therefore only a few libraries need to be referenced in "Make/options" for things to build properly. Because if a certain included library already has access to another library, than that other library is automagically visible to the application being built.
• Fedora and Debian are now dismissive of this behaviour for the following reasons:
  
  Quote:

  Originally Posted by http://fedoraproject.org/wiki/UnderstandingDSOLinkChange The default behaviour for ld allows users to 'indirectly' link to required objects/libraries through intermediate objects/libraries. While this is convenient, it can also be dangerous because it makes your program's dependencies tied to the dependencies of other objects. If those objects ever change their linkages, they can break your program without any changes to your own code!

  Quote:

  Originally Posted by http://wiki.debian.org/ToolChain/DSOLinking Currently the BFD based linker uses indirect dependent shared libraries to resolve symbols when linking shared libraries or binaries. This situation has a hidden violation of encapsulation.

Best regards,
Bruno

Thanks, Bruno.

By saying beta, I was hoping that gnu-gold would someday add a option to tolerate the "--add-needed" option with only a warning. Maybe they are still open to the users' voices in "beta" stage?

But anyway, I'm okay with their new philosophy.
Is it too troublesome to add twenty to thirty lines in options file for each app?
Could the core libs linkage be added in wmake/Makefile (not just -lOpenFOAM)?

Thanks again, Bruno, you are so active/energetic everyday. :D

I think it's the other way around: "--add-needed" is now outdated. And even the other option of relying on "DT_NEEDED" will probably also be deprecated sooner or later...

Around 200 apps (+100 if you count the ones in the "test" folder) x 20-30 lines = massive headache?
Actually this isn't much of a headache, because this work has already been done in the (unofficial) modifications made to OpenFOAM for it to work on Windows, both by Symscape and blueCAPE, because ironically Windows requires explicit indication of which libraries the applications reaaally need for working. Although in Windows it gets even trickier, because in Linux one can tell the linker to add a few libraries into the mix, even if they're not explicitly necessary...

But from what I've seen so far, the reasoning is part of OpenFOAM's own coding elegance:

• Code duplication, whichever and wherever it might be, should be avoided whenever possible. It stands to reason because whenever you have code duplication, you increase the chances of having a bug hidden in all duplicate places and even risk not fixing the same bug in all of the duplicates.
• The other one is the fully modular capabilities, where we can happily add a new turbulence model or boundary condition in a new custom library, without the need to rebuild everything from scratch.

I'm half asleep already... so I'm not so sure that "active/energetic" is the key reason :D Probably I'm simply trying to prove something to myself :rolleyes: ...