Libblake2b.so not found

[wilsonk]

Hello John, just a quick note that the tests in the Makefile can't find libblake2b.so (on the linux I am using, which is a Ubuntu clone), because it is built in the local directory and that usually isn't in ones library path.

I set LD_LIBRARY_PATH to the build dir and things work fine (or one could add the build dir to ld.so.conf and re-run ldconfig with sudo privs, I suppose). Perhaps there should be a note in the README or an addition to the Makefile to set LD_LIBRARY_PATH (with a warning I would think :) )?

Anyways, I just thought I would mention it.

On a separate note: can you still build/run xenoncats code? I tried last night and kept getting seg faults (I opened a new ticket about it) for all the versions except cuckoo20? I severely doubt this is a problem specific to my machine, but I suppose it could be. Just wanted to check before I waste 12 hours on memtest86 to no avail ;)

Thanks, Kelly

[tromp]

dear Kelly,

On Sat, Sep 2, 2017 at 9:54 PM, wilsonk notifications@github.com wrote:

Hello John, just a quick note that the tests in the Makefile can't find libblake2b.so (on the linux I am using, which is a Ubuntu clone), because it is built in the local directory and that usually isn't in ones library path.

I thought the line LIBS = -L. -lblake2b ensures that the current directory is included in the library search path. I just did a fresh clone of the repo and everything builds fine...

I set LD_LIBRARY_PATH to the build dir and things work fine (or one could add the build dir to ld.so.conf and re-run ldconfig with sudo privs, I suppose). Perhaps there should be a note in the README or an addition to the Makefile to set LD_LIBRARY_PATH (with a warning I would think :) )?

Anyways, I just thought I would mention it.

On a separate note: can you still build/run xenoncats code?

Yes, I re-cloned his repo on Sep 1 and everything ran fine (except for the few modifications to make it run on Mac OSX).

I tried last night and kept getting seg faults (I opened a new ticket about it) for all the versions except cuckoo20? I severely doubt this is a problem specific to my machine, but I suppose it could be. Just wanted to check before I waste 12 hours on memtest86 to no avail ;)

If his code worked for you before, then you can go back to the pre-September commit and try that again.

regards, -John

[wilsonk]

Hi John,

Sorry about this, but I don't think I properly worded my concern/problem above...the cuckoo programs build fine, but they don't run because the linker can't dynamically find libblake2b.so, thus the LD_LIBRARY_PATH fix. I imagine things are working for you because you either have your build dir in your library search path (via LD_LIBRARY_PATH or ld.so.conf or a similar mechanism), you are linking statically somehow (but you wouldn't be using the makefile then) or the most likely case is that you have a version of libblake2b.so in /usr/lib or /usr/local/lib (or a directory that ld is finding dynamically)?

I just wanted to mention that this is a brand new install of Linux Lite/Ubuntu 16.04 with a brand new 'git clone' (first and only) of cuckoo and I ran into this issue when running 'make test' (or 'make all', or any make command that tries to run one of the programs that use libblake2b.so). I only mention this, at this point, in case someone else runs into the same thing.

Also, it looks like the problem I was having with xenoncats code is due to my version of gcc gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609. I switched over to clang-3.9.1rc2 and his code builds and runs fine. I tested your code with clang also and it runs ever so slightly faster than with gcc, so I assume that the timings I get with xenoncats code should be pretty comparable to gcc. At least this way I can test things now :)

Thanks, Kelly

P.S. You can close the ticket if you feel like it. As I said, I just wanted a note about this in case someone else runs into these problems with new installs of Ubuntu or one of its clones.

[tromp]

dear Kelly,

Sorry about this, but I don't think I properly worded my concern/problem above...the cuckoo programs build fine, but they don't run because the linker can't dynamically find libblake2b.so, thus the LD_LIBRARY_PATH fix. I imagine things are working for you because you either have your build dir in your library search path (via LD_LIBRARY_PATH or ld.so.conf or a similar mechanism), you are linking statically somehow (but you wouldn't be using the makefile then) or the most likely case is that you have a version of libblake2b.so in /usr/lib or /usr/local/lib (or a directory that ld is finding dynamically)?

I'm not compiling statically. On my mac OSX, it shows: otool -L matrix30 matrix30: libblake2b.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

I need to be in the build dir though to run matrix30, otherwise I get tromp$ cuckoo/src/matrix30 dyld: Library not loaded: libblake2b.so Referenced from: /Users/tromp/cuckoo/src/matrix30 Reason: image not found Abort trap: 6

My LD_LIBRARY_PATH, and OSX alternative DYLD_FRAMEWORK_PATH are empty, while DYLD_LIBRARY_PATH only has /usr/local/cuda/lib: in it. So somehow the mac OSX loader looks for libraries in the current dir. Anyway, the current setup is clearly not ideal, and should be fixed.

For now, I'll add a note to the Makefile to add the build dir to either LD_LIBRARY_PATH or to DYLD_LIBRARY_PATH on mac OSX.

Thanks again for the bug report!

regards, -John