bug#37946: pingus build fails: ‘function’ in namespace ‘std’ does not name a template type
Pierre Neidhardt writes: > pingus fails to build, maybe since the last core update: > > --8<---cut here---start->8--- > g++ -o build/src/pingus/screens/demo_session.o -c -O2 -s -std=c++0x > -isystem/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/include/libpng16 > -DVERSION="\"0.7.6\"" -DHAVE_OPENGL=1 -DHAVE_LINUXEVDEV=1 -D_GNU_SOURCE=1 > -D_REENTRANT -DHAVE_ICONV_CONST -DICONV_CONST= -Ibuild/src -Isrc > -I/gnu/store/3zh2m96050jbd4c7g2qc4mg2jq02zgd8-sdl-1.2.15/include/SDL > -I/gnu/store/p04y598xbcpi11xw3vx77h6klnmrmm17-sdl-image-1.2.12/include/SDL > -I/gnu/store/98q06cqxskclzgs0wislfnjg1n3gsdbl-sdl-mixer-1.2.12/include/SDL > -Ibuild -I. -Ibuild/src -Isrc -Ibuild/external/tinygettext > -Iexternal/tinygettext src/pingus/screens/demo_session.cpp > src/pingus/screens/demo_session.cpp:40:8: error: ‘function’ in namespace > ‘std’ does not name a template type >std::function callback; > ^~~~ > --8<---cut here---end--->8--- Fixed in 2ed626bf0d28df44328c1946cd69eb79a853c6e0, thanks! signature.asc Description: PGP signature
bug#37999: clang fails to pickup/supply startfiles to ld
Hi all,
Our clang toolchain seems to be quite broken at this time. In particular, it
fails to call `ld` in the right way such that the startfiles are picked up:
--8<---cut here---start->8---
$ guix environment --pure --container --ad-hoc clang@6 binutils -- clang++ -v
-Xlinker --verbose
...
"/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld"
--eh-frame-hdr
-m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2
-o a.out
crt1.o
crti.o
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtbegin.o
-L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0
-L/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..
-L/gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib
--verbose
-L/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/crtend.o
crtn.o
...
attempt to open crt1.o failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crt1.o:
No such file or directory
attempt to open crti.o failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find crti.o:
No such file or directory
...
attempt to open
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.so
failed
attempt to open
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/libm.a
failed
attempt to open
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.so
failed
attempt to open
/gnu/store/64xzk1kwk30n7arqgmxs2qy7wzcnc8i3-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../../libm.a
failed
attempt to open
/gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.so
failed
attempt to open
/gnu/store/zki2b9r9lkdxnb23sqc8xs99xs9s5x03-clang-6.0.1/bin/../lib/libm.a failed
attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.so
failed
attempt to open /gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/lib/libm.a
failed
attempt to open
/gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.so
failed
attempt to open
/gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib64/libm.a
failed
attempt to open /no-ld-lib-path/libm.so failed
attempt to open /no-ld-lib-path/libm.a failed
attempt to open
/gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.so
failed
attempt to open
/gnu/store/mx2bgrpxkbdjsmhlxp9a30hbzcilk4cn-binutils-2.32/x86_64-unknown-linux-gnu/lib/libm.a
failed
/gnu/store/8aj9slzwi5vnmi5iszc5jh3hrvndj29c-profile/bin/ld: cannot find -lm
...
--8<---cut here---end--->8---
I believe this is because we have crt1.o, crti.o, and limb.so in the output of
our glibc package, which clang seems unaware of.
I don't know exactly how to fix this, but I did some digging in the clang
codebase (cfe-6.0.1 to be exact), and found that the crt1.o, crti.o arguments
are added in lib/Driver/ToolChains/Gnu.cpp.
These arguments are constructed using something like
Args.MakeArgString(ToolChain.GetFilePath("crti.o")), which really calls
Driver::GetFilePath in lib/Driver/Driver.cpp under the hood. Meaning that we
just need to make Driver::GetFilePath aware of our glibc path and return the
correct full path to crt1.o and crti.o.
If anyone can help out here it would be much appreciated.
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
bug#37996: guile-ssh non-deterministic test failure
FYI, guile-ssh-0.11.3 failed one of its tests the first time I tried to build it today on my X200. The second attempt succeeded. Mark --8<---cut here---start->8--- Guile-SSH 0.11.3: tests/test-suite.log # TOTAL: 11 # PASS: 10 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: dist == ;;; note: source file ../modules/srfi/srfi-64.scm ;;; newer than compiled /gnu/store/dav5zdvdsrx0vjw0f9fyhkqyknl6kd55-guile-2.2.6/lib/guile/2.2/ccache/srfi/srfi-64.go Starting test dist (Writing full log to "dist.log") FAIL with-ssh # of expected passes 18 # of unexpected failures 1 Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. job-node" Test end: result-kind: pass actual-value: #t Test begin: test-name: "hand-out-job, invalid type" Test end: result-kind: pass actual-value: #t Test begin: test-name: "assign-eval" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, unspecified" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, error" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, compilation error" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, unbound variable error" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, unknown # object error" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, elisp" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-get-result, multiple values" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-skip-to-prompt, valid input" Test end: result-kind: pass actual-value: #t Test begin: test-name: "rrepl-skip-to-prompt, invalid input" Test end: result-kind: pass actual-value: #t Test begin: test-name: "node-guile-version, valid response" Test end: result-kind: pass actual-value: #t Test begin: test-name: "with-ssh" Test end: result-kind: fail actual-value: #f Group end: dist # of expected passes 18 # of unexpected failures 1 FAIL dist.scm (exit status: 1) command "make" "check" failed with status 2 note: keeping build directory `/tmp/guix-build-guile-ssh-0.11.3.drv-0' builder for `/gnu/store/bpnh3sfk7knh13cbmhvylzfa6l98k95z-guile-ssh-0.11.3.drv' failed with exit code 1 build of /gnu/store/bpnh3sfk7knh13cbmhvylzfa6l98k95z-guile-ssh-0.11.3.drv failed --8<---cut here---end--->8---
bug#37989: python2-numpy v0.17.3 fails to build
Josh Holland writes: > Hi, > > It seems that the update of python-numpy to 1.17.3 in > 8e5fbd5dda93e137ff527cabe25989b28ab9e1c0 has broken the build of the > corresponding Python 2 package, both on my local machine and on the CI > server: http://ci.guix.gnu.org/build/1893145/details. Fixed in adb396eae3524d9b82294aaf5cc87a615515b04d, thanks! signature.asc Description: PGP signature
bug#37989: python2-numpy v0.17.3 fails to build
Hi Josh, Lots of packages including libreoffice transitively depend on python2-numpy, so this needs some sort of resolution — perhaps simply pinning python2-numpy to a previous version? That would be my preferred solution - pin python2-numpy to the last NumPy version that supports Python 2, which is most likely 1.16. However, Python 2 will not be maintained after the end of 2019, and I'm not sure if there is an overall Guix-wide migration plan for python2-* packages. Not that I know, but no matter how this will be handled, Guix is the perfect platform for people still depending on Python 2 because they can always install packages from an earlier release. Which is a good reason to end Python 2 support in Guix by an as up to date package set as possible. Cheers. Konrad.
bug#37989: python2-numpy v0.17.3 fails to build
Hi,
It seems that the update of python-numpy to 1.17.3 in
8e5fbd5dda93e137ff527cabe25989b28ab9e1c0 has broken the build of the
corresponding Python 2 package, both on my local machine and on the CI
server: http://ci.guix.gnu.org/build/1893145/details.
The log in Cuirass is incomplete, but the error in my build is the
following:
starting phase `build'
running "python setup.py" with command "build" and parameters ()
Traceback (most recent call last):
File "", line 1, in
File "setup.py", line 31, in
raise RuntimeError("Python version >= 3.5 required.")
RuntimeError: Python version >= 3.5 required.
command "python" "-c" "import setuptools,
tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
open)(__file__);code=f.read().replace('\\r\\n',
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "build" failed with
status 1
Indeed, despite the assertion on
https://numpy.org/doc/1.17/user/building.html that Python 2.7 or 3.4 are
sufficient, the setup.py script explicitly checks that Python is at
least 3.5; see the upstream commit badf2901:
https://github.com/numpy/numpy/commit/badf2901ea040aa89dbb3c19e53c6b1b692cb489
Lots of packages including libreoffice transitively depend on
python2-numpy, so this needs some sort of resolution — perhaps simply
pinning python2-numpy to a previous version? However, Python 2 will not
be maintained after the end of 2019, and I'm not sure if there is an
overall Guix-wide migration plan for python2-* packages.
--
Josh Holland
bug#37940: endless "try upgrading both" cycles
Hello Ludo, Ludovic Courtès writes: [...] > Now, it doesn’t sound right that ‘util-linux’ is propagated from glib > and from poppler…? Glib propagates 'util-linux' since it was updated to 2.58.1 (and poppler propagates glib). This isn't the first time it's caused trouble [0]. Marius has proposed a patch to fix it, which is intended for 'core-updates' (It hasn't been pushed yet AFAIK). Regards, Diego [0]: http://issues.guix.gnu.org/issue/37732
