Skip to content
Snippets Groups Projects

Changes or information for FreeBSD port

    • Closed Issue created by Yuri Z @yurivict 
    $ source ./work/OpenFOAM-v2112/etc/bashrc
cc: error: unsupported option '--showme:link'
    Edited

      Child items

      0
      Show labels

      No child items are currently assigned. Use child items to break down this issue into smaller parts.

        Activity

        • Yuri Z changed title from Fails to build on systems with clang: unsupported option '--showme:link' to Fails to build on systems with mpich: unsupported option '--showme:link'

          changed title from Fails to build on systems with clang: unsupported option '--showme:link' to Fails to build on systems with mpich: unsupported option '--showme:link'

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          Did you actually adjust your prefs.sh file (or bashrc file) to specify WM_MPLIB and MPICH?

          Hint: see what echo "$WM_MPLIB" and/or echo "$FOAM_MPI" return. If they don't specify mpich, I think you've done something wrong.

          The message you report with --showme:link should only ever appear as a last resort option for SYSTEMOPENMPI.

        • Yuri Z
          Yuri Z @yurivict ·
          Author

          I see. It builds fine with OpenMPI when it is in paths, which is preferable.

          I am trying to resuscitate the FreeBSD port for OpenFOAM.

        • Yuri Z closed

          closed

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          I'm not familiar with how FreeBSD packages things, but I'll rename the issue for future interactions. I've put together debian and rpm packages (and partial assist on some Arch packages), so might be able to coordinate with you.

        • Mark OLESEN reopened

          reopened

        • Mark OLESEN changed title from Fails to build on systems with mpich: unsupported option '--showme:link' to Changes or information for FreeBSD port

          changed title from Fails to build on systems with mpich: unsupported option '--showme:link' to Changes or information for FreeBSD port

        • Yuri Z
          Yuri Z @yurivict ·
          Author

          FreeBSD has port/package system. Binary packages are built from ports. Ports are continuously updated in the rolling release. There are ~32,000 ports.

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          @yurivict Here are some links that may or may not help:

        • Kutalmış Berçin added community label

          added community label

        • Yuri Z
          Yuri Z @yurivict ·
          Author

          There is the link failure:

          make[3]: Entering directory '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/applications/solvers/acoustic/acousticFoam'
g++ -std=c++11 -m64 -pthread -DOPENFOAM=2112 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas  -O3  -DNoRepository -ftemplate-depth-100 -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/finiteVolume/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/fvOption/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/regionFaModels/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/meshTools/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/sampling/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/transportModels/compressible/lnInclude -iquote. -IlnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/OpenFOAM/lnInclude -I/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/src/OSspecific/POSIX/lnInclude   -fPIC  /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o -L/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/lib \
    -lfiniteVolume -lfvOptions -lmeshTools -lsampling -lregionFaModels -lOpenFOAM -ldl  \
     -lm -o /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/bin/acousticFoam
ld: error: undefined symbol: Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int, int)
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::reduce<double, Foam::maxOp<double> >(Foam::List<Foam::UPstream::commsStruct> const&, double&, Foam::maxOp<double> const&, int, int))
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::Pstream::gather<double, Foam::maxOp<double> >(Foam::List<Foam::UPstream::commsStruct> const&, double&, Foam::maxOp<double> const&, int, int))
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::reduce<int, Foam::sumOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::sumOp<int> const&, int, int))
>>> referenced 1 more times

ld: error: undefined symbol: Foam::UOPstream::write(Foam::UPstream::commsTypes, int, char const*, long, int, int)
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::reduce<double, Foam::maxOp<double> >(Foam::List<Foam::UPstream::commsStruct> const&, double&, Foam::maxOp<double> const&, int, int))
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::Pstream::gather<double, Foam::maxOp<double> >(Foam::List<Foam::UPstream::commsStruct> const&, double&, Foam::maxOp<double> const&, int, int))
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(void Foam::reduce<int, Foam::sumOp<int> >(Foam::List<Foam::UPstream::commsStruct> const&, int&, Foam::sumOp<int> const&, int, int))
>>> referenced 1 more times

ld: error: undefined symbol: Foam::reduce(double&, Foam::sumOp<double> const&, int, int)
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(Foam::fvMatrix<double>::relax(double))

ld: error: undefined symbol: Foam::UPstream::nRequests()
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate())

