"libpthreads"?

[Victor Eijkhout]

It looks like cmake bombs on a request to "-lpthreads". I have no idea why it is wanting that. Log files attached.

[Wolfgang Bangerth]

On 4/22/20 7:16 AM, Victor Eijkhout wrote:
> It looks like cmake bombs on a request to "-lpthreads". I have no idea why it
> is wanting that. Log files attached.

Hi Victor,
deal.II has a number of calls to the pthreads threading functions, so it needs
to link against the POSIX thread library. That would call for adding -lpthread
to the command line.

In your log file, the error comes from using -lpthreads (not the 's' at the
end). You don't say what the exact error message is, but I would suspect that
the problem results from this different spelling. Now, I looked into the
deal.II sources and I can't find any occurrence where we would test with this
spelling. What is your setting for CXXFLAGS, LDFLAGS, etc?

Best
W.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Victor Eijkhout]

> In your log file, the error comes from using -lpthreads (not the 's' at the end).

And by “not” you mean “note”?

> You don't say what the exact error message is,

Is the last error in the CMakeError.log the relevant one?

Configuration error: Cannot compile a test program with the final set of
compiler and linker flags:
CXX flags (DEBUG): -fpic -ansi -w2 -diag-disable=remark -wd21 -wd68 -wd135 -wd175 -wd177 -wd191 -wd193 -wd279 -wd327 -wd383 -wd981 -wd1418 -wd1478 -wd1572 -wd2259 -wd2536 -wd2651
-wd3415 -wd15531 -wd111 -wd128 -wd185 -wd186 -wd280 -qopenmp-simd -std=c++14 -Wno-parentheses -O0 -g -gdwarf-2 -grecord-gcc-switches -g -march=native -I/opt/intel/compilers_and_librarie
s_2019.5.281/linux/tbb/include -O0
LD flags (DEBUG): -Wl,--as-needed -shared-intel -qopenmp -rdynamic -Xlinker --enable-new-dtags -Xlinker -rpath -Xlinker /opt/intel/compilers_and_libraries_2019.5.281/linux/mpi/i
ntel64/lib/release -Xlinker -rpath -Xlinker /opt/intel/compilers_and_libraries_2019.5.281/linux/mpi/intel64/lib -lpthread
LIBRARIES (DEBUG): /opt/intel/compilers_and_libraries_2019.5.281/linux/mpi/intel64/lib/libmpicxx.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_iostreams.so;/opt/apps/inte
l19/python2_7/boost/1.69/lib/libboost_serialization.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_system.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_thread.so;-lpthr
ead;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_regex.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_chrono.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_date_t
ime.so;/opt/apps/intel19/python2_7/boost/1.69/lib/libboost_atomic.so;/opt/apps/intel19/metis/5.1.0/lib/libmetis.so;/opt/apps/intel19/gsl/2.5/lib/libgsl.so;/opt/apps/intel19/gsl/2.5/lib/libgslcblas.so;/home1/apps/intel19/impi19_0/p4est/2.2/lib/libp4est.so;/home1/apps/intel19/impi19_0/p4est/2.2/lib/libsc.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64_lin/libmklcore.so;/home1/apps/intel19/impi19_0/slepc/3.11/clx/lib/libslepc.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libpetsc.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libHYPRE.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libcmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libdmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libzmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libmumps_common.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libpord.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libscalapack.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libumfpack.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libklu.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libcholmod.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libbtf.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libccolamd.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libcolamd.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libcamd.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libamd.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsuitesparseconfig.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsuperlu.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsuperlu_dist.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libEl.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libElSuiteSparse.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libpmrrr.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libspai.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsundials_cvode.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsundials_nvecserial.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libsundials_nvecparallel.a;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64/libmkl_intel_lp64.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64/libmkl_sequential.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64/libmkl_core.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mkl/lib/intel64/libmkl_def.so;/opt/apps/intel19/impi19_0/phdf5/1.10.4/x86_64/lib/libhdf5hl_fortran.so;/opt/apps/intel19/impi19_0/phdf5/1.10.4/x86_64/lib/libhdf5_fortran.so;/opt/apps/intel19/impi19_0/phdf5/1.10.4/x86_64/lib/libhdf5_hl.so;/opt/apps/intel19/impi19_0/phdf5/1.10.4/x86_64/lib/libhdf5.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libchaco.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libzoltan.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libparmetis.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libmetis.so;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libptesmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libptscotchparmetis.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libptscotch.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libptscotcherr.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libesmumps.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libscotch.a;/home1/apps/intel19/impi19_0/petsc/3.11/clx/lib/libscotcherr.a;/opt/intel/compilers_and_libraries_2019.5.281/linux/mpi/intel64/lib/libmpifort.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/mpi/intel64/lib/release/libmpi.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libifport.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libifcoremt_pic.a;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libimf.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libsvml.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libipgo.a;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libirc.so;/opt/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin/libirc_s.a;rt;m;pthread;/usr/lib64/libz.so;dl;

