BBC threaded bleadperl v5.35.3-115-g3683a9ee5a breaks GOCCY/Compiler-Lexer-0.23.tar.gz

[andk]

Description

Threaded perls stopped compiling the CPAN distro GOCCY/Compiler-Lexer-0.23.tar.gz since the commit 3683a9e,

Steps to Reproduce

(in the cpan shell): test GOCCY/Compiler-Lexer-0.23.tar.gz

The compiler error diagnostics

In file included from /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/perl.h:28,
                 from lib/Compiler/Lexer.xs:7:
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/config.h:1051:27: error: ‘_Thread_local’ does not name a type; did you mean ‘thread_local’?
 1051 | #define PERL_THREAD_LOCAL _Thread_local /**/
      |                           ^~~~~~~~~~~~~
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/thread.h:385:8: note: in expansion of macro ‘PERL_THREAD_LOCAL’
  385 | extern PERL_THREAD_LOCAL void *PL_current_context;
      |        ^~~~~~~~~~~~~~~~~
In file included from /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/perl.h:5694,
                 from lib/Compiler/Lexer.xs:7:
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/inline.h: In function ‘char* Perl_mortal_getenv(const char*)’:
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/thread.h:387:35: error: ‘PL_current_context’ was not declared in this scope
  387 | #  define PERL_GET_CONTEXT        PL_current_context
      |                                   ^~~~~~~~~~~~~~~~~~
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/thread.h:387:35: note: in definition of macro ‘PERL_GET_CONTEXT’
  387 | #  define PERL_GET_CONTEXT        PL_current_context
      |                                   ^~~~~~~~~~~~~~~~~~
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/perl.h:159:32: note: in expansion of macro ‘PERL_GET_THX’
  159 | #  define dTHX          pTHX = PERL_GET_THX
      |                                ^~~~~~~~~~~~
/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi/CORE/inline.h:3250:5: note: in expansion of macro ‘dTHX’
 3250 |     dTHX;
      |     ^~~~
error building lib/Compiler/Lexer.o from 'lib/Compiler/Lexer.c' at /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/ExtUtils/CBuilder/Base.pm line 185.

Expected behavior

up to commit 65f7068 the compilation succeeded.

Perl configuration

Summary of my perl5 (revision 5 version 35 subversion 4) configuration:
  Commit id: 3683a9ee5ad61f8cb5eac30e61b4936bd0445bdb
  Platform:
    osname=linux
    osvers=5.14.0-3-amd64
    archname=x86_64-linux-thread-multi
    uname='linux k93msid 5.14.0-3-amd64 #1 smp debian 5.14.12-1 (2021-10-14) x86_64 gnulinux '
    config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c -Dmyhostname=k93msid -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Dlibswanted=cl pthread socket inet nsl gdbm dbm malloc dl ld sun m crypt sec util c cposix posix ucb BSD gdbm_compat -Duseithreads -Uuselongdouble -DEBUGGING=-g'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2 -g'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='11.2.0'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib
    libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.32.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.32'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_TIMES
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_DEVEL
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
    USE_REENTRANT_API
    USE_THREAD_SAFE_LOCALE
  Built under linux
  Compiled at Dec 31 2021 17:04:04
  @INC:
    /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/site_perl/5.35.4/x86_64-linux-thread-multi
    /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/site_perl/5.35.4
    /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4/x86_64-linux-thread-multi
    /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.35.3-115-g3683a9ee5a/1e0c/lib/5.35.4

[jkeenan]

This compilation failure appears to be some combination of OS-specific and C-compiler-specific.

Evidence from CPANtesters

On FreeBSD on perls older than 5.20, this distro is getting a lot of FAILs. But from 5.20 onwards, it PASSes overwhelmingly.

On OpenBSD, this distro is PASSing on recent threaded builds.

On Linux, on threaded builds from 5.35.4 and later, this module is graded UNKNOWN -- which means that it failed during 'make', as reported by Andreas.

On NetBSD, on threaded builds from 5.35.4 and later, this module is graded UNKNOWN. These tests appear to be being run with gcc-5.5.0.

My own testing

