[mborgraeve]

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.

[wyldckat]

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

configure: error: no vtf3.h found; check path for VTF3 package first...
configure: error: no BPatch.h found; check path for Dyninst package first...
configure: error: no f2c.h found; check path for CLAPACK package first...
configure: error: MPI Correctness Checking support cannot be built inside Open MPI
configure: error: no jvmti.h found; check path for JVMTI package first...
configure: error: no papi.h found; check path for PAPI package first...
configure: error: no libcpc.h found; check path for CPC package first...
configure: error: no ctool/ctool.h found; check path for CTool package first...

[mborgraeve]

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 ?

[wyldckat]

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:
   

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

2. Make the script executable:

   chmod a+x $HOME/bin/ld

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

   export PATH=$HOME/bin:$PATH

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

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

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

   export LD_MODE=GOLD

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

   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:

   -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!

[mborgraeve]

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

make[2]: « /home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/expandDictionary » est à jour.
g++ -m64 -Dlinux64 -DWM_SP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100  -IlnInclude -I. -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OpenFOAM/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OSspecific/POSIX/lnInclude   -fPIC Make/linux64GccSPOpt/foamDebugSwitches.o -L/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/lib \
             -lautoMesh -lbarotropicCompressibilityModel -lbasicSolidThermo -lbasicThermophysicalModels -lblockMesh -lchemistryModel -lcoalCombustion -lcompressibleLESModels -lcompressibleRASModels -lcompressibleTurbulenceModel -lconversion -ldecompositionMethods -ldistributed -ldistributionModels -ldsmc -ldynamicFvMesh -ldynamicMesh -ledgeMesh -lengine -lfieldFunctionObjects -lfileFormats -lfiniteVolume -lfoamCalcFunctions -lforces -lfvMotionSolvers -lgenericPatchFields -lincompressibleLESModels -lincompressibleRASModels -lincompressibleTransportModels -lincompressibleTurbulenceModel -linterfaceProperties -lIOFunctionObjects -ljobControl -llagrangian -llagrangianIntermediate -llaminarFlameSpeedModels -lLESdeltas -lLESfilters -lliquidMixtureProperties -lliquidProperties -lmeshTools -lmolecularMeasurements -lmolecule -lODE -lOpenFOAM -lpotential -lradiationModels -lrandomProcesses -lreactionThermophysicalModels -lreconstruct -lsampling -lSLGThermo -lsolidMixtureProperties -lsolidParticle -lsolidProperties -lsolid -lspecie -lsurfaceFilmModels -lsurfMesh -lsystemCall -lthermalPorousZone -lthermophysicalFunctions -ltopoChangerFvMesh -ltriSurface -ltwoPhaseInterfaceProperties -lutilityFunctionObjects -lOpenFOAM -ldl   -lm -o /home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/foamDebugSwitches
g++ -m64 -Dlinux64 -DWM_SP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/meshTools/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/dynamicMesh/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OpenFOAM/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OSspecific/POSIX/lnInclude   -fPIC Make/linux64GccSPOpt/PDRMesh.o -L/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/lib \
             -lmeshTools -ldynamicMesh -lfiniteVolume -lcompressibleRASModels -lOpenFOAM -ldl   -lm -o /home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/PDRMesh
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::Pstream::gather<int, Foam::minOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::minOp<int> const&, int) [clone .constprop.902]: error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::Pstream::gather<int, Foam::minOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::minOp<int> const&, int) [clone .constprop.902]: error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::syncTools::syncBoundaryFaceList<int, Foam::maxEqOp<int>, Foam::mapDistribute::transform>(Foam::polyMesh const&, Foam::UList<int>&, Foam::maxEqOp<int> const&, Foam::mapDistribute::transform const&): error: undefined reference to 'Foam::UIPstream::UIPstream(int, Foam::PstreamBuffers&)'
collect2: ld a retourné 1 code d'état d'exécution
make[3]: *** [/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/PDRMesh] Erreur 1
make[2]: *** [PDRMesh] Erreur 2

(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

[wyldckat]

Try keeping:

-Xlinker --no-as-needed

[mborgraeve]

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

g++ -m64 -Dlinux64 -DWM_SP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/meshTools/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/dynamicMesh/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OpenFOAM/lnInclude -I/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/src/OSspecific/POSIX/lnInclude   -fPIC -Xlinker --no-as-needed Make/linux64GccSPOpt/PDRMesh.o -L/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/lib \
             -lmeshTools -ldynamicMesh -lfiniteVolume -lcompressibleRASModels -lOpenFOAM -ldl   -lm -o /home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/PDRMesh
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::Pstream::gather<int, Foam::minOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::minOp<int> const&, int) [clone .constprop.902]: error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::Pstream::gather<int, Foam::minOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::minOp<int> const&, int) [clone .constprop.902]: error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function findPatch(Foam::polyBoundaryMesh const&, Foam::word const&): error: undefined reference to 'Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int)'
Make/linux64GccSPOpt/PDRMesh.o:PDRMesh.C:function void Foam::syncTools::syncBoundaryFaceList<int, Foam::maxEqOp<int>, Foam::mapDistribute::transform>(Foam::polyMesh const&, Foam::UList<int>&, Foam::maxEqOp<int> const&, Foam::mapDistribute::transform const&): error: undefined reference to 'Foam::UIPstream::UIPstream(int, Foam::PstreamBuffers&)'
collect2: ld a retourné 1 code d'état d'exécution
make[3]: *** [/home/matthieu/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccSPOpt/bin/PDRMesh] Erreur 1
make[2]: *** [PDRMesh] Erreur 2

[wyldckat]

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:

sudo update-alternatives --config ld

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

[wyldckat]

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:

sudo update-alternatives --config ld

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

[lakeat]

I saw this error today. Very strange

[lakeat]

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

[wyldckat]

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:
  

  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!

  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

[lakeat]

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.

[wyldckat]

Originally Posted by lakeat

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?

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...

Originally Posted by lakeat

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)?

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.

Originally Posted by lakeat

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

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