Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-11-17T01:57:06Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3761Framework: do Trilinos teams have repo read access?2018-11-17T01:57:06ZJames WillenbringFramework: do Trilinos teams have repo read access?*Created by: jhux2*
@trilinos/framework @srajama1 (product owner) @maherou @jwillenbring @bartlettroscoe
I would like to be able to assign the @trilinos/muelu team as a reviewer for MueLu-related PRs. According to [this](https://he...*Created by: jhux2*
@trilinos/framework @srajama1 (product owner) @maherou @jwillenbring @bartlettroscoe
I would like to be able to assign the @trilinos/muelu team as a reviewer for MueLu-related PRs. According to [this](https://help.github.com/articles/requesting-a-pull-request-review/) page, this should be possible _if_ the team has read permission for the repo.
Question: Do Trilinos teams have read permissions for the Trilinos repo? If not, would it be possible to allow teams read access, or is there a good reason for not doing so?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3755"mpi.h" not found2018-11-01T20:34:28ZJames Willenbring"mpi.h" not found*Created by: teamblubee*
I saw the discussions about using <mpi.h> instead of "mpih."
I am having a build failure because this file:
Trilinos-d0a8f5e2bc674318a8579187c23112f26e092ce1/packages/teuchos/core/src/Teuchos_GlobalMPISessio...*Created by: teamblubee*
I saw the discussions about using <mpi.h> instead of "mpih."
I am having a build failure because this file:
Trilinos-d0a8f5e2bc674318a8579187c23112f26e092ce1/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp
is including "mpi.h"
There's a reference to a particular bugzilla that I do not have access to: https://software.sandia.gov/bugzilla/show_bug.cgi?id=5631
Is there any possible way to fix this upstream?
This is the configure argument that I am running; ${LOCALBASE} = /usr/local
```shell
CMAKE_ARGS+= -GNinja \
-DCMAKE_INSTALL_RPATH="${PREFIX}/lib" \
-DBUILD_SHARED_LIBS=ON \
-DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES=OFF \
-DTrilinos_ENABLE_Epetra=ON \
-DTrilinos_ENABLE_EpetraExt=ON \
-DTrilinos_ENABLE_Amesos=ON \
-DTrilinos_ENABLE_Epetra=ON \
-DTrilinos_ENABLE_Ifpack=ON \
-DTrilinos_ENABLE_AztecOO=ON \
-DTrilinos_ENABLE_Sacado=ON \
-DTrilinos_ENABLE_Teuchos=ON \
-DTrilinos_ENABLE_MueLu=ON \
-DTrilinos_ENABLE_ML=ON \
-DTrilinos_ENABLE_ROL=ON \
-DTrilinos_ENABLE_Fortran=OFF \
-DTrilinos_ENABLE_Zoltan=ON \
-DTPL_ENABLE_DLlib=OFF \
-DTPL_ENABLE_MPI=ON \
-DMPI_USE_COMPILER_WRAPPERS=ON \
-DMPI_C_COMPILER:FILEPATH="${LOCALBASE}/bin/mpicc" \
-DMPI_CXX_COMPILER:FILEPATH="${LOCALBASE}/bin/mpic++" \
-DMPI_Fortran_COMPILER:FILEPATH="${LOCALBASE}/bin/mpif77" \
-DCMAKE_C_COMPILER:FILEPATH="${LOCALBASE}/bin/mpicc" \
-DCMAKE_CXX_COMPILER:FILEPATH="${LOCALBASE}/bin/mpic++" \
-DCMAKE_Fortran_COMPILER:FILEPATH="${LOCALBASE}/bin/mpif77" \
-DMPI_BASE_DIR="${LOCALBASE}"
```
best
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3694CMake Fortran compiler detection fails2018-11-13T16:29:16ZJames WillenbringCMake Fortran compiler detection fails*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that...*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/<teamName>
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
I am trying to use the Ninja generator to compile Trilinos using the newly open source Fortran compiler; Flang: https://github.com/flang-compiler/flang
The cmake test fails
```shell
Probing the environment ...
-- USE_XSDK_DEFAULTS='FALSE'
-- BUILD_SHARED_LIBS='FALSE'
-- CMAKE_BUILD_TYPE='RELEASE'
-- CMAKE_C_COMPILER_ID='Clang'
-- CMAKE_C_COMPILER_VERSION='5.0.1'
-- CMAKE_CXX_COMPILER_ID='Clang'
-- CMAKE_CXX_COMPILER_VERSION='5.0.1'
-- The Fortran compiler identification is Flang 99.99.1
-- Check for working Fortran compiler: /usr/local/bin/flang
-- Check for working Fortran compiler: /usr/local/bin/flang -- broken
CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:45 (message):
The Fortran compiler
"/usr/local/bin/flang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1830 (ENABLE_LANGUAGE)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
but if I manually run the program and test it works
creating test program with the same contents of the above cmake command
```Fortran
PROGRAM TESTFortran
PRINT *, 'Hello'
END
```
save that as test.f
flang test.f
```shell
flang -v test.f
clang version 6.0.1
Target: x86_64-portbld-freebsd12.0
Thread model: posix
InstalledDir: /usr/local/flang/bin
"/usr/local/flang/bin/flang1" test.f -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x400000 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -tp px -x 57 0xfb0000 -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def __FreeBSD__ -def __NO_MATH_INLINES -def __LP64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __x86_64 -def __x86_64__ -def __amd_64__amd64__ -def __k8 -def __k8__ -def __THROW= -def __extension__= -def __PGLLVM__ -nofreeform -idir /usr/local/include -idir /usr/local/flang/include -idir /usr/local/llvm60/include -idir /usr/local/llvm60/lib/clang/6.0.1/include -vect 48 -x 54 1 -x 70 0x40000000 -y 163 0xc0000000 -x 189 0x10 -stbfile test-2a5590.stb -modexport test-2a5590.cmod -modindex test-2a5590.cmdx -output test-2a5590.ilm
"/usr/local/flang/bin/flang2" test-2a5590.ilm -y 129 2 -ieee 0 -fn test.f -opt 0 -terse 1 -inform warn -inform warn -x 68 0x1 -x 51 0x20 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 127 17 -x 19 0x400000 -x 28 0x40000 -x 120 0x10000000 -x 70 0x8000 -x 122 1 -x 125 0x20000 -x 164 0x800000 -quad -x 59 4 -tp px -x 120 0x1000 -x 124 0x1400 -y 15 2 -x 57 0x3b0000 -x 58 0x48000000 -x 49 0x100 -astype 0 -x 183 4 -x 121 0x800 -x 54 0x10 -x 70 0x40000000 -x 249 50 -x 124 1 -y 163 0xc0000000 -x 189 0x10 -y 189 0x4000000 -x 183 0x10 -stbfile test-2a5590.stb -asm /tmp/test-2a5590.ll
"/usr/local/flang/bin/clang-6.0" -cc1 -triple x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name test.f -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/local/flang/lib/clang/6.0.1 -Wno-unused-command-line-argument -fdebug-compilation-dir /wrkdirs/usr/ports/math/trilinos/work/.build -ferror-limit 19 -fmessage-length 294 -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-02b4b5.o -x ir /tmp/test-2a5590.ll
clang -cc1 version 6.0.1 based upon LLVM 6.0.1 default target x86_64-portbld-freebsd12.0
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/flang/lib -L/usr/local/llvm60/lib -L/usr/lib -lflangmain -lm -lflang -lflangrti -lomptarget -lompstub -lomp -lpgmath -lm -lexecinfo /tmp/test-02b4b5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
```
running
```shell
./a.out
Hello
```
## Possible Solution
properly detect flang compiler?
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
./configure -GNinja;
I already have the Kitware ninja fork that supports fortran.
## Additional Information
```shell
//Enable support for the TPL ExodusII in all supported Trilinos
// packages. This can be set to 'ON', 'OFF', or left empty ''.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_6274f"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_6274f.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_62
74f.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2d
fa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3693CMake Fortran test fails2018-11-08T18:00:55ZJames WillenbringCMake Fortran test fails*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that...*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/<teamName>
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
I am trying to use the Ninja generator to compile Trilinos using the newly open source Fortran compiler; Flang: https://github.com/flang-compiler/flang
The cmake test fails
```shell
Probing the environment ...
-- USE_XSDK_DEFAULTS='FALSE'
-- BUILD_SHARED_LIBS='FALSE'
-- CMAKE_BUILD_TYPE='RELEASE'
-- CMAKE_C_COMPILER_ID='Clang'
-- CMAKE_C_COMPILER_VERSION='5.0.1'
-- CMAKE_CXX_COMPILER_ID='Clang'
-- CMAKE_CXX_COMPILER_VERSION='5.0.1'
-- The Fortran compiler identification is Flang 99.99.1
-- Check for working Fortran compiler: /usr/local/bin/flang
-- Check for working Fortran compiler: /usr/local/bin/flang -- broken
CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:45 (message):
The Fortran compiler
"/usr/local/bin/flang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1830 (ENABLE_LANGUAGE)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
but if I manually run the program and test it works
creating test program with the same contents of the above cmake command
```Fortran
PROGRAM TESTFortran
PRINT *, 'Hello'
END
```
save that as test.f
flang test.f
```shell
flang -v test.f
clang version 6.0.1
Target: x86_64-portbld-freebsd12.0
Thread model: posix
InstalledDir: /usr/local/flang/bin
"/usr/local/flang/bin/flang1" test.f -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x400000 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -tp px -x 57 0xfb0000 -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def __FreeBSD__ -def __NO_MATH_INLINES -def __LP64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __x86_64 -def __x86_64__ -def __amd_64__amd64__ -def __k8 -def __k8__ -def __THROW= -def __extension__= -def __PGLLVM__ -nofreeform -idir /usr/local/include -idir /usr/local/flang/include -idir /usr/local/llvm60/include -idir /usr/local/llvm60/lib/clang/6.0.1/include -vect 48 -x 54 1 -x 70 0x40000000 -y 163 0xc0000000 -x 189 0x10 -stbfile test-2a5590.stb -modexport test-2a5590.cmod -modindex test-2a5590.cmdx -output test-2a5590.ilm
"/usr/local/flang/bin/flang2" test-2a5590.ilm -y 129 2 -ieee 0 -fn test.f -opt 0 -terse 1 -inform warn -inform warn -x 68 0x1 -x 51 0x20 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 127 17 -x 19 0x400000 -x 28 0x40000 -x 120 0x10000000 -x 70 0x8000 -x 122 1 -x 125 0x20000 -x 164 0x800000 -quad -x 59 4 -tp px -x 120 0x1000 -x 124 0x1400 -y 15 2 -x 57 0x3b0000 -x 58 0x48000000 -x 49 0x100 -astype 0 -x 183 4 -x 121 0x800 -x 54 0x10 -x 70 0x40000000 -x 249 50 -x 124 1 -y 163 0xc0000000 -x 189 0x10 -y 189 0x4000000 -x 183 0x10 -stbfile test-2a5590.stb -asm /tmp/test-2a5590.ll
"/usr/local/flang/bin/clang-6.0" -cc1 -triple x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name test.f -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/local/flang/lib/clang/6.0.1 -Wno-unused-command-line-argument -fdebug-compilation-dir /wrkdirs/usr/ports/math/trilinos/work/.build -ferror-limit 19 -fmessage-length 294 -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-02b4b5.o -x ir /tmp/test-2a5590.ll
clang -cc1 version 6.0.1 based upon LLVM 6.0.1 default target x86_64-portbld-freebsd12.0
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/flang/lib -L/usr/local/llvm60/lib -L/usr/lib -lflangmain -lm -lflang -lflangrti -lomptarget -lompstub -lomp -lpgmath -lm -lexecinfo /tmp/test-02b4b5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
```
running
```shell
./a.out
Hello
```
## Possible Solution
properly detect flang compiler?
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
./configure -GNinja;
I already have the Kitware ninja fork that supports fortran.
## Additional Information
```shell
//Enable support for the TPL ExodusII in all supported Trilinos
// packages. This can be set to 'ON', 'OFF', or left empty ''.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_6274f"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_6274f.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_62
74f.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2d
fa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3692Fortran compiler check fails2018-11-08T18:01:16ZJames WillenbringFortran compiler check fails*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that...*Created by: teamblubee*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/<teamName>
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
I am trying to use the Ninja generator to compile Trilinos using the newly open source Fortran compiler; Flang: https://github.com/flang-compiler/flang
The cmake test fails
```shell
Probing the environment ...
-- USE_XSDK_DEFAULTS='FALSE'
-- BUILD_SHARED_LIBS='FALSE'
-- CMAKE_BUILD_TYPE='RELEASE'
-- CMAKE_C_COMPILER_ID='Clang'
-- CMAKE_C_COMPILER_VERSION='5.0.1'
-- CMAKE_CXX_COMPILER_ID='Clang'
-- CMAKE_CXX_COMPILER_VERSION='5.0.1'
-- The Fortran compiler identification is Flang 99.99.1
-- Check for working Fortran compiler: /usr/local/bin/flang
-- Check for working Fortran compiler: /usr/local/bin/flang -- broken
CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:45 (message):
The Fortran compiler
"/usr/local/bin/flang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1830 (ENABLE_LANGUAGE)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
but if I manually run the program and test it works
creating test program with the same contents of the above cmake command
```Fortran
PROGRAM TESTFortran
PRINT *, 'Hello'
END
```
save that as test.f
flang test.f
```shell
flang -v test.f
clang version 6.0.1
Target: x86_64-portbld-freebsd12.0
Thread model: posix
InstalledDir: /usr/local/flang/bin
"/usr/local/flang/bin/flang1" test.f -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x400000 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -tp px -x 57 0xfb0000 -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def __FreeBSD__ -def __NO_MATH_INLINES -def __LP64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __x86_64 -def __x86_64__ -def __amd_64__amd64__ -def __k8 -def __k8__ -def __THROW= -def __extension__= -def __PGLLVM__ -nofreeform -idir /usr/local/include -idir /usr/local/flang/include -idir /usr/local/llvm60/include -idir /usr/local/llvm60/lib/clang/6.0.1/include -vect 48 -x 54 1 -x 70 0x40000000 -y 163 0xc0000000 -x 189 0x10 -stbfile test-2a5590.stb -modexport test-2a5590.cmod -modindex test-2a5590.cmdx -output test-2a5590.ilm
"/usr/local/flang/bin/flang2" test-2a5590.ilm -y 129 2 -ieee 0 -fn test.f -opt 0 -terse 1 -inform warn -inform warn -x 68 0x1 -x 51 0x20 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 127 17 -x 19 0x400000 -x 28 0x40000 -x 120 0x10000000 -x 70 0x8000 -x 122 1 -x 125 0x20000 -x 164 0x800000 -quad -x 59 4 -tp px -x 120 0x1000 -x 124 0x1400 -y 15 2 -x 57 0x3b0000 -x 58 0x48000000 -x 49 0x100 -astype 0 -x 183 4 -x 121 0x800 -x 54 0x10 -x 70 0x40000000 -x 249 50 -x 124 1 -y 163 0xc0000000 -x 189 0x10 -y 189 0x4000000 -x 183 0x10 -stbfile test-2a5590.stb -asm /tmp/test-2a5590.ll
"/usr/local/flang/bin/clang-6.0" -cc1 -triple x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name test.f -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/local/flang/lib/clang/6.0.1 -Wno-unused-command-line-argument -fdebug-compilation-dir /wrkdirs/usr/ports/math/trilinos/work/.build -ferror-limit 19 -fmessage-length 294 -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-02b4b5.o -x ir /tmp/test-2a5590.ll
clang -cc1 version 6.0.1 based upon LLVM 6.0.1 default target x86_64-portbld-freebsd12.0
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/flang/lib -L/usr/local/llvm60/lib -L/usr/lib -lflangmain -lm -lflang -lflangrti -lomptarget -lompstub -lomp -lpgmath -lm -lexecinfo /tmp/test-02b4b5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
```
running
```shell
./a.out
Hello
```
## Possible Solution
properly detect flang compiler?
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
./configure -GNinja;
I already have the Kitware ninja fork that supports fortran.
## Additional Information
```shell
//Enable support for the TPL ExodusII in all supported Trilinos
// packages. This can be set to 'ON', 'OFF', or left empty ''.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_6274f"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_6274f.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_62
74f.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2d
fa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3700Framework / TriBITS: download-cmake.py no longer points to a valid cmake2018-10-23T23:58:36ZJames WillenbringFramework / TriBITS: download-cmake.py no longer points to a valid cmake*Created by: csiefer2*
This guy: Trilinos/cmake/tribits/python_utils/download-cmake.py
Tries to download this: http://cmake.org/files/v2.8/cmake-3.10.0-Linux-i386.tar.gz
Which give ye ol' 404.
I discovered this in an initial se...*Created by: csiefer2*
This guy: Trilinos/cmake/tribits/python_utils/download-cmake.py
Tries to download this: http://cmake.org/files/v2.8/cmake-3.10.0-Linux-i386.tar.gz
Which give ye ol' 404.
I discovered this in an initial setups of nightly testing on one of my machines.
@bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3673Framework: Fix bug in PullRequestLinuxDriver for SERIAL builds2018-11-07T17:46:18ZJames WillenbringFramework: Fix bug in PullRequestLinuxDriver for SERIAL builds*Created by: william76*
@trilinos/framework
@jwillenbring
@prwolfe
the update to `PullRequestLinuxDriver.sh` script to wildcard "*_SERIAL" is wrong.
https://github.com/trilinos/Trilinos/blob/b64a5a4498abe7aedd1ffe42fb4795d...*Created by: william76*
@trilinos/framework
@jwillenbring
@prwolfe
the update to `PullRequestLinuxDriver.sh` script to wildcard "*_SERIAL" is wrong.
https://github.com/trilinos/Trilinos/blob/b64a5a4498abe7aedd1ffe42fb4795d756331615/cmake/std/PullRequestLinuxDriver.sh#L225-L229
This If/Else condition fails to correctly identify the _SERIAL piece, take this sample test code to illustrate:
```bash
#!/usr/bin/env bash
# uncomment one of these
JOB_BASE_NAME="Trilinos_pullrequest_gcc_4.9.3_SERIAL"
# JOB_BASE_NAME="Trilinos_pullrequest_gcc_4.9.3"
echo "JOB_BASE_NAME: $JOB_BASE_NAME"
echo "Test old method:"
if [ "*_SERIAL" != "${JOB_BASE_NAME:?}" ]; then
echo -e "- Job is MPI"
else
echo -e "- Job is SERIAL"
fi
echo "Test new method:"
regex=".*(_SERIAL)$"
if [[ ! ${JOB_BASE_NAME:?} =~ ${regex} ]]; then
echo -e "- Job name is MPI"
else
echo -e "- Job name is SERIAL"
fi
```
Run it with the non-serial version of `JOB_BASE_NAME` and you get:
```
$ ./test.sh
JOB_BASE_NAME: Trilinos_pullrequest_gcc_4.9.3
Test old method:
- Job is MPI
Test new method:
- Job name is MPI
```
Looks correct, right? Nope, it's just lucking into it via a bug. Run it with the `_SERIAL` job and you get this:
```
$ ./test.sh
JOB_BASE_NAME: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Test old method:
- Job is MPI
Test new method:
- Job name is SERIAL
```
The method just comparing against "*_SERIAL" incorrectly thinks the string matches. I think this expression will always evaluate to `true` which is not what we want.
## TODO
- [x] Fix the script to use the new method described here to make that conditional operate properly.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3670Framework: Still testing GCC 4.7.2 in Experimental Track2018-11-13T15:50:56ZJames WillenbringFramework: Still testing GCC 4.7.2 in Experimental Track*Created by: csiefer2*
Trilinos will not configure with a GCC that old. Please shoot this test.*Created by: csiefer2*
Trilinos will not configure with a GCC that old. Please shoot this test.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3628Did CMake 3.10.0 requirement break the check-in test script?2018-10-31T23:57:31ZJames WillenbringDid CMake 3.10.0 requirement break the check-in test script?*Created by: mhoemmen*
@trilinos/framework @bartlettroscoe
The latest changes that require CMake 3.10.0 seem to have broken the check-in test script. I invoked the script like this:
```
.../Trilinos/checkin-test.py --ctest-timeou...*Created by: mhoemmen*
@trilinos/framework @bartlettroscoe
The latest changes that require CMake 3.10.0 seem to have broken the check-in test script. I invoked the script like this:
```
.../Trilinos/checkin-test.py --ctest-timeout=400 --disable-packages=PyTrilinos,Claps,TriKota,Domi,STKSearch,Moertel,Shards --skip-case-no-email --allow-no-pull --enable-all-packages=off --default-builds= --extra-builds=MPI_DEBUG_EX --enable-packages=TpetraCore,Zoltan2,Amesos2 --configure
```
with the following modules loaded:
```
1) sems-env 3) sems-cmake/3.12.2 5) sems-openmpi/1.10.1 7) sems-boost/1.59.0/base 9) sems-hdf5/1.8.12/parallel 11) sems-zlib/1.2.8/base
2) kokkos-env 4) sems-gcc/4.9.3 6) sems-python/2.7.9 8) sems-superlu/4.3/base 10) sems-netcdf/4.4.1/exo_parallel 12) sems-parmetis/4.0.3/parallel
```
I get the following output:
```
...
B) Do the configuration with CMake (MPI_DEBUG_EX) ...
Running: rm CMakeCache.txt
Running: rm -rf CMakeFiles
Running: ./do-configure
Writing console output to file configure.out ...
Runtime for command = 0.302733 minutes
Configure failed returning 1!
Traceback (most recent call last):
File "/scratch/prj/Trilinos/Trilinos/cmake/tribits/ci_support/CheckinTest.py", line 1563, in runBuildTestCase
raise Exception("Configure failed!")
Exception: Configure failed!
E) Analyze the overall results and send email notification (MPI_DEBUG_EX) ...
E.1) Determine what passed and failed ...
The pull step was not performed!
The configure FAILED!
```
Should I consider the check-in test script dead? It was a useful tool & I'm sad to see it go.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3625Framework: Separate merge from test execution in PullRequestLinuxDriver.sh2018-11-08T16:41:56ZJames WillenbringFramework: Separate merge from test execution in PullRequestLinuxDriver.sh*Created by: william76*
@trilinos/framework
Currently, if `cmake/std/PullRequestLinuxDriver.sh` is modified it might not work properly for the Develop->to->Master if the script has been changed since the 'version' of the script bein...*Created by: william76*
@trilinos/framework
Currently, if `cmake/std/PullRequestLinuxDriver.sh` is modified it might not work properly for the Develop->to->Master if the script has been changed since the 'version' of the script being run will be the one that exists on master. If the change adds a new test, the dev->to->master test will fail because the if-then-else statement comparing job names for the new job won't exist in this piece:
```bash
if [ "Trilinos_pullrequest_gcc_4.8.4" == "${JOB_BASE_NAME:?}" ] ; then
source ${TRILINOS_DRIVER_SRC_DIR}/cmake/std/sems/PullRequestGCC4.8.4TestingEnv.sh
ierror=$?
if [[ $ierror != 0 ]]; then
echo "There was an issue loading the gcc environment. The error code was: $ierror"
exit $ierror
fi
elif [ ... ]
# other tests...
else
ierror=42
echo "There was an issue loading the proper environment. The error code was: $ierror"
exit $ierror
fi
```
In the case where an additional entry to this switch statement is made and is on the develop branch but not on the master branch, the script will fail because Jenkins is running the version of the script that lives on master because the script performs the merge of the test branch into master.
As part of a revamp of the PR driver script(s), we should split out the part of the script that merges the test branch into the master branch from the rest so that we can merge the develop branch into master separately from testing it within the Jenkins test.
@jwillenbring I didn't spend a ton of time writing this issue up... did I miss anything?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3611Sundance no longer configures with updated Trilinos and TriBITS2018-11-13T16:02:19ZJames WillenbringSundance no longer configures with updated Trilinos and TriBITS*Created by: bartlettroscoe*
@trilinos/framework
The package Sundance stored in the extra repo https://github.com/trilinos/Sundance does not configure with the current version of Trilinos 'develop'. The only automated Trilinos build...*Created by: bartlettroscoe*
@trilinos/framework
The package Sundance stored in the extra repo https://github.com/trilinos/Sundance does not configure with the current version of Trilinos 'develop'. The only automated Trilinos build that actually pulls in Sundance is the build `Linux-GCC-4.9.3-openmpi-1.8.7_Debug_DEV_Werror` posting the the "Experimental" CDash group shown today at:
* https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&parentid=4038223
In this build, Sundance fails to configure showing the configure failure [here](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4042789) which shows the configure failure:
```
Processing enabled package: Sundance (Libs, Tests, Examples)
adding Playa/src
-- DEPLIBS=''
adding Playa/tests
CMake Error at packages/Sundance/cmake/AddTestBatch.cmake:8 (PARSE_ARGUMENTS):
Unknown CMake command "PARSE_ARGUMENTS".
Call Stack (most recent call first):
packages/Sundance/Playa/tests/Operator/CMakeLists.txt:20 (ADD_TEST_BATCH)
```
TriBITS removed the deprecated function `PARSE_ARGUMENTS()` a long time ago in the TriBITS commit TriBITSPub/TriBITS@e7bfe1a5337f11a3b070a7a272032f6de430b482 on 5/19/2017 and was snapshotted to Trilinos 'develop' in the commit 12c4cf6defd5b5f4572a4ab52bb2920d24f4061b on 6/1/2017. That means that **Sundance has likely not been able to configure against the Trilinos 'develop' branch in over 16 months**!
But when the package-by-package mode was being used for this build as recently as 9/21/2018 shown [here](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&parentid=3959759&filtercount=2&showfilters=1&field1=buildstarttime&compare1=83&value1=4%20weeks%20ago&filtercombine=and), that configure failure only killed the build and testing of the Sundance package and therefore all of the other packages still got built and tests run. But when switching to the all-at-once mode as part of #1761 on 10/10/2018, that Sundance configure failure now stops the build and testing of all of the Trilinos packages. Therefore, this issue must be addressed.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3585Test Anasazi_Epetra_OrthoManagerGenTester_0_MPI_4 appears to be randomly fail...2019-04-02T18:21:50ZJames WillenbringTest Anasazi_Epetra_OrthoManagerGenTester_0_MPI_4 appears to be randomly failing in many builds including CI, PR, and ATDM builds*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/anasazi, @srajama1 (Trilinos Linear Solver Product Area Lead)
## Next Action Status
PR #4052 merged to 'develop' on 12/18/2018 but still failing after that. Next: Tr...*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/anasazi, @srajama1 (Trilinos Linear Solver Product Area Lead)
## Next Action Status
PR #4052 merged to 'develop' on 12/18/2018 but still failing after that. Next: Try to fix again?
## Description
It would seem that the test `Anasazi_Epetra_OrthoManagerGenTester_0_MPI_4` is very occasionally randomly failing in various builds. As shown in [this query](https://testing.sandia.gov/cdash-dev-view/queryTests.php?project=Trilinos&date=2018-10-09&filtercount=4&showfilters=1&filtercombine=and&field1=testname&compare1=61&value1=Anasazi_Epetra_OrthoManagerGenTester_0_MPI_4&field2=status&compare2=61&value2=failed&field3=details&compare3=64&value3=timeout&field4=buildstarttime&compare4=83&value4=2018-07-01), this test failed 10 times since 7/1/2018 in the builds:
* `Linux-GCC-4.8.4-MPI_RELEASE_DEBUG_SHARED_PT_OPENMP_CI` (post-push CI build): 1 time (today)
* `PR-XXXX-test-Trilinos_pullrequest_gcc_4.9.3-YYYY` (standard PR build): 4 times
* `PR-XXXX-test-Trilinos_pullrequest_gcc_4.8.4-YYYY` (standard PR build): 1 time
* `Trilinos-atdm-chama-intel-debug-openmp` (standard ATDM build): 1 time
* `Trilinos-atdm-rhel6-gnu-opt-openmp` (standard ATDM build): 2 times
* `Trilinos-atdm-waterman-cuda-9.2-debug` (standard ATDM build): 1 time
In each of these 10 failures in the last 3 months, such as the CI failure today shown [here](https://testing.sandia.gov/cdash-dev-view/testDetails.php?test=56264374&build=4031303), it shows failures like:
```
projectAndNormalizeGen() returned rank 5
|| <S,S> - I || after : 2.65912e-11
1|| S_in - X1*C1 - X2*C2 - S_out*B || : 1.70776e-09
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv tolerance exceeded! test failed!
```
The location of these failures seems to change in this test but all of the failures appear to be "tolerance exceeded! test failed!"
Is there some type of non-deterministic behavior in this test or in the underlying Anasazi code that allows for these types of random failures?
## Steps to Reproduce
Given that this test seems to be failing randomly only very occasionally, this might be hard to reproduce locally. But given that this has failed in the post-push GCC 4.8.4 CI build and the GCC 4.9.3 PR build one might be able to use one of those.
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3523install gitdist with trilinos install2018-09-27T17:02:35ZJames Willenbringinstall gitdist with trilinos install*Created by: rppawlo*
Is there any way we can get gitdist installed into the bin directory during trilinos installs? Might need a configure flag to enable/disable this capability?
@bartlettroscoe
@bathmatt *Created by: rppawlo*
Is there any way we can get gitdist installed into the bin directory during trilinos installs? Might need a configure flag to enable/disable this capability?
@bartlettroscoe
@bathmatt https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3510Kokkos: ‘bit_scan_reverse’ is not a member2018-09-27T15:42:01ZJames WillenbringKokkos: ‘bit_scan_reverse’ is not a member*Created by: dridzal*
@trilinos/kokkos
## Current Behavior
```
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp: In function ‘void {anonymous}::kokkos_internal_yield(unsig$...*Created by: dridzal*
@trilinos/kokkos
## Current Behavior
```
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp: In function ‘void {anonymous}::kokkos_internal_yield(unsig$
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp:70:15: error: ‘bit_scan_reverse’ is not a member of ‘Kokkos$
switch (Kokkos::Impl::bit_scan_reverse((i >> 2)+1u)) {
```
## Expectations
Trilinos should build.
## Motivation and Context
Can't sync ROL and Trilinos until this is fixed.
## Steps to Reproduce
Build Trilinos using the default SEMS checkin-test (pre-push) environment.
## Your Environment
Default SEMS checkin-test environment.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3515Framework: POSIX compatibility of build scripts2018-09-26T22:37:23ZJames WillenbringFramework: POSIX compatibility of build scripts*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be nice if the build scripts would work on all shells, and not just on bash. Examples of things that seem to create trouble are comparisons with `==` instead of `=` ...*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be nice if the build scripts would work on all shells, and not just on bash. Examples of things that seem to create trouble are comparisons with `==` instead of `=` and usage of the variable `BASH_SOURCE`.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3469Configuration of CUDA-enabled build fails2019-04-18T18:03:54ZJames WillenbringConfiguration of CUDA-enabled build fails*Created by: pelesh*
Configuration of a CUDA-enabled Tpetra/Kokkos build fails at the point where CMake checks for C++ compiler. The error message is:
```
Linking CXX executable cmTC_babeb
/usr/tce/packages/cmake/cmake-3.5.2/bi...*Created by: pelesh*
Configuration of a CUDA-enabled Tpetra/Kokkos build fails at the point where CMake checks for C++ compiler. The error message is:
```
Linking CXX executable cmTC_babeb
/usr/tce/packages/cmake/cmake-3.5.2/bin/cmake -E cmake_link_script
CMakeFiles/cmTC_babeb.dir/link.txt --verbose=1
/usr/tce/packages/openmpi/openmpi-2.0.0-gcc-6.1.0/bin/mpicxx
CMakeFiles/cmTC_babeb.dir/testCXXCompiler.cxx.o -o cmTC_babeb -rdynamic
nvcc fatal : Unknown option 'rdynamic,-fexceptions,-pthread'
gmake[1]: *** [cmTC_babeb] Error 1
```
It seems as if Kokkos' `nvc_wrapper` does not insert `-Xlinker` flags correctly.
I am building from current master branch on a system with following configuration:
```
$ module list
Currently Loaded Modules:
1) StdEnv 2) gcc/6.1.0 3) cuda/9.1.85 4) openmpi/2.0.0 5) cmake/3.5.2
```
The same issue occurs with different openmpi, CUDA, CMake and gcc versions.
I am following Tpetra build instructions from `$Trilinos/packages/tpetra/doc/FAQ.txt`, and I set environment variables like this:
```
export OMPI_CXX=${Trilinos}/packages/kokkos/bin/nvcc_wrapper
export CUDA_LAUNCH_BLOCKING=1
export CUDA_MANAGED_FORCE_DEVICE_ALLOC=1
```
I use following configuration script to set cmake options:
```
#!/bin/bash
cmake \
-D CMAKE_C_COMPILER="mpicc" \
-D CMAKE_CXX_COMPILER="mpicxx" \
-D CMAKE_Fortran_COMPILER="mpif90" \
\
-D Trilinos_CXX11_FLAGS="-std=c++11 --expt-extended-lambda" \
\
-D Trilinos_ENABLE_OpenMP=OFF \
-D TPL_ENABLE_Pthread=OFF \
\
-D Trilinos_ENABLE_Teuchos=ON \
-D Trilinos_ENABLE_Tpetra=ON \
-D Tpetra_INST_SERIAL=ON \
-D Tpetra_INST_OPENMP=OFF \
\
-D Trilinos_ENABLE_Kokkos=ON \
-D Trilinos_ENABLE_KokkosCore=ON \
-D Kokkos_ENABLE_Serial=ON \
-D Kokkos_ENABLE_OpenMP=OFF \
-D Kokkos_ENABLE_Pthread=OFF \
-D Kokkos_ENABLE_Cuda=ON \
-D Kokkos_ENABLE_Cuda_UVM=ON \
-D Kokkos_ENABLE_Cuda_Lambda=ON \
-D Kokkos_ENABLE_Cuda_Relocatable_Device_Code=OFF \
-D TPL_ENABLE_CUDA=ON \
\
-D TPL_ENABLE_MPI=ON \
-D MPI_USE_COMPILER_WRAPPERS=ON \
\
-D Tpetra_INST_CUDA:BOOL=ON \
../Trilinos
```
Any advice how to get past this point would be most appreciated.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3501Framework: Windows build not posting to dashboard2018-09-29T03:06:13ZJames WillenbringFramework: Windows build not posting to dashboard*Created by: csiefer2*
Again.*Created by: csiefer2*
Again.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3447download for Trilinos 12.12.1 is broken?2018-09-20T16:12:53ZJames Willenbringdownload for Trilinos 12.12.1 is broken?*Created by: boegel*
When I try to download Trilinos 12.12.1 via https://trilinos.org/download/, I end up with a broken link.
I considered downloading from https://github.com/trilinos/Trilinos/releases instead, but the source tarball...*Created by: boegel*
When I try to download Trilinos 12.12.1 via https://trilinos.org/download/, I end up with a broken link.
I considered downloading from https://github.com/trilinos/Trilinos/releases instead, but the source tarball tagged there for 12.12.1 seems to be something entirely different (e.g. `CTrilinos` is not in there).
Is the broken download via the website a known problem?
Is there another way to download the same `trilinos-12.12.1-Source.tar.gz` that was available via https://trilinos.org/download?
@trilinos/packagehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3445ThreadPool: Removal of ThreadPool from Trilinos2019-01-16T00:18:47ZJames WillenbringThreadPool: Removal of ThreadPool from Trilinos*Created by: kddevin*
@trilinos/stk @trilinos/framework @bartlettroscoe
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Cho...*Created by: kddevin*
@trilinos/stk @trilinos/framework @bartlettroscoe
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
Soon we will remove ThreadPool from the Trilinos code base.
Users of ThreadPool should respond to this issue ASAP with questions/concerns.
Within Trilinos, STKClassic depends on ThreadPool; STKClassic is also targeted for removal #3444 .
STKSearch claims a dependence on ThreadPool, but, in truth, does not need it; this claim of dependence will be removed.
## Motivation and Context
ThreadPool is no longer supported; it has been replaced by the far superior Kokkos toolkit.
Users of ThreadPool can migrate to Kokkos.
Removing unsupported, obsolete code is necessary to effectively maintain the Trilinos code base.
## Definition of Done
ThreadPool removed from stk_search dependencies
ThreadPool source code removed
STKClassic source code removed
STK/Trilinos integration and testing completed
## Possible Solution
Removal of ThreadPool is preferred.
If, for some reason, #3444 cannot be done, ThreadPool will move into the stk_classic directory to prevent further adoption by applications.
## Related Issues
* Is blocked by #3444
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3444STK: Removal of STKClassic (stk_classic) from Trilinos and STK2018-09-25T14:41:22ZJames WillenbringSTK: Removal of STKClassic (stk_classic) from Trilinos and STK*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/stk @trilinos/framework
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
Soon we will remove STKClassic (a.k.a. stk_classic) from the STK and Trilinos repos.
Users who depend on STKClassic should respond to this issue ASAP with questions and concerns. Thanks!
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
STKClassic is no longer supported; it has been replaced by the superior capabilities in STK.
Current STKClassic users can migrate to STK capabilities.
Removing unsupported, obsolete code is necessary to maintain the Trilinos code base.
## Definition of Done
Code and build options removed from Trilinos and STK code bases.
Remove unbuilt/untested trilinoscouplings/examples/example_Poisson_stkclassic.cpp
Remove ifdef-ed out stk_classic code from trilinoscouplings/examples/example_Poisson_stk.cpp
STK/Trilinos integration and tests complete.