> but I would suspect that the problem results from this different spelling. Now, I looked into the deal.II sources and I can't find any occurrence where we would test with this spelling. What is your setting for CXXFLAGS, LDFLAGS, etc?

cmake -VV \
-DCMAKE_INSTALL_PREFIX=%{INSTALL_DIR} \
\
-DDEAL_II_WITH_CXX11=ON \
-DDEAL_II_WITH_CXX17=OFF \
-DDEAL_II_CXX_FLAGS_DEBUG="${BASIC_FLAGS} -O0" \
-DDEAL_II_CXX_FLAGS_RELEASE="${BASIC_FLAGS} -O2" \
\
-DDEAL_II_COMPONENT_MESH_CONVERTER=ON \
\
-DDEAL_II_WITH_MPI=ON \
${MPI_SPECIFICATION} \
${LAPACK_SPECIFICATION} \
\
-DBOOST_DIR=${TACC_BOOST_DIR} \
-DDEAL_II_WITH_GSL=ON \
-DGSL_INCLUDE_DIR=${TACC_GSL_INC:-NO_GSL_INC} \
-DGSL_LIBRARY_DIR=${TACC_GSL_LIB:-NO_GSL_LIB} \
-DGSL_LIBRARY=${TACC_GSL_LIB:-NO_GSL_LIB}/libgsl.so\;${TACC_GSL_LIB:-NO_GSL_LIB}/lib\gslcblas.so \
-DHDF5_DIR=${TACC_HDF5_DIR} \
-DDEAL_II_WITH_METIS=${CMAKE_USE_METIS} \
-DMETIS_DIR=${TACC_METIS_DIR} \
\
` if [ ${TACC_FAMILY_COMPILER} = "intel" ] ; then echo " \
-DMUMPS_DIR=${TACC_MUMPS_DIR} \
" ; fi ` \
-DDEAL_II_WITH_PETSC=${CMAKE_USE_PETSC} \
-DPETSC_DIR=${PETSC_DIR} -DPETSC_ARCH=${PETSC_ARCH} \
-DDEAL_II_WITH_SLEPC=${CMAKE_USE_PETSC} \
-DSLEPC_DIR=${TACC_SLEPC_DIR} \
-DDEAL_II_WITH_P4EST=ON \
-DP4EST_DIR=${P4ESTDIR} \
-DDEAL_II_WITH_TRILINOS=${CMAKE_USE_TRILINOS} \
-DTRILINOS_DIR=${TACC_TRILINOS_DIR} \
${DEALDIR}/dealii-${DEALVERSION} \
\
%{_topdir}/BUILD/dealii-%{version} \
2>&1 | tee ${LOGDIR}/dealii_cmake.log

Where

export BASIC_FLAGS="-g -march=native"

export BASIC_FLAGS="${BASIC_FLAGS} -I${TBBROOT}/include"


(Doesn’t cmake write this stuff to the log files?)

V.

[Wolfgang Bangerth]

Victor,

>> In your log file, the error comes from using -lpthreads (not the 's' at the end).
>
> And by “not” you mean “note”?

