x86_64-pc-linux-gnu-g++ -o Sluift/EditlineTerminal.o -c -O2 -pipe -march=native -fno-diagnostics-color -falign-functions=32:25:16 -std=c++11 -Wextra -Wall -Wnon-virtual-dtor -Wundef -Wold-style-cast -Wno-long-long -Woverloaded-virtual -Wfloat-equal -Wredundant-decls -Wno-unknown-pragmas -O2 -pipe -march=native -fno-diagnostics-color -falign-functions=32:25:16 -fPIC -DNDEBUG -DSWIFT_EXPERIMENTAL_FT -DNDEBUG -DSWIFT_EXPERIMENTAL_FT -DNDEBUG -DSWIFT_EXPERIMENTAL_FT -DLUA_COMPAT_ALL -DHAVE_EDITLINE -I. -I/usr/include/lua5.1 -I. -I. Sluift/EditlineTerminal.cpp Sluift/EditlineTerminal.cpp: In constructor 'Swift::EditlineTerminal::EditlineTerminal()': Sluift/EditlineTerminal.cpp:72:36: error: invalid conversion from 'int (*)(const char*, int)' to 'char* (*)(const char*, int)' [-fpermissive] 72 | rl_completion_entry_function = getEmptyCompletions; // Fallback. Do nothing. | ^~~~~~~~~~~~~~~~~~~ | | ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1-20210217-102603 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 11.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.1.0 Python 3.8.8 Available Ruby profiles: (none found) Available Rust versions: [1] rust-bin-1.50.0 * The following VMs are available for generation-2: 1) JamVM JDK 2.0.0 [jamvm] *) AdoptOpenJDK 8.282_p08 [openjdk-bin-8] Available Java Virtual Machines: [1] jamvm [2] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Tue Mar 2 07:52:10 UTC 2021 emerge -qpvO net-im/swift [ebuild N ] net-im/swift-4.0.2-r102 USE="icu idn lua -expat -test -zeroconf" LUA_SINGLE_TARGET="lua5-1 -lua5-2 -luajit"
Created attachment 689016 [details] emerge-info.txt
Created attachment 689019 [details] emerge-history.txt
Created attachment 689022 [details] environment
Created attachment 689025 [details] etc.portage.tar.bz2
Created attachment 689028 [details] logs.tar.bz2
Created attachment 689031 [details] net-im:swift-4.0.2-r102:20210302-084812.log
Created attachment 689034 [details] temp.tar.bz2
still happens despite bug 701016 being closed
Hm :/ I am still absolutly unable to reproduce. Even with 1:1 same use flags and cflags as you did. It just compiles fine. Any ideas?
(In reply to Conrad Kostecki from comment #9) > Any ideas? It fails at this tinderbox image (again, tried it today) but emerged fine at others (different profile, USE flag, emerge history etc.) in the last few days
(In reply to Toralf Förster from comment #10) > (In reply to Conrad Kostecki from comment #9) > > > Any ideas? > It fails at this tinderbox image (again, tried it today) but emerged fine at > others (different profile, USE flag, emerge history etc.) in the last few > days Hm, was is so special about this tinderbox? What are the differences to the other, where it worked?
(In reply to Conrad Kostecki from comment #11) > (In reply to Toralf Förster from comment #10) > > (In reply to Conrad Kostecki from comment #9) > > > > > Any ideas? > > It fails at this tinderbox image (again, tried it today) but emerged fine at > > others (different profile, USE flag, emerge history etc.) in the last few > > days > > Hm, was is so special about this tinderbox? What are the differences to the > other, where it worked? I can reproduce this if dev-libs/libedit is installed on the system. From https://swift.im/git/swift/tree/Sluift/main.cpp I can see that EditlineTerminal.h is only included if HAVE_EDITLINE is defined (scons tests for editline/readline.h to set the flag). And indeed libedit's readline.h has: typedef char *rl_compentry_func_t(const char *, int); extern rl_compentry_func_t *rl_completion_entry_function; AFAIC there is no option to disable libedit. Probably it is best to remove the check completly. Otherwise add a (conditional?) dependency on dev-libs/libedit with patched definition of getEmptyCompletions.
(In reply to Conrad Kostecki from comment #11) > Hm, was is so special about this tinderbox? What are the differences to the > other, where it worked? avout this image ? It is unique wrt " arbitrary combination of ~amd64 + profile + USE flag set" [1] and for sure with the emerge history. BTW, if this issue is a rare cornercase w/o any real world occurrence then just let this bug open till another image can reproduce it (w/ different USE flags etc) ? [1] https://zwiebeltoralf.de/tinderbox.html
> I can reproduce this if dev-libs/libedit is installed on the system. Bingo! I don't have that installed, but this tinderbox here has. After emerging dev-libs/libedit, I was able to reproduce. Thank you!
(In reply to Stephan Hartmann from comment #12) > I can reproduce this if dev-libs/libedit is installed on the system. Ah, that might explain why no tinderbox image uncovered it before in the past. I had have a libedit dependency within the tinderbox images till last year. I was able to get rid of that dep in december.
(In reply to Stephan Hartmann from comment #12) > AFAIC there is no option to disable libedit. Probably it is best to remove > the check completly. Otherwise add a (conditional?) dependency on > dev-libs/libedit with patched definition of getEmptyCompletions. It also seems to fail, if I use sys-libs/readline instead. I will patch it out, since by default, it's not used anyway.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=330346ce66cae755165a2a786527b0605d521279 commit 330346ce66cae755165a2a786527b0605d521279 Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2021-03-07 16:26:14 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2021-03-07 16:27:00 +0000 net-im/swift: fix compilation with installed dev-libs/libedit Closes: https://bugs.gentoo.org/773961 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> net-im/swift/swift-4.0.2-r102.ebuild | 3 +++ 1 file changed, 3 insertions(+)
