Bug 218752 - net/asterisk11 - Problem with the asterisk console when linked to the latest version of libedit
Summary: net/asterisk11 - Problem with the asterisk console when linked to the latest ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Guido Falsi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-19 13:05 UTC by Yani Karydis
Modified: 2017-04-19 17:39 UTC (History)
0 users

See Also:
madpilot: maintainer-feedback+


Attachments
Patch to use the internal libedit library (476 bytes, patch)
2017-04-19 13:05 UTC, Yani Karydis
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yani Karydis 2017-04-19 13:05:40 UTC
Created attachment 181896 [details]
Patch to use the internal libedit library

Hello,

I'm getting some strange console behaviour when asterisk is linked to the latest version of the libedit library (3.1.20170329_2,1). Typing any command in the console (asterisk -r) displays unicode codes instead of the actual input (e.g. typing "c" echoes "\U+AD263"). The same problem was reported in Digium's forum about a year ago:

https://community.asterisk.org/t/cli-gibberish-prompt-and-input-appear-to-be-some-sort-of-unicode-characters/67382

The fix is to pass "--with-libedit=inetrnal" to the configure script to use the internal libedit library. I'm attaching a Makefile patch.
Comment 1 Guido Falsi freebsd_committer freebsd_triage 2017-04-19 13:36:35 UTC
Hi,

this problem was already reported to me, but I've been unable to reproduce it. I tested both in a VM using the official packages(from the latest repo obviously) and on my servers, using packages built by myself using poudriere.

I can retry with a fresh VM building all relevant ports in the jail, but I suspect the problem lays elsewhere.

My suspect is the real cause is some ABI misalignment. Maybe the libedit guys broke ABI by mistake.

In theory it should be enough to rebuild just asterisk after updating libedit, but to be on the safe side, could you try rebuilding ncurses, libedit and all ports depending on libedit?
Comment 2 Guido Falsi freebsd_committer freebsd_triage 2017-04-19 13:39:16 UTC
Oops, I misread your submission. My previous tests where all with asterisk13. I will check with asterisk 11. Meybe there is a difference. Anyway please try the test I described in comment 1.
Comment 3 Yani Karydis 2017-04-19 13:50:53 UTC
Hello,

I have already rebuilt all ports that asterisk11 depends on a new system. My original platform was amd64, I've already replicated the issue on fresh installs on amd64 (VM) and arm (Raspberry PI). The culprit is the latest version of the shared libedit library. On a poudriere build, the problem isn't apparent as the jails do not include the shared libedit library as it's not specified as a runtime library in the port definition (the internal library is used in this case). On a ports build however, the configure script finds the shared libedit library when available (such in my case as I use the mysql client) and uses it, which causes the problem. I've downgraded the shared libedit library and this fixes the problem, however I need to have the latest libedit library installed as it's used by other ports.

Please let me know if you would like me to try something else.
Comment 4 Guido Falsi freebsd_committer freebsd_triage 2017-04-19 14:16:15 UTC
(In reply to yani from comment #3)
> Hello,
> 
> I have already rebuilt all ports that asterisk11 depends on a new system. My
> original platform was amd64, I've already replicated the issue on fresh
> installs on amd64 (VM) and arm (Raspberry PI). The culprit is the latest
> version of the shared libedit library. On a poudriere build, the problem
> isn't apparent as the jails do not include the shared libedit library as
> it's not specified as a runtime library in the port definition (the internal
> library is used in this case). On a ports build however, the configure
> script finds the shared libedit library when available (such in my case as I
> use the mysql client) and uses it, which causes the problem. I've downgraded

Good catch.

I thought USES=libedit was listed. It is in the asterisk13 port, and that one seems to work fine with latest libedit. Most probably something was changed in asterisk between the two versions.

> the shared libedit library and this fixes the problem, however I need to
> have the latest libedit library installed as it's used by other ports.
> 
> Please let me know if you would like me to try something else.

No more tests required on your part! I now understand the problem at hand. And yes using the internal libedit library looks like the only viable solution for asterisk11, which is not getting support, apart from security fixes from upstream.

Thanks for your investigation, I'll commit the change after some testing.
Comment 5 Guido Falsi freebsd_committer freebsd_triage 2017-04-19 17:39:05 UTC
Committed. Thanks!
Comment 6 commit-hook freebsd_committer freebsd_triage 2017-04-19 17:39:09 UTC
A commit references this bug:

Author: madpilot
Date: Wed Apr 19 17:38:17 UTC 2017
New revision: 438897
URL: https://svnweb.freebsd.org/changeset/ports/438897

Log:
  - Force asterisk11 to use bundled libedit, otherwise it could link
    with ports provided one, with which it has incompatibilities
  - While here, remove asterisk 1.8 from CONFLICTS, it is not available
    anymore as a port

  PR:		218752
  Submitted by:	yani@pi-greece.eu

Changes:
  head/net/asterisk11/Makefile