Could Not Load Library Client Hl2 Mod
Karmen Mcarthun
even if this could be a game related problem, I would ask here if anyone who plays tf2 got this error and how to fix it, I tried to solution from valve but don't work, running hl2.exe in win98, and with gameoverlayrender disabled, tf2 still causes this problem, I have also tried redownloading it. The winehq test is done from a arch x86_64 so I dont think that 64bit is a problem...anyone can help?
I had this problem about a month ago after a Steam update. I think I had to install lib32-libldap. If that doesn't work, post back and we can just compare installed lib32 packages, because I'm almost certain one of them is what fixed it.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
HL2 mods literally do not work for me. This is one of the most ANNOYING problems I have ever encountered with any game. Mods simply REFUSE to work no matter what I try. I've scrolled countless pages of google, found many """""""solutions""""""" that don't work at all for me but have somehow worked for other people with the same problem. I have Source SDK Base 2006, 2007, and 2013. 2013 is set in beta upcoming, as most mods require. I follow the readme of every mod, their instructions on the mod's post, still nothing wants to work. I've only gotten two mods to work somehow just by pure luck. I've tried verifying game cache, tool cache of the SDK bases, restarting steam, deleting HL2 bins, verifying again, and nothing works. I've even tried repairing steam service. I get the update window (even though it's a mod), I click play, it shows the intro, then the loading screen, and the game crashes with "Could not load library client. Try restarting. If that doesn't work, try verifying game cache." Great instructions right? I've tried contacting the mod creator but he takes a while to respond. Even he said he doesn't know how to fix that. So if there's any definite or possible fix let me know.
You receive this error if your mod's bin folder does not contain a client DLL or DLL was unable to be loaded. Make sure your build toolset is copying its client and server DLLs to the right directory (your mod's modfolder), but most importantly, make sure those DLLs successfully build in the first place!
I have a semi-large application developed under Windows (Windows 10, LabVIEW 2015 SP1), that also works under an Ubuntu Linux environment. When I release an update, I have to build the same application under Windows and Ubuntu separately. 99.9% of the time, this is fine. However, I now need to use the LabVIEW HTTP Client VI's to perform some queries to a web service. Under Windows, these work fine, but when trying them on my Ubuntu virtual machine (which has LabVIEW 2015 SP1 installed with all add-ons that were on the Linux LabVIEW DVD), I get the following error:
I have scavenged through all of the threads I could find concerning the topic and tried the suggested fixes, but to no avail. Tried reinstalling, tried creating a new symlink, reinstalling all add-ons, disabling my firewall, but no results whatsoever, still the same cryptic error message.
Most likely one of the shared library dependencies is not correctly installed on your Ubuntu system. What Ubuntu version and bitness (32 bit or 64 bit) do you have? Which variant of LabVIEW did you install (32 bit or 64 bit)?
You probably have a 64 bit Ubuntu version and run a 32 bit LabVIEW version. That usually works but can cause problems for extra libraries since not every 32 bit library is likely installed by default in your system.
Generally speaking you have to find out which libraries the httpclient library depends on and then possibly find secondary dependencies of those libraries too. As far as I know httpclient itself uses libcurl and several other such open source libraries which should be installed by default together with LabVIEW. One of them might use other libraries that NI considers default libraries for Linux and does not include with the LabVIEW installer.
Or also a possibility you installed some other program in your Ubuntu system that came with it's own older version of one of those libraries and also manipulated the LD_PATH variable or created public symlinks for them, so that when the LabVIEW library gets loaded and asks for one of these libraries it gets served the old library which is missing a specific export that the LabVIEW provided library needs. As soon as a single import in a library can not be satisfied the loading of the entire library will eventually fail.
I am using Ubuntu 16.04 LTS (32-bit) under Oracle VirtualBox and LabVIEW 2015 SP1 (32-bit). The VM was created for one purpose only, which is building LabVIEW Linux applications. I have not installed any 3rd party software which would meddle with my LD_PATH or anything like that. Of course it is possible that something that was installed by default with my Linux installation is doing it...
I checked the symlinks in the directory and all the links were actually there - for example, "libmpr.so.4 => not found" actually links as such: "libmpr.so.4 -> libmpr.so.4.1.0", which is an existing file in the same directory.
I'm not very much at home with shared libraries under Linux, so I can't really make any conclusions from this output. All the files seem to be there, all the symlinks seem to be there to link older files to new ones. Could it be some kind of a permissions issue...?
While I'm not very familiar with shared libraries in Linux, I did some digging after reading your ldd output. It seems like the fact that it isn't finding the links even though they are there could be the source of your problem. After doing a bit more research, it seems that this can happen for a variety of reasons. A few people have fixed this issue by running ldconfig to create the necessary links. For more information on ldconfig, please see the man page:
Thanks for helping me dig around. I tried the ldconfig approach and while it actually seems to have helped to some extent (some "not found" lines are no more present as seen in the attachment and the ones remaining seem to be user interface-related), there is no difference in LabVIEW itself; I still get the exact same error message when trying to use the HTTP library. Naturally I also tried restarting the system after relinking the libraries, restarting LabVIEW, trying the relink when LabVIEW was not running, relinking while running, you name it.
This is all such a fuss that it really seems a nightmare integrating it into an installer for my application on a live system. Unfortunately, I'm quite out of options here, other than running the application in a Windows environment only OR scrapping the whole new functionality, and neither of those options is desirable right now.
But these libraries are not self contained. Most of them rely on system libraries such as libc, and various other ones that are USUALLY present on any reasonable Linux distribution but there is no guarantee about that, thanks to the very varied world of Linux. That is one of the reasons one can not simply develop an application for Linux and then say it will work on every Linux distribution. Each distribution has its own ideas about what tools it packs into the main system, and accordingly what dependencies get installed alongside with them and in what version.
You will likely have to start at libni_httpClient.so and list its dependencies, then find each of them, which could be anywhere in /usr/lib and even the system /lib directory and possibly in other directories that your distribution might add to the /etc/ld.so.conf file to search for additional libraries. Then list all dependencies of each of those files too and continue like that until you found them all. One of them is likely not present.
If you can't find any dependency that is not present, you might have a more complicated problem that one of your system libraries really is an older (or sometimes newer version) than what the NI libraries where build against and is missing a particular exported function.
All this is the Linux version of DLL hell, as you can encounter it on Windows too. While the Linux ELF standard tries to avoid some of the problems that cause DLL hell on Windows, it is basically completely helpless against the diversification of the Linux world and bad discipline of library developers, who often forget to do a sensible versioning for their libraries or even worse, discontinue or change APIs at their whim.
I did some extensive digging and could not find anything - all the deeper dependencies seemed fine, all the libraries that were linked to outside the LabVIEW resource folder (system libraries) seemed in order and nothing was reported missing.
So it seems kind of hopeless, really - a lot like the Linux version of DLL hell you described. Something is missing or configured wrong, but finding out the exact root cause is beyond me - looks like I have to give up for the first time during my 10+ years of LabVIEW conquests.
Of course, Ubuntu Linux is not specifically supported by LabVIEW and so I probably can't complain; but it just seems unusual that something is so difficult to debug. Thanks for helping, I'll leave this thread open just in case someone discovers a breakthrough at some moment.
It also includes a registry cleaner as well as a junk file cleaner. It is safer to use it than to try to manually detect leftover files. The registry utility includes a backup option that you can use to make sure everything goes smoothly.
As you can see, Engine error: Could not load library client error can create some trouble, but in most cases, you can fix it by downloading Download Microsoft Visual C++ 2010 Service Pack 1 Redistributable files.
93ddb68554