Hide Forgot
Hello, My name is Rick Cone, long-time UNIX/Linux (Red Hat) user. We have a very legacy application called "Mlink", that we have a very large installed software base of already written and fully operational communication scripts. We are currently running on RHEL 5 (32 bit), and we're in the migration process to RHEL 7 (64 bit). The package "compat-libtermcap" is present in RHEL 5, and RHEL 6, but was removed from RHEL 7. I would like to have it again included in RHEL 7. It is needed for "Mlink": [root@t7serv1 mlink]# ldd mlink linux-gate.so.1 => (0xf76e2000) libtermcap.so.2 => /lib/libtermcap.so.2 (0x00953000) libc.so.6 => /lib/libc.so.6 (0xf750e000) /lib/ld-linux.so.2 (0xf76e3000) Note the "/lib/libtermcap.so.2". This is essentially "compat-libtermcap". THe other items here are provided by 32 bit libraries (yum) loaded into 64 bit RHEL 7. Note, I can (manually) bring over the "/lib/libtermcap.so.2" from the RHEL 5 (32 bit) systems we currently use, and Mlink works. I would just feel much better if it was officially put back into RHEL 7 (64 bit) by Red Hat (in yum). Thank you! Rick
(In reply to Rick Cone from comment #4) > Note, I can (manually) bring over the "/lib/libtermcap.so.2" from the RHEL 5 > (32 bit) systems we currently use, and Mlink works. I would just feel much > better if it was officially put back into RHEL 7 (64 bit) by Red Hat (in > yum). Could you please try it with a libtermcap.so.2 -> libtinfo.so.5 symlink? The ABI is not 100% compatible, which is the reason the symlink is not included in the ncurses package, but if you could test that the application works as expected without real libtermcap, it might be an acceptable solution.
Hello, The "libtermcap.so.2 -> libtinfo.so.5 symlink" did work. Here are the details: [root@t7serv1 lib]# cd /lib [root@t7serv1 lib]# ls -l libtinfo.so.5 lrwxrwxrwx. 1 root root 15 Nov 7 12:51 libtinfo.so.5 -> libtinfo.so.5.9 [root@t7serv1 lib]# ls -l libtinfo.so.5.9 -rwxr-xr-x. 1 root root 136288 Jan 26 2014 libtinfo.so.5.9 [root@t7serv1 lib]# ln -s /lib/libtinfo.so.5.9 /lib/libtermcap.so.2 [root@t7serv1 lib]# ls -l libtermcap.so.2 lrwxrwxrwx. 1 root root 20 Jan 4 11:13 libtermcap.so.2 -> /lib/libtinfo.so.5.9 [root@t7serv1 mlink]# ldd mlink linux-gate.so.1 => (0xf77a4000) libtermcap.so.2 => /lib/libtermcap.so.2 (0xf776c000) libc.so.6 => /lib/libc.so.6 (0xf75ae000) /lib/ld-linux.so.2 (0xf77a5000) I actually did the symlink link to "libtinfo.so.5.9", as it was the actual file here. I ran the "mlink" application a bit, and all appears good. It ran just as good as when using the "/lib/libtermcap.so.2" from the RHEL 5 (32 bit) systems we currently use. I'm going to assume this is a viable alternative, or perhaps "an equally viable alternative", I guess. So, I certainly appreciate the input on this other approach. Using this symlink to something already formally existing in RHEL 7 64 bit does seem generally better than my "home grown" approach of using the "/lib/libtermcap.so.2" from the RHEL 5 (32 bit) systems we currently use. I guess my goal here is, as I stated before (I apologize if I'm sounding picky), was to "feel much better if it was officially put back into RHEL 7 (64 bit) by Red Hat (in yum)". I can certainly keep this new symlink approach (i.e. "ln -s /lib/libtinfo.so.5.9 /lib/libtermcap.so.2"), really no problem there. Was that your intention, meaning, just create this symlink to "get the job done" (no disrespect). I just worry if that original file disappears in a future yum update, etc. (in which I would doubt), this would then fail. I also think I noticed that yum seemed to mildly complain about a seemingly foreign lib file present in my old "home grown" approach (I don't recall the exact warning message here, but it alarmed me a bit), and it might again here. Does that sound correct? I'm striving for some form of order, or official, approach here. I don't want a yum update sensing something odd, and affecting it's update behavior in the future. I guess I could remove the symlink temporarily while doing a yum update. Your kind thoughts and advice is certainly appreciated. Thanks! Rick
(In reply to Rick Cone from comment #8) > Was that your intention, meaning, just create this symlink > to "get the job done" (no disrespect). I just worry if that original file > disappears in a future yum update, etc. (in which I would doubt), this would > then fail. I also think I noticed that yum seemed to mildly complain about > a seemingly foreign lib file present in my old "home grown" approach (I > don't recall the exact warning message here, but it alarmed me a bit), and > it might again here. Does that sound correct? I'm striving for some form > of order, or official, approach here. I don't want a yum update sensing > something odd, and affecting it's update behavior in the future. I guess I > could remove the symlink temporarily while doing a yum update. Your kind > thoughts and advice is certainly appreciated. I guess a cleaner approach would be to put that symlink in some special directory that's normally not searched by the dynamic linker and set LD_LIBRARY_PATH only for the mlink program. Maybe create a wrapper script that would do that. Would that work better for you?
Well, I'm not sure. I'm not an expert on these sort of things, and mlink is not my application (it's from Computer Associates ... if that makes any difference). Since it's not my application, I'm sure I really want to do anything to "push the envelope" of it's functionality, being it is old, legacy, 32-bit, etc. Perhaps if I understood your cleaner approach suggestion better, and in more detail, I might think about it I guess. Just curious, why would "yum" mildly issue a warning for seemingly "rogue" shared objects in the /lib directly? Is it because they're not formally registered, or something like that? I had thought about removing the symlink during yum updates (done during down times), so it did not interfere with yum. Sorry to be so wordy, just trying to explain and understand. Thanks for your further thoughts here. Rick
What message does yum print? I suspect it might be from ldconfig, which is executed in postinstall scripts of many packages. Adding the symlink to a different directory would prevent accidentally running another application which depends on libtermcap, but is not fully compatible with the libtinfo emulation.
Sorry, I can't recall the yum message exactly. Using the symlink you suggested recenty to libtinfo.so.5.9, I did a yum update. I did not see any errors or warnings. I have attached the output of the yum update for your viewing pleasure (or not!). Tell me in detail what you're proposing in detail when you say "Adding the symlink to a different directory would prevent accidentally running another application which depends on libtermcap" Thank you so much! Rick
Created attachment 1239146 [details] Yum update output
(In reply to Rick Cone from comment #12) > Tell me in detail what you're proposing in detail when you say "Adding the > symlink to a different directory would prevent accidentally running another > application which depends on libtermcap" The idea was to create the symlink in a directory that would be used only by the mlink application and which you have verified that it works correctly. If another application that needs libtermcap was installed on the system, it wouldn't start until you created a similar symlink for it and verified it works as expected. This might prevent accidents due to possible incompatibility between the libraries. I'm not sure if it's worth the trouble.
Understood... I have something somewhat similar setup now with options. I have 3 available. In a new special (separate) directory called "/etc/libtermcap", I can create a symlink to "/lib/libtermcap.so.2" from: /lib/libtinfo.so.5.9 Suggested on Bugzilla. /etc/libtermcap/libtinfo.so.5.9 Copied to this special directory /etc/libtermcap/libtermcap.so.2.0.8 Copied from RHEL 5 32 bit. My current preferred method is the first ("/lib/libtinfo.so.5.9"), as it was suggested here. Since yum didn't seem to complain, at least on this last yum update, I like it even better. Anyway, mlink seems to run with any of the 3. We do not really anything with the terminal emulation with mlink anyway. Thoughts? Thanks, Rick
I think the first option is a good one. I'm not sure I understand the other two options correctly. My suggestion was to put the symlink pointing to /lib/libtinfo.so.5.9 to a different directory, so it would be ignored by dynamic linker unless LD_LIBRARY_PATH was set to include /etc/libtermcap.
The other two are just using base files safely in the confines of the special "/etc/libtermcap" folder, to be potentially be used for the symlink to "/lib/libtermcap.so.2". They are essentially plan B and plan C, or backup plans as a "just in case" type of thing. I'm really sorry, I'm not all that experienced in these things. I still don't really understand your suggestion. Perhaps type it out in commands as to how it would be implemented, etc., so I understand it, and can evaluate it. Thanks, Rick
I was thinking something like this: # mkdir -p /usr/local/lib/mlink # ln -s /lib/libtinfo.so.5 /usr/local/lib/mlink/libtermcap.so.2 To execute mlink: $ export LD_LIBRARY_PATH=/usr/local/lib/mlink $ mlink
Yeah, that worked. Understood. Thanks! I'm not sure I want to do the "export LD_LIBRARY_PATH=/usr/local/lib/mlink" every time this executed, or set it up everywhere in profiles as well. So, I tired to make it work in "/etc/ld.so.conf" and "/etc/ld.so.conf.d". I made a file "/etc/ld.so.conf.d/mlink.conf": [root@t7serv1 ld.so.conf.d]# ls -l total 28 -rw-r--r--. 1 root root 19 Oct 20 2014 dyninst-x86_64.conf -r--r--r--. 1 root root 63 Oct 20 03:00 kernel-3.10.0-327.36.3.el7.x86_64.conf -r--r--r--. 1 root root 63 Nov 16 11:22 kernel-3.10.0-514.2.2.el7.x86_64.conf -r--r--r--. 1 root root 63 Oct 19 09:29 kernel-3.10.0-514.el7.x86_64.conf -rw-r--r--. 1 root root 17 May 26 2016 libiscsi-x86_64.conf -rw-r--r--. 1 root root 17 Sep 21 06:18 mariadb-x86_64.conf -rw-r--r--. 1 root root 21 Jan 13 10:03 mlink.conf With the contents of: /usr/local/lib/mlink I then did "ldconfig" to update the ld cache. It actually changed the "/usr/local/lib/mlink" contents to: [root@t7serv1 mlink]# ls -l total 0 lrwxrwxrwx. 1 root root 18 Jan 13 10:03 libtermcap.so.2 -> /lib/libtinfo.so.5 lrwxrwxrwx. 1 root root 15 Jan 13 10:03 libtinfo.so.5 -> libtermcap.so.2 Which, I thought was a little weird (perhaps a lot weird). The initial (more) "ldconfig -v" output is: [root@t7serv1 mlink]# ldconfig -v | more ldconfig: Can't stat /libx32: No such file or directory ldconfig: Path `/usr/lib' given more than once ldconfig: Path `/usr/lib64' given more than once ldconfig: Can't stat /usr/libx32: No such file or directory /usr/lib64/dyninst: libsymtabAPI.so.8.2 -> libsymtabAPI.so.8.2.0 libsymLite.so.8.2 -> libsymLite.so.8.2.0 libstackwalk.so.8.2 -> libstackwalk.so.8.2.0 libpcontrol.so.8.2 -> libpcontrol.so.8.2.0 libpatchAPI.so.8.2 -> libpatchAPI.so.8.2.0 libparseAPI.so.8.2 -> libparseAPI.so.8.2.0 libinstructionAPI.so.8.2 -> libinstructionAPI.so.8.2.0 libdyninstAPI_RT.so.8.2 -> libdyninstAPI_RT.so.8.2.0 libdyninstAPI.so.8.2 -> libdyninstAPI.so.8.2.0 libdynElf.so.8.2 -> libdynElf.so.8.2.0 libdynDwarf.so.8.2 -> libdynDwarf.so.8.2.0 libdynC_API.so.8.2 -> libdynC_API.so.8.2.0 libcommon.so.8.2 -> libcommon.so.8.2.0 /usr/lib64/iscsi: libiscsi.so.2 -> libiscsi.so.2.0.10900 /usr/lib64/mysql: libmysqlclient.so.18 -> libmysqlclient.so.18.0.0 /usr/local/lib/mlink: libtinfo.so.5 -> libtermcap.so.2 /lib: ... etc. ... Anyway, it doesn't seem to find that lib: [root@t7serv1 mlink]# ldd mlink linux-gate.so.1 => (0xf7782000) libtermcap.so.2 => not found libc.so.6 => /lib/libc.so.6 (0xf75ab000) /lib/ld-linux.so.2 (0xf7783000) Thoughts? Thank you! Rick
(In reply to Rick Cone from comment #19) > [root@t7serv1 mlink]# ls -l > total 0 > lrwxrwxrwx. 1 root root 18 Jan 13 10:03 libtermcap.so.2 -> /lib/libtinfo.so.5 > lrwxrwxrwx. 1 root root 15 Jan 13 10:03 libtinfo.so.5 -> libtermcap.so.2 > > Which, I thought was a little weird (perhaps a lot weird). This is because libtermcap.so.2 has SONAME "libtinfo.so.5" and ldconfig creates "misssing" symlinks. There is an option in ldconfig which disables that, but the extra symlink shouldn't cause problems. > Anyway, it doesn't seem to find that lib: > > [root@t7serv1 mlink]# ldd mlink > linux-gate.so.1 => (0xf7782000) > libtermcap.so.2 => not found > libc.so.6 => /lib/libc.so.6 (0xf75ab000) > /lib/ld-linux.so.2 (0xf7783000) I think that's because "libtermcap.so.2" is not actually included in ld.so.cache (the SONAME is already included) and it needs LD_LIBRARY_PATH to be set in order to find it in a non-standard directory.
Understood. Thanks for the information. Well, for now, I think mlink is running okay. I have 3 symlink options available to make "/lib/libermcap.so.2" appear for mlink's benefit, and any of the 3 appear to be generally okay. I don't think I'll need any more help on this. I truly appreciate your help. and anyone else who has contributed. Thanks, Rick
The solution with the symlink seems to be working, so I'm closing this bug as a request for adding compat-libtermcap to RHEL7.
*** Bug 1569201 has been marked as a duplicate of this bug. ***