FreeBSD-12

$ uname -mrs
FreeBSD 12.3-RELEASE amd64

# perl-5.35.6, compile with clang (default compiler)

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Uversiononly -Dprefix=/home/jkeenan/testing/v5.35.6 -Dman1dir=none -Dman3dir=none -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing';

$ cc --version
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
Target: x86_64-unknown-freebsd12.3
Thread model: posix
InstalledDir: /usr/bin

$ ./bin/perl -Ilib -MCompiler::Lexer -E 'say q|hello world|;'
hello world

# Perl 5 blead (Dec 31 2021)

$ ./bin/perl -Ilib -v | head -2 | tail -1
This is perl 5, version 35, subversion 8 (v5.35.8 (v5.35.7-24-g0ccfd062e2)) built for amd64-freebsd-thread-multi

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Uversiononly -Dprefix=/home/jkeenan/testing/blead -Dman1dir=none -Dman3dir=none -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing';

$ ./bin/perl -Ilib -MCompiler::Lexer -E 'say q|hello world|;'
hello world

Let's stay on FreeBSD but try a different C-compiler.

$ export COMPILE_WITH_GCC="-des -Dusedevel -Duseithreads -Dcc=gcc"
$ install_custom_freebsd_branch_for_testing 0ccfd062e2 "$COMPILE_WITH_GCC"

$ ./bin/perl -Ilib -v | head -n 2 | tail -1
This is perl 5, version 35, subversion 8 (v5.35.8 (v5.35.7-24-g0ccfd062e2)) built for amd64-freebsd-thread-multi

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Uversiononly -Dprefix=/home/jkeenan/testing/0ccfd062e2 -Dman1dir=none -Dman3dir=none -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing -des -Dusedevel -Duseithreads -Dcc=gcc';

$ ./bin/perl -Ilib -MCompiler::Lexer -E 'say q|hello world|;'
hello world

So Compiler::Lexer builds on recent threaded perls on FreeBSD using either clang or gcc as C-compiler.

Linux

$ uname -mrs
Linux 5.10.13-x86_64-linode141 x86_64

$ ./bin/perl -Ilib -v | head -2 | tail -1
This is perl 5, version 35, subversion 6 (v5.35.6 (v5.35.5-26-g4a1b9dd)) built for x86_64-linux-thread-multi

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Dusethreads -Uversiononly -Dprefix=/home/jkeenan/testing/threaded_blead -Dman1dir=none -Dman3dir=none';

# Try to install via cpanm
...
Configuring Compiler-Lexer-0.23 ... OK
Building and testing Compiler-Lexer-0.23 ... FAIL
! Installing Compiler::Lexer failed. See /home/jkeenan/.cpanm/work/1640992049.7227/build.log for details. Retry with --force to force install it.

Let's try to build on Linux using clang as the C-compiler.

$ ./bin/perl -Ilib -v | head -2 | tail -1
This is perl 5, version 35, subversion 8 (v5.35.8 (v5.35.7-24-g0ccfd06)) built for x86_64-linux-thread-multi

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Duseithreads -Dcc=clang -Dprefix=/home/jkeenan/testing/blead -Uversiononly -Dman1dir=none -Dman3dir=none';

$ ./bin/perl -Ilib -V:cc_version
cc='clang';

$ ./bin/cpanm Compiler::Lexer
# builds and tests successfully

$ ./bin/perl -Ilib -MCompiler::Lexer -E 'say q|hello world|;'
hello world

However, on a more recent Linux, using a more recent version of clang, Compiler::Lexer failed to compile on a threaded build of perl built at blead.

$ uname -mrs
Linux 5.4.0-91-generic x86_64

$ ./bin/perl -Ilib -v | head -2 | tail -1
This is perl 5, version 35, subversion 8 (v5.35.8 (v5.35.7-24-g0ccfd062e2)) built for x86_64-linux-thread-multi

$ ./bin/perl -Ilib -V:config_args
config_args='-des -Dusedevel -Duseithreads -Dcc=clang -Dprefix=/home/jkeenan/testing/blead -Uversiononly -Dman1dir=none -Dman3dir=none';

