(no subject)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

(no subject)

arch general mailing list-2
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-failure

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
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Ralf Mardorf-4
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
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Fons Adriaensen-2
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)
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Ralf Mardorf-4
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)
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Ralf Mardorf-4
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
Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

Ralf Mardorf-4
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