Build problem on Linux Ubuntu 21.10

I upgraded my Ubuntu from 20.04 to 21.10 (which I don’t think is officially supported for zcash builds yet), and I encountered this build problem at the last step when linking zcashd (and most of the other executables):

$ zcutil/build.sh
(usual build output ....)
  CXXLD    zcashd
ld.lld: error: undefined symbol: pthread_yield
>>> referenced by os_yield.c
>>>               os_yield.o:(__os_yield) in archive /g/master-zcash/depends/x86_64-pc-linux-gnu/share/../lib/libdb_cxx-6.2.a
>>> did you mean: pthread_yield@GLIBC_2.2.5
>>> defined in: /lib/x86_64-linux-gnu/libc.so.6
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:3401: zcashd] Error 1

I found a workaround is to build as follows:

CONFIGURE_FLAGS='ac_cv_func_pthread_yield=no' zcutil/build.sh
5 Likes

Hi @LarryRuane ! I’ve hit the same linker error, on Arch.

The workaround doesn’t seem to work for Arch, I get the same error.

Sounds like glibc might need a downgrade on your fresh Ubuntu box to 2.2.5 as this function is no longer valid (or zcashd probably needs a patch).

https://man7.org/linux/man-pages/man3/pthread_yield.3.html

   Since glibc 2.34, this function is marked as deprecated.
1 Like

This is strange, right now, I don’t encounter this error (I’m still running Ubuntu 21.10) even if I don’t use that workaround. I don’t know what’s changed. Are you seeing the same os_yield.o linker error? When you run ./configure, do you see it checking for yield or os_yield, something like that? I remember seeing (when I posted the workaround above) something like checking for yield... yes and then when I added the above workaround, it changed to ... no. But now I don’t see it checking for yield at all. (And I don’t get the error even without using the workaround.) So I don’t know what’s going on.

1 Like

Here’s the error:

  CXXLD    zcash-gtest
ld.lld: error: undefined symbol: pthread_yield
>>> referenced by os_yield.c
>>>               os_yield.o:(__os_yield) in archive /home/detcader/src/zcashes/zcash/depends/x86_64-pc-linux-gnu/share/../lib/libdb_cxx-6.2.a
>>> did you mean: pthread_yield@GLIBC_2.2.5
>>> defined in: /usr/lib/libc.so.6
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:3411: zcashd] Error 1
make[2]: *** Waiting for unfinished jobs....
ld.lld: error: undefined symbol: pthread_yield
>>> referenced by os_yield.c
>>>               os_yield.o:(__os_yield) in archive /home/detcader/src/zcashes/zcash/depends/x86_64-pc-linux-gnu/share/../lib/libdb_cxx-6.2.a
>>> did you mean: pthread_yield@GLIBC_2.2.5
>>> defined in: /usr/lib/libc.so.6
ld.lld: error: undefined symbol: pthread_yield
>>> referenced by os_yield.c
>>>               os_yield.o:(__os_yield) in archive /home/detcader/src/zcashes/zcash/depends/x86_64-pc-linux-gnu/share/../lib/libdb_cxx-6.2.a
>>> did you mean: pthread_yield@GLIBC_2.2.5
>>> defined in: /usr/lib/libc.so.6
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:3403: zcash-gtest] Error 1
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:3297: test/test_bitcoin] Error 1
make[2]: Leaving directory '/home/detcader/src/zcashes/zcash/src'
make[1]: *** [Makefile:8055: all-recursive] Error 1
make[1]: Leaving directory '/home/detcader/src/zcashes/zcash/src'
make: *** [Makefile:634: all-recursive] Error 1

Which glibc are you building against? Can you test @pkr 's hypothesis that the deprecation of the mentioned function is the issue?

When I run configure, after running:

CONFIGURE_FLAGS='ac_cv_func_pthread_yield=no' zcutil/build.sh

I do not see the pattern yi show up. That is, I don’t think it’s showing checking for yield

Is it possible that zcutil/build.sh is not generating a new configure?

OK… I reran clean and build and expanded the grep target…

grep -r pthread_yield ./src/
./src/univalue/config.log:  $ ./configure --disable-option-checking --prefix=/usr/local ac_cv_func_pthread_yield=no --disable-shared -
-with-pic --enable-benchmark=no --with-bignum=no --enable-module-recovery --cache-file=/dev/null --srcdir=.
./src/univalue/config.log:ac_cv_func_pthread_yield=no
./src/univalue/config.status:ac_cs_config='--disable-option-checking --prefix=/usr/local ac_cv_func_pthread_yield=no --disable-shared
--with-pic --enable-benchmark=no --with-bignum=no --enable-module-recovery --cache-file=/dev/null --srcdir=.'
./src/univalue/config.status:  set X /bin/sh './configure'  '--disable-option-checking' '--prefix=/usr/local' 'ac_cv_func_pthread_yiel
d=no' '--disable-shared' '--with-pic' '--enable-benchmark=no' '--with-bignum=no' '--enable-module-recovery' '--cache-file=/dev/null' '
--srcdir=.' $ac_configure_extra_args --no-create --no-recursion
./src/secp256k1/config.log:  $ ./configure --disable-option-checking --prefix=/usr/local ac_cv_func_pthread_yield=no --disable-shared
--with-pic --enable-benchmark=no --with-bignum=no --enable-module-recovery --cache-file=/dev/null --srcdir=.
./src/secp256k1/config.log:ac_cv_func_pthread_yield=no
./src/secp256k1/config.status:ac_cs_config='--disable-option-checking --prefix=/usr/local ac_cv_func_pthread_yield=no --disable-shared
 --with-pic --enable-benchmark=no --with-bignum=no --enable-module-recovery --cache-file=/dev/null --srcdir=.'
./src/secp256k1/config.status:  set X /bin/sh './configure'  '--disable-option-checking' '--prefix=/usr/local' 'ac_cv_func_pthread_yie
ld=no' '--disable-shared' '--with-pic' '--enable-benchmark=no' '--with-bignum=no' '--enable-module-recovery' '--cache-file=/dev/null'
'--srcdir=.' $ac_configure_extra_args --no-create --no-recursion

It seems like the flag is being picked up in the config.log’s in subdirectories.

I am now going to regenerate the clean/build without the flag and check that the subdir config.logs have different pthread_yield messages.

Yes, my impression when I posted that workaround in January was that pthread_yield is deprecated, and that workaround forces the build to not use it (which isn’t a fatal error; it simply uses some equivalent mechanism). I don’t know how to tell which glibc I’m using; that string “glibc” doesn’t appear in the output of make V=1 (verbose), nor does it appear in my config.log. Keep in mind that I’m doing a default clang build, but I was, or thought I was, doing that also when I ran into the problem in January. Does the Arch build use gcc or clang? I’ve never done that build. I’m sorry I can’t be more helpful.

It mentions clang-13, so I guess I need a different flag to ignore the function?

Is there a policy for how zcashd will handle this going forward? Should I open a github issue?

Yes, please open a ticket. I was just talking with one of our build people, and he says that anything above 20.04 on Arch Linux (or probably any version of linux) isn’t officially supported yet, but they’re aware and working on it. But it would be good if you could open a ticket.

1 Like