This was my solution for the problem in #244. I'd installed dependencies using apt-get according to the installation instructions but I wasn't getting jpeg/gif support. has_lib.sh wasn't finding anything.
This may or may not be a proper solution for this. Perhaps the test should recurse rather than add a specific sub directory? I feel like I'm out of my league here but I'd love to save someone else this hassle.
Add paths to jpeg/gif dependencies for ubuntu 12.04. /me crosses fing…
Looks like this has been an issue for others:
I still think the test should probably recurse rather than continue appending different known system libraries.
What do you mean by "recurse"?
Ideally we add LIBRARY_PATH env variable support here.
The common library check already looks in /usr/lib, my libs were in /usr/lib/x86_64-linux-gnu. If it walked sub-directories of the common lib paths it would've found mine.
I've had some sleep now, yes, adding a LIBRARY_PATH that gives has_lib.sh a hint would be better than this!
Is this still a problem?
Yes, but the work around is simple.
@TooTallNate @rvagg looks like it makes sense to pull this in
Only for 64bit Ubuntu, it's kind of specific; also this dir should be included in /etc/ld.so.conf.d/ somewhere, otherwise the system would be broken methinks.
Since has_lib.sh does an ldconfig -p, the simple fix is to actually fix up your ld.so.conf, even if that means just putting in '/usr/lib/x86_64-linux-gnu'to that file and runningsudo ldconfig` again.
to that file and running
-1 for me but it's really no big deal either way.
@rvagg I'm fine with requiring 64bit users to do some extra configuration to pull in the relevant libraries. Perhaps this is better solved through documentation?
I guess the best solution would probably be to mirror what gcc and/or gyp are doing to find the libraries themselves, perhaps that is LIBRARY_PATH if those paths aren't in ld.so.conf?
Looks like #216 addresses similar issue and adds even more to the path
Closing, now that #216 is in