Sheila Peacock
Dear SAC users,
I have just had my computer upgraded to Fedora-33 from 29, and my locally compiled copy of SAC-102 has lost the ability to do command-line editing (e.g. pressing the up-arrow does not get me back to the previous command).
I had compiled SAC-102 on Fedora-29 and was running it on Fedora-33, so I did "make distclean" and recompiled on Fedora-33, but with no better luck.
The version of "libedit" that comes with Fedora-29 is v. 0.0.56, and with Fedora-33 is 0.0.63, and there is a copy of "libedit" v. 0.0.55 in a tarfile bundled with the SAC source code. My compilation was trying to use the system "libedit".
I tried adding the switch "--enable-editline" to the options for "configure", which should cause SAC to use the bundled "libedit" rather than the system one, but this caused a compilation error at the "make" stage, with libedit/lib/libedit.a complaining "(terminal.o); undefined reference to symbol 'tputs'".
I fund that if I entered the directory sac-102.0/libedit and typed "make" in there, the bundled v. 0.0.55 "libedit" was "made" and libraries put into a "lib" subdirectory. When I put this subdirectory into my LD_LIBRARY_PATH before /usr/lib (where the system copy of libedit v. 0.0.63 lives), the command-line editing function was restored, i.e. it works when I issue the command:
setenv LD_LIBRARY_PATH /sharedprograms/sac/v102/sac-102.0/libedit/lib:$LD_LIBRARY_PATH
(the bash equivalent would be "export LD_LIBRARY_PATH=...") before starting SAC-102.
I found that the precompiled version of SAC-102 did not have this problem, i.e. the command-line editing works on my Fedora-33 computer. I presume that it was compiled with "--enable-editline" to avoid depending on an unknown system version of "libedit". SAC-101.6a does not have this problem because it does not even try to use the system copy of "libedit" but only the copy bundled with it, which is from 2009 and doesn't have a version number.
Several other SAC users here are about to have their computers upgraded to Fedora-33 and I have been asked for a general solution to this problem. We have to use a locally compiled copy of SAC that incorporates locally written code that everyone here needs.
My feeling is that the best fix might be for me to substitute a copy of libedit v.0.0.63 for v.0.0.55 in the SAC source-code distribution, set the "--enable-editline" switch and persuade SAC to link with it. Has anyone tried this?
Please ask for more details if this doesn't make sense.
Regards,
Sheila Peacock,
Blacknest.
I have just had my computer upgraded to Fedora-33 from 29, and my locally compiled copy of SAC-102 has lost the ability to do command-line editing (e.g. pressing the up-arrow does not get me back to the previous command).
I had compiled SAC-102 on Fedora-29 and was running it on Fedora-33, so I did "make distclean" and recompiled on Fedora-33, but with no better luck.
The version of "libedit" that comes with Fedora-29 is v. 0.0.56, and with Fedora-33 is 0.0.63, and there is a copy of "libedit" v. 0.0.55 in a tarfile bundled with the SAC source code. My compilation was trying to use the system "libedit".
I tried adding the switch "--enable-editline" to the options for "configure", which should cause SAC to use the bundled "libedit" rather than the system one, but this caused a compilation error at the "make" stage, with libedit/lib/libedit.a complaining "(terminal.o); undefined reference to symbol 'tputs'".
I fund that if I entered the directory sac-102.0/libedit and typed "make" in there, the bundled v. 0.0.55 "libedit" was "made" and libraries put into a "lib" subdirectory. When I put this subdirectory into my LD_LIBRARY_PATH before /usr/lib (where the system copy of libedit v. 0.0.63 lives), the command-line editing function was restored, i.e. it works when I issue the command:
setenv LD_LIBRARY_PATH /sharedprograms/sac/v102/sac-102.0/libedit/lib:$LD_LIBRARY_PATH
(the bash equivalent would be "export LD_LIBRARY_PATH=...") before starting SAC-102.
I found that the precompiled version of SAC-102 did not have this problem, i.e. the command-line editing works on my Fedora-33 computer. I presume that it was compiled with "--enable-editline" to avoid depending on an unknown system version of "libedit". SAC-101.6a does not have this problem because it does not even try to use the system copy of "libedit" but only the copy bundled with it, which is from 2009 and doesn't have a version number.
Several other SAC users here are about to have their computers upgraded to Fedora-33 and I have been asked for a general solution to this problem. We have to use a locally compiled copy of SAC that incorporates locally written code that everyone here needs.
My feeling is that the best fix might be for me to substitute a copy of libedit v.0.0.63 for v.0.0.55 in the SAC source-code distribution, set the "--enable-editline" switch and persuade SAC to link with it. Has anyone tried this?
Please ask for more details if this doesn't make sense.
Regards,
Sheila Peacock,
Blacknest.
