[Bug libfortran/114646] New: libgfortran doesn't work with static libpthread

[Bug libfortran/114646] New: libgfortran doesn't work with static libpthread

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

            Bug ID: 114646
           Summary: libgfortran doesn't work with static libpthread
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-3 tmp]$ cat x.f90 
      use omp_lib
      implicit none
      integer, parameter :: NT = 4
      integer :: nThreads(NT)

      print *, 'Call omp_set_dynamic'
!$    call omp_set_dynamic(.false.)
      print *, 'Call omp_set_num_threads'
!$    call omp_set_num_threads(NT)
      print *, 'Now enter the parallel region'

!$omp parallel default(none) shared(nThreads)
      nThreads(omp_get_thread_num()+1) = omp_get_num_threads()
!$omp end parallel

      print*, nThreads

      END
[hjl@gnu-cfl-3 tmp]$ gfortran -static -fopenmp x.f90 
/usr/local/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/13/libgomp.a(target.o): in
function `gomp_target_init.part.0':
(.text+0x4d6): warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking
[hjl@gnu-cfl-3 tmp]$ ./a.out 
 Call omp_set_dynamic
 Call omp_set_num_threads
 Now enter the parallel region
           4           4           4           4

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
Segmentation fault (core dumped)
[hjl@gnu-cfl-3 tmp]$

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-04-08

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
See https://sourceware.org/bugzilla/show_bug.cgi?id=5784#c10 for more info.

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup.

*** This bug has been marked as a duplicate of bug 39176 ***

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176#c2 .

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer <fw at gcc dot gnu.org> ---
Sorry, threading and -static is expected to work with glibc 2.34 and later.
There are no alternative function implementations when linking with and without
libpthread anymore. Instead we always link with the full implementation, and
some critical ones have fast paths for truly single-threaded operation.

[Bug libfortran/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
         Resolution|DUPLICATE                   |---
            Summary|libgfortran doesn't work    |libgcc's gthr.h still
                   |with static libpthread      |defines GTHREAD_USE_WEAK to
                   |                            |1 for newer glibc
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libfortran                  |libgcc

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What was done for libstdc++ was only specific to libstdc++ even though it uses
the same headers, it was not changed for the generic libgcc code which is used
in other places including but not limited to the unwinder, and libobjc. now the
question comes to do we want to bring in pthread_ functions always with the
unwinder? I don't know ...

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
r12-5108

commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 9 23:45:36 2021 +0000

    libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

    Since Glibc 2.34 all pthreads symbols are defined directly in libc not
    libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
    avoid unnecessary locking in single-threaded programs. This means there
    is no reason to avoid linking to libpthread now, and so no reason to use
    weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100748
            PR libstdc++/103133
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
            Define for glibc 2.34 and later.

fixed static C++ pthread programs.  libgfortran neeeds a similar fix.

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #8 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> What was done for libstdc++ was only specific to libstdc++ even though it
> uses the same headers, it was not changed for the generic libgcc code which
> is used in other places including but not limited to the unwinder, and
> libobjc. now the question comes to do we want to bring in pthread_ functions
> always with the unwinder? I don't know ...

For glibc, most of these functions are included in minimal static executables
anyway. At least today, the difference is not going to be large, if it exists
at all. In the future, minimal static executables may have a smaller footprint,
but even then, these functions are pretty small. The concern is probably more
in the opposite direction, that pthread_once pulls in the unwinder …

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup.

*** This bug has been marked as a duplicate of bug 87189 ***

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 57906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57906&action=edit
A patch

I am testing this.

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[bruno at clisp dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno at clisp dot org

--- Comment #11 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Andrew Pinski from comment #9)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 87189 ***

This makes no sense to me:
- I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is fixed;
therefore it ought to be marked as RESOLVED FIXED.
- Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38.
Therefore they cannot be duplicates of each other.

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |---
             Status|RESOLVED                    |NEW
     Ever confirmed|0                           |1
          Component|libgcc                      |libfortran
            Summary|libgcc's gthr.h still       |libgfortran still doesn't
                   |defines GTHREAD_USE_WEAK to |define GTHREAD_USE_WEAK to
                   |1 for newer glibc           |0 for newer glibc

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #11)
> (In reply to Andrew Pinski from comment #9)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 87189 ***
> 
> This makes no sense to me:
> - I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is
> fixed; therefore it ought to be marked as RESOLVED FIXED.
> - Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38.
> Therefore they cannot be duplicates of each other.

Yes it is all the same issue.

*** This bug has been marked as a duplicate of bug 78017 ***

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #11)
> (In reply to Andrew Pinski from comment #9)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 87189 ***
> 
> This makes no sense to me:
> - I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is
> fixed; therefore it ought to be marked as RESOLVED FIXED.
> - Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38.
> Therefore they cannot be duplicates of each other.

It is all the same issue. Just half of it was fixed in glibc, which is why PR
87189 seems to have been fixed but the gcc side was not fixed.

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|DUPLICATE                   |---

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
This issue is about how libgcc is used by libgfortran, not libgcc itself.

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #14)
> This issue is about how libgcc is used by libgfortran, not libgcc itself.

libgcc needs to be fixed too. NOT just libgfortran.

If you are going to change libgfortran, you might as well fix libgcc since
libgfortran, libobjc and even ada libraries all need the same fix so why NOT
fix it in libgcc instead. All of the libraries that use gthr* need to be fixed
not just libgfortran.

*** This bug has been marked as a duplicate of bug 87189 ***

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to H.J. Lu from comment #14)
> > This issue is about how libgcc is used by libgfortran, not libgcc itself.
> 
> libgcc needs to be fixed too. NOT just libgfortran.
> 
> If you are going to change libgfortran, you might as well fix libgcc since
> libgfortran, libobjc and even ada libraries all need the same fix so why NOT
> fix it in libgcc instead. All of the libraries that use gthr* need to be
> fixed not just libgfortran.
> 
> *** This bug has been marked as a duplicate of bug 87189 ***

So will libphobos and libvtv. So fixing it once and for all in libgcc is much
better than fixing all other libraries.

[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc

[skpgkp2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

--- Comment #17 from Sunil Pandey <skpgkp2 at gmail dot com> ---
(In reply to H.J. Lu from comment #10)
> Created attachment 57906 [details]
> A patch
> 
> I am testing this.

This patch resolved my static testing issue.