I'm trying to port libeditline to OS4. However, whenever I build the library either on Amiga itself or with a cross-compiler, I get the message "warning: warning: newlib.library 53.25 required for tcgetattr()" repeatedly (yes, the "warning:" is doubled like that). Programs that link with libeditline.a end up crashing on launch, even though they worked with the source-compatible libreadline (which I don't want to use for licensing reasons). I'm entirely new at the porting game and still wet behind the ears with Amiga development, so I'm not entirely sure what to do about this. I don't know if my program is crashing because of newlib.library (which is at 53.30 btw) or if something else is wrong.
I figured since libeditline uses the configure toolchain that
./configure --enable-shared=no --enable-static=yes && make all (with the requisite build/host/target options when cross-compiling) would be enough, and given that it does at least generate libeditline.a it seemed reasonable at the time.
Any suggestions on what I should try?
Further investigation shows that the programs built using libreadline are not crashing, but rather that its main function is returning
NULLright off the bat causing the programs to end normally albeit without accepting any user input. That's still quite different behaviour from how the library works on other systems, but at least it's a starting point.
Those warning messages are just to inform that one or more function are requiring a newer newlib version are being used. Since newlib 53.30 was released with 4.1 Final Edition it is only a problem for you if you want your program to work with older OS versions.
The actual text contains only one "warning: " but I guess gcc prepends another one on top of that one.
BTW is this the libeditline that you are trying to port?
Okay, so there's nothing to worry about with those warnings, that wouldn't be why the library isn't working for me. And yeah, that's the one I'm trying to port.
I spiked in some test
putchar()calls at various places where I thought the code is passing through on the way to failure/exit. I think I've traced the failure to either the library's
rl_getc()function and have now decorated them as well.
I've further nailed down the issue to a
read()call in editline.c:rl_getc(void).
It appears that
read()returns 5 instead of the expected 1 (or -1 for error), leading to the EOF return which eventually percolates up to the
readline()call in the program itself getting
NULLand figuring there's no more to do. So it looks like the fix might be to change the check from
r == 1to
r > 0. However now I'm concerned that it'll only return every fifth character typed! Time for more testing.
UPDATE: Looks like it's returning every character, not every fifth. I've found my fix.
Congrats for your release of the libeditline library. It would be great if you could create a blog post here in os4coding about the features of this library and how people can use it in their own apps.
Thanks for the hard work
The work's not done yet. While I've been able to package up the working library and upload it to Aminet, I still need to figure out how to maintain my patch, especially as it seems that in porting the library I've found a problem in newlib's implementation of
read()which the developer of libeditline doesn't want to account for. When all's figured out, though, I do plan to write up about the journey.
Time to chase things down with Hyperion. I looked up the POSIX definition for
read()along with how it is implemented in base newlib (it's a stub that simply returns 0).
read()should never return a value greater than the number of bytes requested to be read, so the fact that it's returning 5 when we ask for 1 means that there's a bug in the AmigaOS newlib.
The fact that the read() function returns a number of bytes higher than was requested is clearly not correct, and suggests that there is something not right in the termios layer which was adapted from clib2.
If you can produce a simple test case that reproduces the issue it would help me in looking further into this.
I've been trying to produce a simple test case, but it seems that the problem doesn't turn up except when using libeditline. I'll have to package up my instrumented library with a test program and send that whole bundle. I'll try to get that done before the end of the weekend, hopefully today.
UPDATE: It looks like only the first call to
read()after editline writes or rewrites a line exhibits the problem. Backspace, delete (after moving back from the current end of line), tab, and enter keys all result in the error occurring on the next keypress.
Unfortunately it's no simple case, but the attached archive is my build of the library without changes save some debugging code in the
rl_getc()function inside src/editline.c, clearly called out. Running any of the programs in the examples drawer from the shell will exhibit the debug error message on the first keystroke following the display of the prompt, and whenever a character is typed following use of the tab, backspace, or delete key.
I did some testing with both my public and beta OS installations on my Sam460 and while I was able to easily reproduce the debug messages using my public installation with newlib.library 53.30 I wasn't able to get them using the beta installation with newlib.library 53.59.
Comparing the relevant source code in both library versions it seems that I made some mistakes in the termios adaption for version 53.30 causing the result value to not be set correctly (instead whatever value happened to be there in memory was returned), that I fixed later in version 53.36 while making some other code changes
Good to hear it's already fixed then! When might we get an update pushed out?