[arch-general] (no subject)
Greets! I maintain a vi clone, xvi.sf.net, which fails to build on arch linux. The issue follows: https://github.com/martinwguy/xvi/blob/master/issues/open/arch-linux-build-f... A user reports build failure on Arch Linux when the final link fails to find symbols tgoto, BC and UP. This recalls a similar issue on AIX, where one had to link with -lcurses and see also the #ifdef AIX phrases in src/tcap_src.c The AIX box that needed this doesn't have a libtermcap, while I see you do have one. Do you know which termcap that is? GNU or BSD or something else? I also see it's in local/ - does that mean it's been installed locally and is a version different from the Arch repository? (Sorry, I'm not that familiar with Arch linux to understand these things!) http://github.com/martinwguy/xvi/issues/165 Package version: local/termcap 1.3.1-4 multilib/gcc-multilib 7.1.1-4 (multilib-devel) core/binutils 2.28.0-4 (base-devel) core/make 4.2.1-2 (base-devel) core/automake 1.15.1-1 (base-devel) ([0])$>> make (cd src && make -f makefile.pos \ OPTFLAG="-O2 -DHELPFILE=\\\"/usr/share/xvi/xvi.help\\\"" \ xvi) [...] cc -DUNIX -DTERMIOS -DPOSIX -O2 -DHELPFILE=\"/usr/share/xvi/xvi.help\" -o xvi alloc.o altstack.o ascii.o buffers.o cmdline.o cmdmode.o cmdtab.o cursor.o dispmode.o edit.o ex_cmds1.o ex_cmds2.o events.o fileio.o find.o flexbuf.o map.o mark.o misccmds.o mouse.o movement.o normal.o param.o pipe.o preserve.o ptrfunc.o regexp.o screen.o search.o signal.o startup.o status.o tag.o targets.o undo.o update.o version.o vi_cmds.o vi_ops.o virtscr.o windows.o yankput.o unix.o tcapmain.o tcap_scr.o -ltermcap tcap_scr.o: In function `set_scroll_region': tcap_scr.c:(.text+0x148): undefined reference to `tgoto' tcap_scr.o: In function `cm_absolute': tcap_scr.c:(.text+0x4e8): undefined reference to `tgoto' tcap_scr.c:(.text+0x524): undefined reference to `tgoto' tcap_scr.o: In function `scroll_up.part.5': tcap_scr.c:(.text+0x8b9): undefined reference to `tgoto' tcap_scr.o: In function `tty_open': tcap_scr.c:(.text+0xe80): undefined reference to `BC' tcap_scr.c:(.text+0xea6): undefined reference to `UP' tcap_scr.o: In function `scroll_down': tcap_scr.c:(.text+0x1948): undefined reference to `tgoto' collect2: error: ld returned 1 exit status make[1]: *** [makefile.pos:65: xvi] Error 1 I don't run AL; can anyone confirm the status of this issue? Many thanks Martin Guy
On Sat, 6 Jan 2018 15:42:05 +0100, Martin Guy via arch-general wrote:
GNU or BSD or something else?
Hi, you could take a look at the PKGBUILD, see https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=termcap .
I also see it's in local/ - does that mean it's been installed locally and is a version different from the Arch repository?
"local" indeed describes a locally installed package that isn't available by official repositories. IOW it's not a different version, there is no such package provided by official Arch repositories. At the right side of https://www.archlinux.org/ there is a package search. It's the same for the Arch User Repository (AUR), see https://aur.archlinux.org/ -> https://aur.archlinux.org/packages/?O=0&K=termcap -> https://aur.archlinux.org/packages/termcap/ "local" not necessarily means it was build from AUR, perhaps it was moved from the official repositories to AUR, or somebody build her own package. I can't comment the quality of this package, AUR package could be plain crap as well as perfectly good, however, the proper mailing list for AUR is https://lists.archlinux.org/listinfo/aur-general . In this case you probably better want to add a comment to https://aur.archlinux.org/packages/termcap/ . Regards, Ralf
On Sat, Jan 06, 2018 at 04:33:25PM +0100, Ralf Mardorf wrote:
"local" not necessarily means it was build from AUR, perhaps it was moved from the official repositories to AUR, or somebody build her own package.
Things in /usr/local/bin and /usr/local/lib are NOT from AUR packages. The normal way to use AUR is to build a package, then install it with pacman -U. That means things will end up in /usr/bin and /usr/lib. Anything in /usr/local was probably installed by compiling it locally without building a package. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sat, 6 Jan 2018 21:55:18 +0000, Fons Adriaensen wrote:
On Sat, Jan 06, 2018 at 04:33:25PM +0100, Ralf Mardorf wrote:
"local" not necessarily means it was build from AUR, perhaps it was moved from the official repositories to AUR, or somebody build her own package.
Things in /usr/local/bin and /usr/local/lib are NOT from AUR packages. The normal way to use AUR is to build a package, then install it with pacman -U. That means things will end up in /usr/bin and /usr/lib.
Anything in /usr/local was probably installed by compiling it locally without building a package.
You are missing the point, since on Sat, 6 Jan 2018 15:42:05 +0100, Martin Guy via arch-general wrote:
Package version: local/termcap 1.3.1-4 multilib/gcc-multilib 7.1.1-4 (multilib-devel) core/binutils 2.28.0-4 (base-devel) core/make 4.2.1-2 (base-devel) core/automake 1.15.1-1 (base-devel)
On Sat, 6 Jan 2018 23:04:17 +0100, Ralf Mardorf wrote:
On Sat, 6 Jan 2018 21:55:18 +0000, Fons Adriaensen wrote:
On Sat, Jan 06, 2018 at 04:33:25PM +0100, Ralf Mardorf wrote:
"local" not necessarily means it was build from AUR, perhaps it was moved from the official repositories to AUR, or somebody build her own package.
Things in /usr/local/bin and /usr/local/lib are NOT from AUR packages. The normal way to use AUR is to build a package, then install it with pacman -U. That means things will end up in /usr/bin and /usr/lib.
Anything in /usr/local was probably installed by compiling it locally without building a package.
You are missing the point, since on Sat, 6 Jan 2018 15:42:05 +0100, Martin Guy via arch-general wrote:
Package version: local/termcap 1.3.1-4 multilib/gcc-multilib 7.1.1-4 (multilib-devel) core/binutils 2.28.0-4 (base-devel) core/make 4.2.1-2 (base-devel) core/automake 1.15.1-1 (base-devel)
Btw. the output of the official "pacman" as well as the unsupported "yaourt" have their advantages and pitfalls: [rocketmouse@archlinux ~]$ pacman -Qs jack2 local/jack2 1.9.10.r298.gf6f7f11b-1 The next-generation JACK with SMP support [rocketmouse@archlinux ~]$ yaourt -Qs jack2 community/jack2 1.9.10.r298.gf6f7f11b-1 The next-generation JACK with SMP support [rocketmouse@archlinux ~]$ pacman -Ss jack2 community/jack2 1.9.10-6 [installed: 1.9.10.r298.gf6f7f11b-1] The next-generation JACK with SMP support community/jack2-dbus 1.9.10-6 The next-generation JACK with SMP support (for D-BUS interaction only) multilib/lib32-jack2 1.9.10-3 The next-generation JACK with SMP support (32 bit) [rocketmouse@archlinux ~]$ yaourt -Ss jack2 community/jack2 1.9.10-6 [installed: 1.9.10.r298.gf6f7f11b-1] The next-generation JACK with SMP support community/jack2-dbus 1.9.10-6 The next-generation JACK with SMP support (for D-BUS interaction only) multilib/lib32-jack2 1.9.10-3 The next-generation JACK with SMP support (32 bit) aur/jack2-dbus-git 3274-1 (6) (0.00) The next-generation JACK with SMP support (for D-BUS interaction only) aur/jack2-git 3274-1 (6) (0.00) The next-generation JACK with SMP support aur/jack2-no-dbus-git 1.9.10.151.g22e843f-2 (2) (0.00) Classic jack2 without dbus enabled. For starting as daemon with systemd. [rocketmouse@archlinux ~]$ pacman -Qs yoshimi local/yoshimi 1.5.6-1 a fork of the ZynAddSubFX software systhesizer [rocketmouse@archlinux ~]$ pacman -Ss yoshimi [rocketmouse@archlinux ~]$ yaourt -Ss yoshimi aur/yoshimi 1.5.6-1 [installed] (70) (0.15) a fork of the ZynAddSubFX software systhesizer
On Sat, 6 Jan 2018 23:19:11 +0100, Ralf Mardorf wrote:
On Sat, 6 Jan 2018 23:04:17 +0100, Ralf Mardorf wrote:
On Sat, 6 Jan 2018 21:55:18 +0000, Fons Adriaensen wrote:
On Sat, Jan 06, 2018 at 04:33:25PM +0100, Ralf Mardorf wrote:
"local" not necessarily means it was build from AUR, perhaps it was moved from the official repositories to AUR, or somebody build her own package.
Things in /usr/local/bin and /usr/local/lib are NOT from AUR packages. The normal way to use AUR is to build a package, then install it with pacman -U. That means things will end up in /usr/bin and /usr/lib.
Anything in /usr/local was probably installed by compiling it locally without building a package.
You are missing the point, since on Sat, 6 Jan 2018 15:42:05 +0100, Martin Guy via arch-general wrote:
Package version: local/termcap 1.3.1-4 multilib/gcc-multilib 7.1.1-4 (multilib-devel) core/binutils 2.28.0-4 (base-devel) core/make 4.2.1-2 (base-devel) core/automake 1.15.1-1 (base-devel)
Btw. the output of the official "pacman" as well as the unsupported "yaourt" have their advantages and pitfalls:
[rocketmouse@archlinux ~]$ pacman -Qs jack2 local/jack2 1.9.10.r298.gf6f7f11b-1 The next-generation JACK with SMP support [rocketmouse@archlinux ~]$ yaourt -Qs jack2 community/jack2 1.9.10.r298.gf6f7f11b-1 The next-generation JACK with SMP support [rocketmouse@archlinux ~]$ pacman -Ss jack2 community/jack2 1.9.10-6 [installed: 1.9.10.r298.gf6f7f11b-1] The next-generation JACK with SMP support community/jack2-dbus 1.9.10-6 The next-generation JACK with SMP support (for D-BUS interaction only) multilib/lib32-jack2 1.9.10-3 The next-generation JACK with SMP support (32 bit) [rocketmouse@archlinux ~]$ yaourt -Ss jack2 community/jack2 1.9.10-6 [installed: 1.9.10.r298.gf6f7f11b-1] The next-generation JACK with SMP support community/jack2-dbus 1.9.10-6 The next-generation JACK with SMP support (for D-BUS interaction only) multilib/lib32-jack2 1.9.10-3 The next-generation JACK with SMP support (32 bit) aur/jack2-dbus-git 3274-1 (6) (0.00) The next-generation JACK with SMP support (for D-BUS interaction only) aur/jack2-git 3274-1 (6) (0.00) The next-generation JACK with SMP support aur/jack2-no-dbus-git 1.9.10.151.g22e843f-2 (2) (0.00) Classic jack2 without dbus enabled. For starting as daemon with systemd. [rocketmouse@archlinux ~]$ pacman -Qs yoshimi local/yoshimi 1.5.6-1 a fork of the ZynAddSubFX software systhesizer [rocketmouse@archlinux ~]$ pacman -Ss yoshimi [rocketmouse@archlinux ~]$ yaourt -Ss yoshimi aur/yoshimi 1.5.6-1 [installed] (70) (0.15) a fork of the ZynAddSubFX software systhesizer
I forgot to run [rocketmouse@archlinux ~]$ yaourt -Qs yoshimi local/yoshimi 1.5.6-1 a fork of the ZynAddSubFX software systhesize
participants (3)
-
Fons Adriaensen
-
Martin Guy
-
Ralf Mardorf