chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] #1277 make check failure on OS X 10.11


From: Jim Ursetto
Subject: Re: [Chicken-hackers] [PATCH] #1277 make check failure on OS X 10.11
Date: Fri, 15 Apr 2016 12:12:52 -0500

> On Apr 15, 2016, at 02:21, Peter Bex <address@hidden> wrote:
> 
>> just to let "make check"
>> work on an OS as deliberately broken as OS X. Isn't there some other way? 
> 
> We could add a note to the README stating you have to disable this
> broken feature.  That would be just like on Windows, where we have a note
> that you must disable the virusscanner because that messes with locks
> a lot.

Turning this off requires turning off System Integrity Protection in its 
entirety,
which would not be acceptable for me.  I would rather just not run `make check`.

>> And does this "blacklisting" mean that it is not possible to set 
>> DYLD_LIBRARY_PATH
>> for any invocation of an executable that calls system(3) (which uses sh)? 
>> How broken 
>> is that?
> 
> It's completely retarded and arbitrary.  It's security theatre, if I
> understand correctly how it works; you could compile a custom copy of
> sh and it would *not* block DYLD_LIBRARY_PATH.

It’s worse than that; you don’t even have to compile a new copy.

$ export DYLD_LIBRARY_PATH=foo
$ csi -e '(use posix) (process-wait (process-run "/bin/sh" (list "-c" "echo 
$DYLD_LIBRARY_PATH")))'

$ cp /bin/sh /Users/jim/local/bin/sh
$ csi -e '(use posix) (process-wait (process-run "/Users/jim/local/bin/sh" 
(list "-c" "echo $DYLD_LIBRARY_PATH")))’
foo


But I don’t think there is any way to override the shell called via system(3)
as a workaround, nor should there be.

A possibly better solution would be to include the absolute path to 
libchicken.dylib
in the test version of that library, or in the tested binaries using 
install_name_tool.
That would avoid the use of DYLD_LIBRARY_PATH completely during testing.  But 
the makefile
and build process is not set up for this contingency and I could not figure out
how to do it cleanly, just for the testing phase.

Another possibility would be to provide the option to do a post-install check,
where you test installed binaries, like we used to do.  Of course, you would
probably install into a temporary location for testing, so you would have to
compile twice.

Jim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]