On Thursday 12 February 2015 18:54:48 Margaret Lewicka wrote:
On 12 February 2015 at 18:42, Pino Toscano
<ptoscano(a)redhat.com> wrote:
[...]
> We link to libcrypt because it provides crypt(), at least on GNU libc
> and on the FreeBSD libc; it seems not the case on Mac OS X, looking
> at your patch.
> I'd say that this should turn into a proper configure check, trying to
> use crypt() without extra libraries and if not possible with libcrypt.
The crypt() thing is explained here:
https://developer.apple.com/library/mac/documentation/Porting/Conceptual/...
(Compiling... in OS X -> Other Porting Tips -> Functions -> crypt).
(TL;DR: crypt() comes from unistd.h)
Actually it is defined in POSIX that crypt() is provided by <unistd.h>:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html
The issue is about finding the right symbol for it, hence the need for
a proper configure check instead of hardcoding the OS. Otherwise,
it will break in case newer versions of Mac OS X ship a proper libcrypt
(or libguestfs is compiled on some other OS which has crypt() in libc).
> Is setting LD_LIBRARY_PATH somehow harmful/problematic on Mac OS
X?
> If not, I'd say to use a variable for the library paths we want to add,
> then adding them to both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH;
> something like
> libdirs="$b/src/.libs:...etc"
> # Set LD_LIBRARY_PATH to contain library.
> if [ -z "$LD_LIBRARY_PATH" ]; then
> LD_LIBRARY_PATH="$libdirs"
> else
> LD_LIBRARY_PATH="$libdirs:$LD_LIBRARY_PATH"
> fi
> export LD_LIBRARY_PATH
> # ditto for DYLD_LIBRARY_PATH
You'll end up with two semi-identical blocks of code, though, because
you'll have to perform the same -z check for DYLD_LIBRARY_PATH. (As
far as I am aware, Darwin does not use LD_LIBRARY_PATH, hence the
substitution.)
Right... given that run.in is bash, we might as well just switch those
env-checking blocks like
LD_LIBRARY_PATH="$b/src/.libs:...etc$LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
--
Pino Toscano