SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Maybe my google skills aren't all that great. After upgrading to Slackware64 14.2 and getting all my other packages installed, I'm hardening the system. I have a license for ESET Nod32 64 bit for Linux and ran it under Slackware64 14.1 without trouble. I'm must have forgotten to write something down, because the installer is looking for glibc.i686 and ld-linux.so.2. I solved the ld-linux.so.2 by creating a symlink to /lib64/ld-linux-x86-64.so.2 in the /lib. But I'm stumped on the glibc.i686. First I thought that glibc-solibs was all that Slackware required for all libraries. But I also have:
[ installed ] - glibc-zoneinfo-2017b-noarch-1_slack14.2
[ installed ] - glibc-solibs-2.23-x86_64-1
[ installed ] - glibc-2.23-x86_64-1
[ installed ] - glibc-i18n-2.23-x86_64-1
[ installed ] - glibc-profile-2.23-x86_64-1
Is there and easy way to solve this problem? Is it simply another missing symlink? I've actually tried to add a symlink for /usr/lib/gconv/UTF-16.so from /usr/lib64/gconv/UTF-16.so but that didn't help.
Actually I'm going to message the ESET folks and ask why they are trying to find a 32bit driver with a 64bit installer? I'm guessing it has something to do with setting up protection for both libraries and multi-lib environments. But that is simply a quess. It could be an issue of RedHat and SuSE putting all libraries in /lib and /usr/lib regardless of the architecture also, so the binary is looking there. I know when I last had this operating it was with AlienBob's multilib libraryies present, but I haven't installed multilib because I'm finding only 64 bit apps to be perfectly fine for my needs.
The original ESET file is a binary executable made for RedHat/SuSE but they don't provide the rpm. This is the only piece of binary I run on my computer where a source to build a proper package isn't available. Any helpful ideas will be appreciated, since ESET suggests this packages is for RedHat and Debian packages. Cheers
Have you checked with the file command to verify the binary is in fact 64bit? I have a suspicion if it is looking for 32bit libs, that it itself is 32bit.
Hmm, well, that's definitely a 64bit binary. If it is pre-compiled, there's not much more you could likely do other than contact them and/or possibly try multilib.
Just for completeness sake (and my curiosity), can you provide the output of the following commands?
ESET customer support simply referred me to RedHat KB for how to install glibc.i686 ;(
I believe this means that ESET must be installed in a multilib environment only. Since I'm not interested in multilib environment I might have to abandon this application and try others, like Sophos or BitDefender, both with higher Windows detection rates. I'm running this because I am in a heterogenous home environment where my wife's computer is Win10 and I'm Slackware and we share files regularly and some grandkid jpg's from emails. I'm going to leave this open in case someone has a different suggestion on how to resolve a request for glibc.i686 other than installing multilib. Cheers.
Dang, that sucks they don't provide something that would work in a pure-64bit environment. The only virus scanner I'm even semi-familiar with is clamav, but that's just because my buddy installed it on his email server like a decade ago. I don't really scan any of my stuff, because I don't usually get things from Windows environments and the things I do have, tend to not go to Windows environments. About the only thing that does transfer between the two is my videos that are hosted on my Slackware media server.
Hopefully you'll have better luck with a different provider.
One minor thought, I wonder if the script just checks for glibc.i686. It might not actually require a multilib environment to run (at least the libs it links to doesn't indicate that). I wonder if you were to install it on a multilib VM and then transfer the files to your regular host, if it would work... but then it may not even be worth the hassle, especially since the company didn't seem to even care or help you resolve the issue beyond pointing you to some pointless instructions for a distro you don't even run ¯\_(ツ)_/¯
I have been an ESET Nod 32 user decades ago under Windows. Assuming that you need it to share files with Windows (else why use it?) I would run it on Windows if on the same machine, else in a Windows virtual machine or Wine if possible.
Latest update from ESET is that indeed you need to have a multilib environment. The reason is that they run some processes in 64bit and some processes under 32bit libraries, because they run more efficiently under 32bit. They take the same approach with Windows 64 bit clients, which have always included 32bit compatibility drivers. Thus the ESET knowledge-base articles to install the glibc.i686. When I had this installed last year I was running multilib and had no problem installing. Clearly the solution is to install AlienBob's multilib and again become a true 32/64bit system, rather than pure 64bit. This thread will be marked as solved.
While trying to make a decision of if I want to install multilib, I looked at vb100 testing and found that the ESET File Security for Linux product has a very high rating for reactive and proactive detection as of Feb 2017. Although vb100 didn't test Nod32, the engines in both products are the same. Otherwise the most recent test of Nod32 for Linux was in October 2015 by AV-Test and it also had very high ratings for detections. Lastly I have checked shadowserver.org, altough it doesn't use the latest Linux engine, and it also shows ESET Nod32 for Linux with top detections in the all time periods. So I figure this is probably the best I can get.
UPDATE: I've again had an issue with poor response time from ESET Technical support on a very simple question, what is proper MD5SUM of installation file to verify the file version number. It's been two weeks and only an acknowledgement of my question, no answer. I'm looking at other products to replace ESET and maybe get out of needing multilib also, woohoo! :-) I'm going to leave this thread alone going forward since the discussion won't be about ESET.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
