[Openmcl-devel] error linking OpenCV on osx

[Stefano Bennati]

Thank you all for your replies!
I followed Gary's suggestion and it worked! The problem was the graphics 
not being visualised, and refreshed, in the main thread.
I know the cl-opencv and I find it really cool, but in my case is of no 
use, because the existing library I'm using is written in C++.
Thanks again!
Cheers
Stefano

On 11/16/12 3:42 PM, Gary Byers wrote:
> Someone who actually takes time to build the OpenCV libraries and their
> dependencies may reach a different conclusion.  For all I know, that'd
> only take a few seconds, but I'd prefer to just make a guess ...
>
> On OSX, code that does "GUI things" (graphics, event processing, etc.)
> only works when it runs in the initial thread.  It's the World's Most
> Advanced Operating System!  (Yes, I know: saying that every few days
> hasn't made it any more reasonable, and I sometimes doubt that it will.)
>
> In CCL, the initial thread (the thread that's created by the OS when the
> application is run) ordinarily does some initialization, creates another
> thread to run the REPL, then spends most of its time sleeping.  It wakes
> up a few times each second to do periodic "housekeeping" tasks, and wakes
> up again when QUIT is called (to shut down other threads and exit.)  
> Things
> are a little different in the Cocoa IDE on OSX (the initial thread runs
> an event loop and another thread does "housekeeping"), but in almost all
> cases a listener thread isn't the initial thread.
>
> AFAIK, SBCL behaves differently (and the listener thread is ordinarily
> the initial thread.)
>
> Calling code from a listener thread - when that code only works
> correctly if it's called from the initial thread - only works correctly
> if the listener thread is the initial thread.  Since that's ordinarily
> not true in CCL, that means that it's necessary to cause that code to 
> run in the initial thread.
>
> Your example uses OPEN-SHARED-LIBRARY to ... open a few libraries, loads
> some lisp sources, then calls DO-CAPTURE (which, I assume, calls into the
> OpenCV library.  Since some library initialization code on OSX executes
> illegal debugging instructions if it's run on a thread other than the
> initial thread - and since we can't expect a multibillion dollar company
> to do better than that - OPEN-SHARED-LIBRARY on OSX arranges to actually
> try to open the library on the initial thread.
>
> I don't know whether anything that happens when the .lisp files are 
> loaded
> calls into the foreign libraries; if so, those things need to be done in
> the initial process.
>
> The call to DO-CAPTURE likely does need to be done in the initial thread.
> One way to arrange for that to happen is to use 
> CCL::CALL-IN-INITIAL-PROCESS.
> (I believe that the intent was to export that symbol and document its 
> definition,
> but that doesn't seem to have happened.)
>
> (CCL::CALL-IN-INITIAL-PROCESS thunk)
>
> arranges for the initial thread/process to call the 0-argument 
> function THUNK
> in the initial thread, waits for it to complete, and returns whatever 
> values
> THUNK returns.  If I remember correctly, nothing especially useful 
> happens
> if an error occurs during execution of THUNK, so you may want to do 
> something
> like:
>
> (multiple-value-bind (success error)
>    (ccl::call-in-initial-process (lambda ()
>                                    (ignore-errors (do-capture asd) t)))
>   (unless success ...))
>
> That isn't absolutely horrible; it's probably harder to remember the 
> need to
> deal with this issue than it is to actually deal with it.
>
> I think that the reasons that CCL does things the way that it does (runs
> the listener/REPL in a non-initial thread) are at least somewhat good 
> ones;
> they do cause people to run into problems like this, and I don't know 
> that
> those reasons are so compelling that we wouldn't want to consider doing
> it the other way.  People would still have to be aware of these OSX 
> limitations -
> (PROCESS-RUN-FUNCTION "background" (lambda () (do-capture ...))) would
> have the same problems, running under SLIME may also do so - but 
> people who
> just want to use a foreign library wouldn't have to keep this in mind to
> the degree that they currently do.
>
> [Of course, this may be another problem entirely.  If so, feel free to 
> ignore
> the above and wait until someone has time to build the library and 
> explore
> the issue.  Hmm.  That might have taken less time than it took to 
> write this
> message.]
>
>
> On Fri, 16 Nov 2012, Stefano Bennati wrote:
>
>> Hallo everyone,
>> I write because I get a weird error while foreign-loading a C++ 
>> method that uses OpenCV on OSX.
>> Let's start from the beginning: I want to run from LISP a C++ library 
>> that does some image processing.
>> I created a small example that shows an image on screen, then I used 
>> SWIG to create the wrapper and compiled it into a shared library.
>>
>> The weird thing is that the image is shown correctly in both Clozure 
>> and SBCL on Linux, but on OSX it is shown only in SBCL... Clozure 
>> shows a white rectangle instead.
>> It is really important for me to let it run under Clozure for OSX! 
>> Any help will be really appreciated!
>>
>> I attach a zip file with the example, there are two makefiles, one 
>> for Linux and one for OSX (sed not working properly in the latter) 
>> and four LISP loaders: two for SBCL, one for Linux and one for OSX 
>> and 2 for CCL, one for Linux and one for OSX
>>
>> Cheers
>>
>> -- 
>> M.Sc. Stefano Bennati
>> Centre for Cognitive Science
>> Friedrichstr. 50
>> D-79098 Freiburg, Germany
>>
>> Phone: +49 761 203-4947
>> Fax:   +49 761 203-4938
>> email: bennati at cognition.uni-freiburg.de
>> web: http://portal.uni.freiburg.de/cognition/members-de/bennati/
>>
>>


-- 
M.Sc. Stefano Bennati
Centre for Cognitive Science
Friedrichstr. 50
D-79098 Freiburg, Germany

Phone: +49 761 203-4947
Fax:   +49 761 203-4938
email: bennati at cognition.uni-freiburg.de
web:   http://portal.uni.freiburg.de/cognition/members-de/bennati/