FWIW, the "github.com/xeodou/go-sqlcipher" library isn't being linked correctly, and it seems to be trying to load /lib/x86_64-linux-gnu/libcrypto.so at runtime.
Not sure what's at fault off hand, but "github.com/xeodou/go-sqlcipher" might be making some assumptions about being dynamically linked. On Monday, July 18, 2016 at 9:57:07 AM UTC-4, Konstantin Khomoutov wrote: > > On Mon, 18 Jul 2016 05:38:50 -0700 (PDT) > kumargv <vijay...@gmail.com <javascript:>> wrote: > > > But for me still it is giving same error > > I also updated to amd64 with go1.7rc1 > > > > these are the dependence of the sample program > > > > linux-vdso.so.1 => (0x00007ffca8fba000) > > libcrypto.so.1.0.0 > > => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fa93c071000) > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > > (0x00007fa93be6d000) libpthread.so.0 > > => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa93bc4f000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > (0x00007fa93b886000) /lib64/ld-linux-x86-64.so.2 (0x000055f1aa574000) > > > > i want to create a binary with all dependence ,so that it can run on > > any m/c without any problem > > Can you suggest something > > Basically you have just transitioned to the world of C debugging. > > The way to go, IMO, is: > > 1) Make sure you have debug versions of the libraries your code depends > on. Alternatively, they may have separate (extracted) debugging > symbols. On your distro, that's usually a package with the -dbg > suffix, like libc6-dbg and libsslX.Y.Z-dbg. > > 2) Figure out how to modify github.com/xeodou/go-sqlcipher so that it > builds its C stuff in debug mode. Unfortunately, this, as I gather, > should be done in two places: its built-in copy of the SQLite > amalgamation and its cgo binding around SQLite and libcrypto. > > 3) Build this stuff with code dumping enabled: > > $ ulimit -c unlimited > $ ./yourprogram > > 4) After it crashes, use `gdb` to load the dumped core file and your > program and then obtain the stacktrace of the code which crashed. > > Refer to the GDB's docs on how to do that. > > Having enabled debugging in cgo code and having debugging symbols of > the libraries used around should make gdb printout provide sensible > information on how it crashed. Unfortunately, after that you'll have > to debug that further, and this requires knowledge of C. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
