From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 05321385828D for ; Fri, 16 Sep 2022 22:51:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 05321385828D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x629.google.com with SMTP id s18so16781575plr.4 for ; Fri, 16 Sep 2022 15:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date; bh=ZAcu+xsJEalNLwvd9D0qM57brTC/3iyijnTUNiuEEC4=; b=VSmwX7cJIFqrHwSTWZz8mWY8T2ExgKFSrloEHkoeoaZLF1xB6Atqtp4zIXF7IBlJsI w/gWavP/AICrc98SzY9t9wxqfJBgpyXOUs4zjY8LWPWqH/0RiRCvk/6qs+SnrGmO9+mf G+SYcpNLbRoNfGs7A159fa4cEDtlYb461FXnJ35hSjjx9loyl5+UrPalwNPmeTmS1XXA qQA0AFQHpPh4GJlnVvYM6hyAiPEngGsm+FlPR21eO67BouXCLzyE6VLRATWrQ2rZwvfN q8HkjxhsBJR6692VX0h8yM/MIYM6E/5zjq5hdQdjNMCdNJVtgzZLifocp/0+JDJ0mkM1 qDIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date; bh=ZAcu+xsJEalNLwvd9D0qM57brTC/3iyijnTUNiuEEC4=; b=i21UioOzfSp8j+7SnNtPbTeK42WiUrRJ1awkZnq9HAbQykTOJ3ObNmDTAV8oO5qJT5 bnCZMSqszHGFr1awlx8XdzSbTzpTOipTHNkB9Yw0QUUESapoa5XGCjujGK+Eit9GusYU iquW6phUi96OfjM5FaSgklGMaf26fzqgfWyF0y+yOi5CFd3Uunnbw3q8i+x4AAJT3Kol aKvZ401Gt5Ky5t7LihXB/79zo+zBkTbsC+aukOvCpz296O8xHq2IO8IlSc0/tnoa+Nhp trpLLJdFA5ZhBuDJ9gJA9DTpZ3Hmj3XGeemDuNe6HpRXWhzq5s19O91S8rQyiohx4eHV p66A== X-Gm-Message-State: ACrzQf192KwZ/ZcKTP2KIaliEwIAflFvwyAGTkVdaPTVaoN8nne9oJhe c6mw2yiffWfrP3KjfvFDp8U2NC8y70xx3Q== X-Google-Smtp-Source: AMsMyM6WNHgdh64stkTWBlnza1BNwgDl6/dy3w0G505ILlJAHYYFrB8WkJOZgZmM/PtMkTJSmWhRyA== X-Received: by 2002:a17:902:904b:b0:172:cd04:a3d3 with SMTP id w11-20020a170902904b00b00172cd04a3d3mr1982654plz.173.1663368661553; Fri, 16 Sep 2022 15:51:01 -0700 (PDT) Received: from abensonca-precision-7540.localnet (075-140-015-040.biz.spectrum.com. [75.140.15.40]) by smtp.gmail.com with ESMTPSA id b77-20020a621b50000000b00545b91e78d3sm9269530pfb.89.2022.09.16.15.51.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Sep 2022 15:51:01 -0700 (PDT) From: Andrew Benson To: Fortran Subject: gfortran, OpenMP and static linking Date: Fri, 16 Sep 2022 15:51:00 -0700 Message-ID: <1720594.qhh6PHbjeT@abensonca-precision-7540> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I've been following the fix proposed by Bernhard in this thread: https://gcc.gnu.org/pipermail/fortran/2021-April/055907.html to allow static linking of Fortran codes compiled with -fopenmp. (I know that static linking of OpenMP codes isn't guaranteed to work, but this fix has worked well for me anyway.) This fix seems to no longer work with glibc >= 2.34 - I think because the functionality of libpthread has been integrated into libc: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html When compiling the simple test code from that thread with glibc 2.34 or newer I get a segfault: $ cat omp.f90 use omp_lib !$omp parallel write(*,*) "thread ", omp_get_thread_num() !$omp end parallel end $ gfortran -o omp -fopenmp omp.f90 -static -Wl,--whole-archive -lpthread - Wl,--no-whole-archive && OMP_NUM_THREADS=2 ./omp ./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c: 102: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking thread 0 thread 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x467b0f in ??? #1 0x0 in ??? Segmentation fault (core dumped) Tracking this down in gdb it seems that pthread_mutex_destroy() is called, but that symbol is null. >From comment #9 in this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909#c9 I figured out a workaround, which is to create a C file with this content: #include "pthread.h" #define nullptr ((void*)0) void pthread_workaround() { pthread_mutex_destroy((pthread_mutex_t *) nullptr); } which defines a function pthread_workaround() which calls pthread_mutex_destroy(), but which itself it never called. Compiling that C code, and linking with the Fortran allows the test code to run successfully. $ gcc -c -o fix.o -fopenmp fix.c $ gfortran -c -o omp.o -fopenmp omp.f90 $ gfortran -o omp -fopenmp -static omp.o fix.o ./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c: 102: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking $ OMP_NUM_THREADS=2 ./omp thread 0 thread 1 My understanding of glibc, pthreads, etc. etc. is insufficient to know if this is a good and/or safe workaround, but I figured I'd share it here in case: a) it's useful to anyone; b) it's indicative of a bug in gfortran; c) anyone has a more elegant solution! -Andrew -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://bitbucket.org/abensonca/galacticus