Yes -- what a disfiguring one-character mistake :-(

>> You don't say what the exact error message is,
>
> Is the last error in the CMakeError.log the relevant one?
>
> Configuration error: Cannot compile a test program with the final set of

> [...]

I would like to help, but I really don't know where the flag comes from. The
text you quote here does not contain the string "pthreads" and it doesn't seem
to come out of the deal.II configuration machinery. [1] It also doesn't appear
in the CMakeOutput.log or CMakeError.log files other than in the place with
the error. What does
set | grep pthreads
say for you?

@All: Who else has ideas? Where do we import link flags from?

Best
W.


[1] I only checked the current deal.II dev sources. You might want to try
grep -r pthreads cmake

[Victor Eijkhout]

>
> I would like to help, but I really don't know where the flag comes from. The text you quote here does not contain the string "pthreads" and it doesn't seem to come out of the deal.II configuration machinery.

Hm?

Cmake outputs this:

-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found

So your cmake configuration must be looking for pthread*s* and then misremembering the conclusion.

> [1] It also doesn't appear in the CMakeOutput.log or CMakeError.log files

Truly weird.

I’m attaching the full screen output, including everything that’s irrelevant to you.

Victor.

[Wolfgang Bangerth]

On 4/22/20 1:40 PM, Victor Eijkhout wrote:
> Cmake outputs this:
>
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
>
> So your cmake configuration must be looking for pthread*s* and then misremembering the conclusion.

Maybe. But maybe also not. We never actually check for pthread_create in our
own configuration. We do call this piece of code in
cmake/configure/configure_1_threads.cmake:

MACRO(SETUP_THREADING)
#
# Unfortunately the FindThreads macro needs a working C compiler
#
IF(CMAKE_C_COMPILER_WORKS)
#
# Clear the test flags because FindThreads.cmake will use a C compiler:
#
CLEAR_CMAKE_REQUIRED()

SWITCH_LIBRARY_PREFERENCE()
FIND_PACKAGE(Threads) <<<<<<<<<<<<<<<<<<
SWITCH_LIBRARY_PREFERENCE()

FIND_PACKAGE(Threads) calls a cmake-builtin module that on my system lives in
/usr/share/cmake/Modules/FindThreads.cmake. It contains this piece of code:

_check_threads_lib(pthreads pthread_create CMAKE_HAVE_PTHREADS_CREATE)
_check_threads_lib(pthread pthread_create CMAKE_HAVE_PTHREAD_CREATE)

It must be somewhere in this module that -lpthreads is added to the link line,
though I have no idea why that would be given that the check fails (as shown
above).

What's your version of cmake?

@tamiko: Any ideas?

Best
W.

[Victor Eijkhout]

On , 2020Apr22, at 14:54, Wolfgang Bangerth <bang...@colostate.edu> wrote:

FIND_PACKAGE(Threads) calls a cmake-builtin module that on my system lives in /usr/share/cmake/Modules/FindThreads.cmake. It contains this piece of code:

if(CMAKE_HAVE_PTHREAD_H)

  #

  # We have pthread.h

  # Let's check for the library now.

  #

  set(CMAKE_HAVE_THREADS_LIBRARY)

  if(NOT THREADS_HAVE_PTHREAD_ARG)

    # Check if pthread functions are in normal C library.

    # We list some pthread functions in PTHREAD_C_CXX_TEST_SOURCE test code.

    # If the pthread functions already exist in C library, we could just use

    # them instead of linking to the additional pthread library.

    if(CMAKE_C_COMPILER_LOADED)

      CHECK_C_SOURCE_COMPILES("${PTHREAD_C_CXX_TEST_SOURCE}" CMAKE_HAVE_LIBC_PTHREAD)

    elseif(CMAKE_CXX_COMPILER_LOADED)

      CHECK_CXX_SOURCE_COMPILES("${PTHREAD_C_CXX_TEST_SOURCE}" CMAKE_HAVE_LIBC_PTHREAD)

    endif()

    if(CMAKE_HAVE_LIBC_PTHREAD)

      set(CMAKE_THREAD_LIBS_INIT "")

      set(CMAKE_HAVE_THREADS_LIBRARY 1)

      set(Threads_FOUND TRUE)

    else()

      # Check for -pthread first if enabled. This is the recommended

      # way, but not backwards compatible as one must also pass -pthread

      # as compiler flag then.

      if (THREADS_PREFER_PTHREAD_FLAG)

         _check_pthreads_flag()

      endif ()

      if(CMAKE_SYSTEM MATCHES "GHS-MULTI")

        _check_threads_lib(posix pthread_create CMAKE_HAVE_PTHREADS_CREATE)

      endif()

      _check_threads_lib(pthreads pthread_create CMAKE_HAVE_PTHREADS_CREATE)

      _check_threads_lib(pthread  pthread_create CMAKE_HAVE_PTHREAD_CREATE)

      if(CMAKE_SYSTEM_NAME MATCHES "SunOS")

          # On sun also check for -lthread

          _check_threads_lib(thread thr_create CMAKE_HAVE_THR_CREATE)

      endif()

    endif()

  endif()

  _check_pthreads_flag()

endif()

What's your version of cmake?

3.16

V.

[Matthias Maier]

Hi Victor,

Would you mind testing something for me quickly?

We have a bit of code floating around in

./cmake/configure/configure_1_threads.cmake

that might create an issue (depending on icc and cmake version I guess).
Would you mind modifying the file as in the attached diff output? Simply
copy the patch file into the source directory of deal.II and run

$ patch -p1 < remove_pthread_workarounds.patch

If that doesn't help, then my next request would be to see the full
terminal output of the cmake invocation.

Also, it seems that cmake barfs at the final sanity check where we check
whether we can compile a simply hello world program with our final
compile configuration. You can disable this check temporarily by
applying remove_sanity_checks.patch (that removes the corresponding
check from cmake./setup_finalize.cmake). cmake should then run through
without a problem creating a file 'detailed.log'. I would like to see
this one. (You can try to compile the library from here - but either the
final link of the library or linking any program against the library
will likely fail).

Best,
Matthias

[Victor Eijkhout]

On , 2020Apr22, at 16:46, Matthias Maier <tam...@43-1.org> wrote:

patch -p1 < remove_pthread_workarounds.patch

%% screen output

patching file cmake/configure/configure_1_threads.cmake

Hunk #1 FAILED at 38.

Hunk #2 succeeded at 64 (offset -10 lines).

1 out of 2 hunks FAILED -- saving rejects to file cmake/configure/configure_1_threads.cmake.rej

%% cat ../BUILD/dealii-9.1.1/cmake/configure/*rej

--- cmake/configure/configure_1_threads.cmake

+++ cmake/configure/configure_1_threads.cmake

@@ -38,15 +38,7 @@

     RESET_CMAKE_REQUIRED()

-    #

-    # The FindThreads macro returned a linker option instead of the actual

-    # library name in earlier versions. We still require the linker option,

-    # so we fix the corresponding variable.

-    #  - See: https://gitlab.kitware.com/cmake/cmake/issues/19747

-    #

-    IF(CMAKE_THREAD_LIBS_INIT AND NOT "${CMAKE_THREAD_LIBS_INIT}" MATCHES "^-l")

-      STRING(PREPEND CMAKE_THREAD_LIBS_INIT "-l")

-    ENDIF()

+    MESSAGE(STATUS "CMAKE_THREAD_LIBS_INIT: ${CMAKE_THREAD_LIBS_INIT}")

   ELSE()

[Matthias Maier]

On Fri, Apr 24, 2020, at 09:00 CDT, Victor Eijkhout <eijk...@tacc.utexas.edu> wrote:

> On , 2020Apr22, at 16:46, Matthias Maier <tam...@43-1.org<mailto:tam...@43-1.org>> wrote:
>
> patch -p1 < remove_pthread_workarounds.patch
>
> %% screen output
>
> patching file cmake/configure/configure_1_threads.cmake
> Hunk #1 FAILED at 38.
> Hunk #2 succeeded at 64 (offset -10 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file cmake/configure/configure_1_threads.cmake.rej

Ah, this is 9.1.1! Mea Culpa.

You don't need the failing hunk - the snippet of cmake configuration in
question was added after the 9.1.1 release. Nevertheless, I have
attached a new patch for 9.1.1. (the second patch works
without modification)

[Victor Eijkhout]

On , 2020Apr24, at 09:47, Matthias Maier <tam...@43-1.org> wrote:

 I have
attached a new patch for 9.1.1

I think that did it. I’m now compiling.

Victor.

[Matthias Maier]

On Fri, Apr 24, 2020, at 11:44 CDT, Victor Eijkhout <eijk...@tacc.utexas.edu> wrote:

>> On , 2020Apr24, at 09:47, Matthias Maier <tam...@43-1.org<mailto:tam...@43-1.org>> wrote:
>>
>> I have attached a new patch for 9.1.1
>
> I think that did it. I’m now compiling.

Fingers crossed!

Would you mind sending me the `detailed.log` file?

That way I can verify my suspicion that our renaming of "-lpthread" to
"-pthread" is indeed the problem. :-)

Best,
Matthias

[Marc Fehling]

Hi Victor!

This has been fixed upstream with pull request #9117. This issue only occurs with CMake version >= 3.16. Just compile from the master branch and you're good!

Best,
Marc

[Victor Eijkhout]

On , 2020Apr24, at 18:03, Marc Fehling <m.fe...@fz-juelich.de> wrote:

 Just compile from the master branch and you're good!

I’m allergic to the word “just”.

Considering how laborious our installation process is, I try to install only versions that have official numbers on them. Considering that this is a cmake-interaction, and not any change in functionality, I’ll provide this to the users as 9.1.1.

Is there a 9.1+eps coming up?

Next project: getting dealii to build with trillions, which I think I have a user request for.

Victor.

[David Wells]

Hi Victor,

> Is there a 9.1+eps coming up?

No, but we are planning on releasing 9.2.0 in May (tentatively
scheduled for May 15) - if you can wait then that might be the best
choice.

Thanks,
David

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/389E243A-38E0-48D7-A454-E43FD87858DC%40tacc.utexas.edu.

[Wolfgang Bangerth]

On 4/28/20 9:17 AM, David Wells wrote:
>> Is there a 9.1+eps coming up?
> No, but we are planning on releasing 9.2.0 in May (tentatively
> scheduled for May 15) - if you can wait then that might be the best
> choice.

That said: TACC is an important customer to us. Since you already verified
that that patch works for you, would it help if we just moved that one patch
to the 9.1 release branch and you work with that?

I think we're loath to make this into a release of its own given the effort
that goes into testing and packaging it all. But if a 9.1.1 + one patch would
work for you by giving it a git commit number you can pull, then I'm sure we
can achieve this.

Best
Wolfgang

[Victor Eijkhout]

On , 2020Apr28, at 10:21, Wolfgang Bangerth <bang...@colostate.edu> wrote:

Since you already verified that that patch works for you, would it help if we just moved that one patch to the 9.1 release branch and you work with that?

No need. I’m simply pretending that this is part of 9.1. It is being installed in today’s maintenance.

Is there a mailing list solely for announcements? I’m not sure that I’m on such a thing. If it exists, please add me.

Victor.

[Wolfgang Bangerth]

> No need. I’m simply pretending that this is part of 9.1. It is being installed
> in today’s maintenance.

Great! Also thanks for reporting this issue and your patience going around
with us to figure out that the new cmake is the issue...

> Is there a mailing list solely for announcements? I’m not sure that I’m on
> such a thing. If it exists, please add me.

We don't have one. We announce on a variety of mailing lists like NA-Digest.
But we've been reasonably regular at releasing around the month of May in
recent years if you want to pencil things into your calendar :-) (The releases
end up on the deal.II github page at
https://github.com/dealii/dealii/releases
I wonder whether there's a way to get notifications out of that page...)

Best
W.

[Bruno Turcksin]

On Tuesday, April 28, 2020 at 3:33:06 PM UTC-4, Wolfgang Bangerth wrote:

We don't have one. We announce on a variety of mailing lists like NA-Digest.
But we've been reasonably regular at releasing around the month of May in
recent years if you want to pencil things into your calendar :-) (The releases
end up on the deal.II github page at
   https://github.com/dealii/dealii/releases
I wonder whether there's a way to get notifications out of that page...)

You can go to Watch and then select Releases Only. You will get a notification when the release is tagged.

Best,

Bruno