[Top][All Lists]

[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 
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 
>> 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 

$ 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")))’

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 
in the test version of that library, or in the tested binaries using 
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.


reply via email to

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