Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 893938 - dev-lisp/gcl-2.6.14: fail build on riscv64, No such file or directory
Summary: dev-lisp/gcl-2.6.14: fail build on riscv64, No such file or directory
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: riscv Linux
: Normal normal (vote)
Assignee: Common Lisp Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 893500
  Show dependency tree
 
Reported: 2023-02-11 09:15 UTC by Yixun Lan
Modified: 2023-12-06 16:44 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
full build log (build.log.xz,13.86 KB, application/x-xz)
2023-02-11 09:17 UTC, Yixun Lan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yixun Lan archtester gentoo-dev 2023-02-11 09:15:26 UTC
fail to build with
 USE="X ansi readline" emerge dev-lisp/gcl
 USE="-X -ansi -readline" emerge dev-lisp/gcl

if [ "./default.el" != "" ] ; then \
if test -f "/var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el" ; then \
cat /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el | sed -e '/BEGIN gcl/,/END gcl/d' > /var/tmp/portage/dev-lisp/gcl-2.6.14/image/usr/share/emacs/site-lisp/gcl//temp_emacs_default ; \
mv /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el.prev ; \
  rm -f  /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.elc ; \
          cat add-default.el >> /var/tmp/portage/dev-lisp/gcl-2.6.14/image/usr/share/emacs/site-lisp/gcl//temp_emacs_default ; cp  /var/tmp/portage/dev-lisp/gcl-2.6.14/image/usr/share/emacs/site-lisp/gcl//temp_emacs_default /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el ; \
  rm -f /var/tmp/portage/dev-lisp/gcl-2.6.14/image/usr/share/emacs/site-lisp/gcl//temp_emacs_default ; else \
cp  add-default.el /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el ; fi ; \
chmod a+r /var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el ; fi
cp: cannot create regular file '/var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el': No such file or directory
chmod: cannot access '/var/tmp/portage/dev-lisp/gcl-2.6.14/image./default.el': No such file or directory
make[2]: *** [makefile:8: install] Error 1
make[2]: Leaving directory '/var/tmp/portage/dev-lisp/gcl-2.6.14/work/gcl-2.6.14/elisp'
make[1]: *** [makefile:200: install1] Error 2
make[1]: Leaving directory '/var/tmp/portage/dev-lisp/gcl-2.6.14/work/gcl-2.6.14'
make: *** [makefile:185: install] Error 2
 * ERROR: dev-lisp/gcl-2.6.14::gentoo failed (install phase):
 *   emake failed


Reproducible: Always
Comment 1 Yixun Lan archtester gentoo-dev 2023-02-11 09:17:25 UTC
Created attachment 850378 [details]
full build log
Comment 2 James Cloos 2023-02-11 20:03:52 UTC
incidently, it built fine here with: ansi readline -X
Comment 3 Jakov Smolić archtester gentoo-dev 2023-03-04 19:25:55 UTC
Interestingly, both combinations were built without issues here on qemu, I'll give it a try on unmatched board.
Comment 4 matoro archtester 2023-12-06 04:23:15 UTC
I don't get this error, but I do get a different one.

Loading binary of GCL_PCL_PKG...
;; Loading #p"/var/tmp/portage/dev-lisp/gcl-2.6.15_pre3/work/gcl-Version_2_6_15pre3/gcl/unixport/../pcl/gcl_pcl_pkg.o"
Unknown reloc type 57

Error: ERROR "The assertion !emsg(\"Unknown reloc type %lu\\n\", tp) on line 186 of sfaslelf.c in function relocate failed: Success"
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by LOAD.
ERROR "The assertion !emsg(\"Unknown reloc type %lu\\n\", tp) on line 186 of sfaslelf.c in function relocate failed: Success"
 
Broken at LOAD.  Type :H for Help.
    1  Return to top level. 
>>make[1]: *** [makefile:35: gcl_pcl_boot.c] Error 255
make[1]: Leaving directory '/var/tmp/portage/dev-lisp/gcl-2.6.15_pre3/work/gcl-Version_2_6_15pre3/gcl/pcl'
make: *** [makefile:90: unixport/saved_pcl_gcl] Error 2
Comment 5 matoro archtester 2023-12-06 16:44:03 UTC
Should we consider then adding -fno-asynchronous-unwind-tables, or is that the wrong approach?