ajgb / crypt-nacl-sodium

Crypt::NaCl::Sodium - NaCl compatible modern, easy-to-use library for encryption, decryption, signatures, password hashing and more
https://metacpan.org/release/Crypt-NaCl-Sodium
9 stars 10 forks source link

fixes required for using system libsodium #2

Open plicease opened 9 years ago

plicease commented 9 years ago

This includes additional fixes to enable using the system libsodium, if it is available.

See also:

https://github.com/ajgb/alien-sodium/pull/1

ajgb commented 9 years ago

Wouldn't that change switch between statically linked if the -L/-I arguments were used, to dynamically if Alien::Sodium was used?

My aim is to always link to static lib - and if the correct version of library is available already use it (either by locating it with pkg-config or via Makefile.PL switches), otherwise build it using Alien::Sodium.

But never require libsodium nor Alien::Sodium at the runtime.

Which I think mean that the fixes are needed in Alien::Sodium to correctly detect system library, is that correct?

plicease commented 9 years ago

With alien_isolate_dynamic (included in the Alien::Sodium PR you accepted) you will be linking against the static libraries when Alien::Sodium builds libsodium from source (generally this is what you want so that upgrading Alien::Sodium does not break Crypt::NaCL::Sodium), and link against the dynamic libs the system provides if Alien::Sodium finds the system libsodium (again, generally this is what youwant so that you get any security patches or bug fixes to libsodium). Either way Alien::Sodium shouldn't be required at run-time.

plicease commented 9 years ago

Please consider using the raw Alien::Sodium->libs, it will use the static libs when you install Alien::Sodium from source, and use the dynamic libs from the OS.

system lib install fails with:

clang  -shared -O2 -L/usr/local/lib -fstack-protector Sodium.o  -o blib/arch/auto/Crypt/NaCl/Sodium/Sodium.so /home/ollisg/opt/sodium/1.0.3/lib/libsodium.a \
            \

/usr/bin/ld: /home/ollisg/opt/sodium/1.0.3/lib/libsodium.a(libsodium_la-hmac_hmacsha256.o): relocation R_X86_64_PC32 against symbol `crypto_auth_hmacsha256_init' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [blib/arch/auto/Crypt/NaCl/Sodium/Sodium.so] Error 1
FAIL
! Installing Crypt::NaCl::Sodium failed. See /home/ollisg/.cpanm/work/1437139690.1731/build.log for details. Retry with --force to force install it.

edit updated the output which I copied from the wrong source in my first attempt.

ajgb commented 9 years ago

and if you did recompile with -fPIC would that work?

one of the reasons I've doubts about supporting system lib is that it's out of my control - as you have just noticed.

Luckily AFAIK no mainstream distro comes with the required version, so I can assume that whoever installed it manually knows what to do when build or tests fail.

The reason I like Alien::Base is that it allows me to install the version I need, into the location I want - without any interference from the system.

plicease commented 9 years ago

Debian testing has 1.0.3, which is specifically got us started down this route.

I'm not asking you to support the system lib, that is the responsibility of the system devs, but if you can keep it easy for the system devs to integrate their version it is less work for them and they are more likely to include your module.

The control in this specific example that you are trying to exert is not necessary. We've solved the problem of static libraries in AB itself, so I am not sure why you want to do it again in the Makefile.PL. The advantage on relying on AB to do this is that when bugs are found or compatibility for new platforms is added you get the benefit without having to produce a new version of your module.