ld: error: undefined symbol: Foam::UPstream::waitRequests(int)
>>> referenced by acousticFoam.C
>>>               /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64GccDPInt32Opt/applications/solvers/acoustic/acousticFoam/acousticFoam.o:(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate())
c++: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/wmake/makefiles/general:150: /disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/bin/acousticFoam] Error 1
make[3]: Leaving directory '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/applications/solvers/acoustic/acousticFoam'
make[2]: *** [/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/wmake/makefiles/apps:28: acousticFoam] Error 2
make[2]: Leaving directory '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/applications/solvers/acoustic'
make[1]: *** [/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/wmake/makefiles/apps:28: acoustic] Error 2
make[1]: Leaving directory '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/applications/solvers'
*** Error code 2
        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          This looks like there is still some problem with how the MPI is defined and the LD_LIBRARY_PATH environ is set.

          In OpenFOAM all of the MPI calls are wrapped into a Pstream library, which provides a level of vendor abstraction and also supports some serialize/deserialize operations.

          Going from your platforms path "/some-dir/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt", you should expect to see these types of entries in your LD_LIBRARY_PATH:

          • /some-dir/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/lib/sys-openmpi
          • /some-dir/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/lib
          • /some-dir/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/lib/dummy

          The lib/sys-openmpi (the name depends on the MPI vendor), should have a libPstream.so which 'nm -C' should show to contain those symbols.

          So either the library didn't get compiled properly, the environment is weird, or you are using a linker that needs more information than usual.

          On my installation, that libPstream.so does have a resolved symbol:

          0000000000011b00 T Foam::UPstream::nRequests()

          The odd thing is that even if your MPI selection is somehow incorrect, it should fallback to the entries in the lib/dummy where there is a second libPstream.so containing only stubs (they trigger a warning/error if actually used to try running in parallel).

          Not sure if this information helped...

          BTW: the runtime link dependency on libPstream comes through with the libOpenFOAM : given by the src/OpenFOAM/Make/options

          Edited by Mark OLESEN
        • Yuri Z
          Yuri Z @yurivict ·
          Author

          ./work/OpenFOAM-v2112/platforms/linux64GccDPInt32Opt/lib/sys-openmpi/libPstream.so has Foam::UPstream::nRequests(), but the link line doesn't contain -lPstream or similar.

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          The linkage against libPstream is usually implicit, but some linkers need to know about it explicitly. For example,

          So it sounds like you have some slightly different linker, or the regular one but one that flags unresolved symbols as an error. If you want to explicitly force use of the gold linker (for example), the WM_COMPILE_CONTROL variable supports that (see etc/bashrc). Otherwise as you can see from the contents of the above files, the FOAM_EXTRA_LDFLAGS provides you some other override control. But first need to see what your linker is, and what it wants.

          BTW: we have link rules for the mold linker, but only for clang since the gcc equivalent gets a bit messy. Not sure if you have that one on FreeBSD.

          Edited by Mark OLESEN
          • Yuri Z
            Yuri Z @yurivict ·
            Author

            I applied this patch that might be related:

            --- wmake/rules/General/Gcc/link-c++.orig       2022-06-21 07:49:25 UTC
+++ wmake/rules/General/Gcc/link-c++
@@ -1,11 +1,7 @@
 LINK_LIBS   = $(c++DBUG)
 
 LINKLIBSO   = $(CC) $(c++FLAGS) -shared \
-    -Xlinker --add-needed \
-    -Xlinker --no-as-needed \
     $(FOAM_EXTRA_LDFLAGS)
  
 LINKEXE     = $(CC) $(c++FLAGS) \
-    -Xlinker --add-needed \
-    -Xlinker --no-as-needed \
     $(FOAM_EXTRA_LDFLAGS)

            This is because I use clang and it doesn't know about -Xlinker. This may have made symbol lookup more strict.

            The linker is:

            $ ld --version
LLD 13.0.0 (FreeBSD llvmorg-13.0.0-0-gd7b669b3a303-1400002) (compatible with GNU linkers)
          • Mark OLESEN
            Mark OLESEN @mark ·
            Maintainer

            This is because I use clang and it doesn't know about -Xlinker. This may have made symbol lookup more strict.

            OK that explains quite a lot. In that case, do not patch anything at all dealing with Gcc. You should be using WM_COMPILER=Clang ! Might still need to have (WM_COMPILE_CONTROL="+lld"), but try that later.

            Take a look at the Clang linkage rules

            AFAIK clang does know about -Xlinker but just perhaps not with the original gcc combination.

            Edited by Mark OLESEN
          • Please register or sign in to reply
        • Yuri Z
          Yuri Z @yurivict ·
          Author

          I am trying with WM_COMPILER=Clang, thanks for suggesting this. Builds also run in single-CPU despite the -j flag for some reason, so it would take many hours.

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          If you specify -j it will default to using all available cores that it can detect. If the detection fails, it falls back to single core. I'm guessing that the detection magic needs to be different:

          nCores=$(getconf _NPROCESSORS_ONLN 2>/dev/null) || nCores=1

          The getconf command is POSIX, but _NPROCESSOR_ONLN probably is Linux-specific. You'll need to figure out different magic for getting the number of available cores.

          In the meantime, to speed things up, you should just use wmake or Allwmake with '-j N', where N is the number of procs you have.

        • Yuri Z
          Yuri Z @yurivict ·
          Author

          nCores=$(getconf _NPROCESSORS_ONLN 2>/dev/null) || nCores=1 works and evaluates to 8, but then it still runs on 1 CPU.

          #2519

        • Mark OLESEN
          Mark OLESEN @mark ·
          Maintainer

          Source code changes needed:

          • src/OSspecific/POSIX/signals/sigFpe.C
            • contains linux,apple specific SIG_FPE handling and malloc filling with NaN. Need to check what works for FreeBSD.
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        • Loading
        Please register or sign in to reply