$ ./bin/perl -Ilib -V:gccversion
gccversion='Clang 10.0.0 ';

$ ./bin/cpanm Compiler::Lexer
...
Building and testing Compiler-Lexer-0.23 ... FAIL
! Installing Compiler::Lexer failed.

This data suggests that the BBC failure occurs (i) on some OSes and not others; and (ii) on those platforms where it does occur, the failure may be C-compiler specific.

[jkeenan]

@nwc10, @tonycoz, could you take a look at this ticket? Thanks.

[tonycoz]

The problem is that C thread local variables (which the commit added) use _Thread_local as the storage class, while C++ uses thread_local. (reference)

Ideally we'd separately probe for the C++ thread local storage class, but Configure doesn't have any real infrastructure to test C++ (unless -Dcc is a C++ compiler), so I don't see a simple, robust fix for this.

We could hack on config_h.SH to detect C++ and always use thread_local for PERL_THREAD_LOCAL but that's ugly and leave users with a perl that we can't be sure can build C++ XS modules such as Compiler-Lexer.

[nwc10]

Thanks for the analysis

The problem is that C thread local variables (which the commit added) use _Thread_local as the storage class, while C++ uses thread_local. (reference)

Yay. Really, yay.

It's not quite the George Bernard Shaw quote about two countries divided by a common language but it's close. Needless difference, just causing friction...

Ideally we'd separately probe for the C++ thread local storage class, but Configure doesn't have any real infrastructure to test C++ (unless -Dcc is a C++ compiler), so I don't see a simple, robust fix for this.

We could hack on config_h.SH to detect C++ and always use thread_local for PERL_THREAD_LOCAL but that's ugly and leave users with a perl that we can't be sure can build C++ XS modules such as Compiler-Lexer.

Agree with all of this.

I wonder if the approach in smoke-me/nicholas/pthreads-not-_Thread_local-for-C++ is the least worst option - for C++ disable the use of thread local storage and fall back to pthreads.

This change (ec238e5) is small because I wrote the new PERL_SET_CONTEXT implementation defensively - it sets both the new variable extern PERL_THREAD_LOCAL void *PL_current_context; and calls the old pthread_setspecific(...)

[tonycoz]

Works for me.

As I said in my notes on the commit, your comments (and commit message) indicating that's it's a "some platforms" issue are incorrect, it's really a standards issue.

[jkeenan]

Thanks for the analysis

The problem is that C thread local variables (which the commit added) use _Thread_local as the storage class, while C++ uses thread_local. (reference)

Yay. Really, yay.

It's not quite the George Bernard Shaw quote about two countries divided by a common language but it's close. Needless difference, just causing friction...

Ideally we'd separately probe for the C++ thread local storage class, but Configure doesn't have any real infrastructure to test C++ (unless -Dcc is a C++ compiler), so I don't see a simple, robust fix for this.
We could hack on config_h.SH to detect C++ and always use thread_local for PERL_THREAD_LOCAL but that's ugly and leave users with a perl that we can't be sure can build C++ XS modules such as Compiler-Lexer.

Agree with all of this.

I wonder if the approach in smoke-me/nicholas/pthreads-not-_Thread_local-for-C++ is the least worst option - for C++ disable the use of thread local storage and fall back to pthreads.

This change (ec238e5) is small because I wrote the new PERL_SET_CONTEXT implementation defensively - it sets both the new variable extern PERL_THREAD_LOCAL void *PL_current_context; and calls the old pthread_setspecific(...)

Is this problem something where we may have to ask the CPAN author to revise code?

I ask because we're nearing the point in the annual development cycle where we have to know what we're going to do for all BBCs.

[dur-randir]

Is this problem something where we may have to ask the CPAN author to revise code?

No. The same commit breaks in the same way next::XS (and 10+ from down there). I'd say, it makes perl core universally incompatible with c++ compilers. That's not half the CPAN, but it's also not a single module from a single author broken situation.

[nwc10]

Is this problem something where we may have to ask the CPAN author to revise code?

No. #19335 fixes it.

[nwc10]

Should now be fixed in blead.