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.
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?
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.
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.
(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.
Committed. Thanks!
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