I noticed this running mixed mpi/openmp on a system that required an executable without dynamics libraries. Don't know if the Fortran IO is supposed to be thread safe (i.e. serialized thread safe), but this seems to work without -static. It also appears to work with 4.3.1 but not 4.4 (trunk)
> cat test.f90
write(6,*) "Hello world"
!$OMP END CRITICAL
!$OMP END PARALLEL
> gfortran -static -fopenmp test.f90
> gdb ./a.out
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1".
Starting program: /data/vondele/omptest/a.out
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0 0x0000000000000000 in ?? ()
#1 0x000000000040642f in get_external_unit (n=6, do_create=1)
#2 0x0000000000404c01 in data_transfer_init (dtp=0x7fff047208c0, read_flag=0)
#3 0x00000000004003d6 in MAIN__.omp_fn.0 ()
#4 0x000000000040032c in MAIN__ ()
#5 0x000000000040042c in main (argc=1, argv=0x7fff04720fa8)
This has been repeated many times. Don't use -static for threaded programs, it is really bad idea, and if you really have to, you need to link the whole libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive), otherwise if it works, it is by pure luck.
This certainly isn't a regression.
(In reply to comment #2)
> This has been repeated many times. Don't use -static for threaded programs, it
> is really bad idea, and if you really have to, you need to link the whole
> libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive),
> otherwise if it works, it is by pure luck.
> This certainly isn't a regression.
Thanks for your reply, this was unknown to me, and I think for many occassional omp users. Do you think this could be documented near the -fopenmp flag (I can write something if you wish). Or could one have gcc warn if both -fopenmp and -static are present ?
It is glibc specific, on the other hand it isn't particularly -fopenmp related.
I guess easiest will be if glibc stops shipping libpthread.a.
(In reply to comment #4)
> It is glibc specific, on the other hand it isn't particularly -fopenmp related.
> I guess easiest will be if glibc stops shipping libpthread.a.
but if -fopenmp automatically adds -lpthread maybe it should do it in the 'proper' way if -static is also on the command line (eventually bailing out if libpthread.a can not be found)?
Note, e.g. a warning is produced for similar issues already, e.g. I see:
/home/u1/vondele/gcc_trunk/build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/libgfortran.a(getlog.o): In function `_gfortran_getlog':
/home/u1/vondele/gcc_trunk/gcc/libgfortran/intrinsics/getlog.c:82: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
let me reopen the bug, removing the regression marker, and as an enhancement. I think that a warning, or adding -lpthread in the 'proper' way if -static will save many other users from loosing time on this one.
Not a gcc bug so closing as invalid. That warning comes from glibc anyways.
(In reply to comment #6)
> Not a gcc bug so closing as invalid.
The gcc 'bug' is that -fopenmp -static should link to pthreads as
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or error out if that is not possible.
The current way of just adding -lpthread and hoping it is correct (even in the presence of -static) is leading to wrong code.
This is not a gcc bug, glibc either should not ship libpthread.a at all or
mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive libpthreadx.a; rm libpthreadx.a
I'll try the latter in Fedora soon.
In any case, users really shouldn't use -static except for a few system recovery tools, see