Skip to content
Snippets Groups Projects

Build with AOCC Compiler Fails

    • Closed Issue created by Nikola Majksner @majksner

    Hi there,

    I'm trying to build OpenFOAM v1912 with the AOCC compiler that is optimized for the new AMD processors. But I'm getting an error at the very end of the compilation process when the OpenFOAM applications are getting compiled.

    OS: Ubuntu 18.04

    OpenFOAM Version: v1912

    Compiler: AOCC(Clang)

    Below are the commands that I'm running:

    $ apt-get install build-essential flex bison cmake zlib1g-dev libboost-system-dev libboost-thread-dev libopenmpi-dev openmpi-bin gnuplot libreadline-dev libncurses-dev libxt-dev libscotch-dev libcgal-dev curl wget

$ wget https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz

$ wget https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz

$ mkdir /opt/OpenFOAM && tar -xzf OpenFOAM-v1912.tgz -C /opt/OpenFOAM && tar -xzf ThirdParty-v1912.tgz -C /opt/OpenFOAM

$ sed -i 's/export WM_COMPILER=.*/export WM_COMPILER=Clang/' /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc

$ source /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc

$ curl 'https://developer.amd.com/aocc-compiler-eula/' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-GB,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'Origin: https://developer.amd.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://developer.amd.com/aocc-compiler-eula/' -H 'Cookie: c_slidebox_lists=; AKA_A2=A; ak_bmsc=08125A7934F9BC415C45AA72039B16E35435930DA136000064E6685E238A1876~pldSTaRB4wo4gj/7xqZwXbAwCMYYxDpl7AudDCN5q/uyPftrKXIBfjWmPvOTtHqaQALZ5YfYDBwbjJu6wqJwvtJIMB+WaJ1MWYgiREFZ77EA7xTBk7xsVM7E8O2+qzX9Yqf4o9fkwDuK3BKxyT97gLGgIz/kQZhjxmxqGEkfa3QRzWYj5Ar4onwEXHpr7YncScOzkQotLixqAh3bf3Ekhfu54ZkqnuAOIPl6+IyTwEdFg=; c_rurl=https%3A//developer.amd.com/aocc-compiler-eula/' -H 'Upgrade-Insecure-Requests: 1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: Trailers' --data 'amd_developer_central_nonce=7a6cd4da48&_wp_http_referer=%2Faocc-compiler-eula%2F&f=YW9jYy1jb21waWxlci0yLjEuMF8xX2FtZDY0LmRlYg%3D%3D' --output aocc.deb

$ dpkg -i aocc.deb

$ source /opt/AMD/aocc-compiler-2.1.0/setenv_AOCC.sh

$ foam

$ ./Allwmake -j -s -l

    Most of the commands are taken from https://www.openfoam.com/documentation/system-requirements.php and https://www.openfoam.com/code/build-guide.php

    Changing back export WM_COMPILER=Gcc in /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc results in successful build of OpenFOAM

    Attached is the output of compile process.

    Thanks,

    log.linux64ClangDPInt32Opt

    Child items

    0
    Show labels

      Activity

      • Andrew Heather
        Andrew Heather @andy ·
        Owner

        @mark

      • Mark OLESEN assigned to @mark

        assigned to @mark

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        The AOCC linker doesn't like the (now deprecated) --add-needed option and does not understand the newer --copy-dt-needed-entries option. Even so, there seems to be something else going on there as well.

        I'll reach out to the AMD guys and see what they say.

      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        @mark Any updates?

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        Sorry, not had time to follow-up much more

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        Did some follow-up. The basic linker issue is solved (will get something onto develop soon), but there is still an issue with linking some solvers.

        The AOCC seems to treat duplicated include directories by discarding the first one. Regular clang and gcc discard the second one. Remembering we always have an -I. in the wmake rules, this AOCC behaviour means that Make/options like the following:

        EXE_INC = -I. -I../XiFoam ...

        Will remove the first duplicated local directory and thus include files in ../XiFoam before ones in ./ !!

        This looks to me like a compiler bug (I've flagged AMD for possible confirmation). We can see if they come up with a fix or an internal flag to change the behaviour. If neither of those happen, we can avoid the problem by making certain that the include happens for the quoted includes only, which puts it into a different list. In this case the Make/options would be changed to the following:

        EXE_INC = -iquote. -I../XiFoam ...

        @andy - this might be an OK change to make anyhow. If we are referencing the local directory, there should not be any #include <..> syntax, only #include ".." lines. And this should ensure that it will push to the top of the search stack.

        Edited by Mark OLESEN
      • Mark OLESEN mentioned in commit 595579e0

        mentioned in commit 595579e0

      • Mark OLESEN mentioned in commit b3464d8a

        mentioned in commit b3464d8a

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        Hi @majksner

        If you want to try things out, either test with the newest develop branch, or apply the changes from the two commits listed above. From those, b3464d8a is the important one.

        Edited by Mark OLESEN
      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        @mark Thank you, I'll try it out.

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        Hi @majksner - any updates?

      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        I haven't had a chance to try it yet. I'll give it a try as soon as I can and let you know.

      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        I've tried to build the latest version (20.06) but I'm still getting an error probably at the last part of the build process. See log for more details.

        log.linux64AmdDPInt32Opt

        Edited by Nikola Majksner
      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        The good news is that you have actually made it quite far.

        Try to ignore all these boost/cgal warnings (ugly, but known). See if the final failure in foamyHexMesh gets fixed if you change:

        applications/utilities/mesh/generation/foamyMesh/foamyHexMesh/Make/options

         EXE_LIBS = \
     ${CGAL_LIBS} \
     -lconformalVoronoiMesh \
+    -lfileFormats \
+    -lsurfMesh \
     -lmeshTools \
     -ldecompositionMethods \
     -ldecompose \

        Not sure why this didn't get caught before, but thanks to your persistence, we'll eventually get it solved!

        BTW: for these "picky" linkage issues, I generally rely on the mingw builds flagging them (dll linkage can be even pickier), but no boost/cgal for cross-compilation at the moment and thus these foamy things get missed.

        If you hit other similar linkage issues, see if similar changes fix things and keep us updated.

        Often (but not always), if the Make/options has things like -I$(LIB_SRC)/fileFormats/lnInclude it will need a corresponding -lfileFormats, for example. There a few cases where the fileFormats info is header-only, but rare.

        Once again, thanks for helping!

      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        I'm glad I can help. I've re-run ./Allwmake -j12 -s -l after I've modified file you suggested. Compilation process seems to be successful but I see some errors in the wmake (check attached log file for more info).

        log.linux64AmdDPInt32Opt

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        The only errors I could see are need the beginning:

        gcc=/usr/bin/gcc
clang=
mpirun=/usr/bin/mpirun
make=/usr/bin/make
cmake=/usr/bin/cmakeang++: Command not found

        and of course part way through

        make[3]: clang++: Command not found

        Looks like the compiler settings got trashed somewhere.

      • Mark OLESEN mentioned in commit 5dc04530

        mentioned in commit 5dc04530

      • Mark OLESEN
        Mark OLESEN @mark ·
        Maintainer

        I think that this issue is actually solved, but still waiting for conformation - @majksner ??

      • Nikola Majksner
        Nikola Majksner @majksner ·
        Author

        I'm sorry, I haven't time to check. You can close the issue for now. I'll revisit it at some point and get back to in case of problems.

      • Nikola Majksner closed

        closed

      Please register or sign in to reply