Quantcast

OpenCL.framework cause my NIF library to crash

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

CharlesStain
This post has NOT been accepted by the mailing list yet.
Hi everyone,
I'm developing an Erlang binding to a C++ library of mine, which relies on OpenCL.
I set up a basic environment, with proper extern "C", as well as linker flags. In my case the magic words are:

-undefined dynamic_lookup -dynamiclib

Without these additional flags my NIF shared library won't compile. Everything work well until I try to link OpenCL within my NIF library. Bear in mind that I'm on Mac OS and OpenCL comes as a dynamic library (a Cocoa Framework to be more specific) and going to another platform like Linux or Windows is not feasible.
When I try to load my "new" NIF library (with OpenCL linked with it), this is the result:

laetus alfredodinapoli$ rebar eunit
==> elaetus (eunit)
Compiled src/elaetus_app.erl
Compiled src/elaetus_sup.erl
Compiled src/elaetus.erl
Trace/BPT trap: 5

Which is not very informative about what's going wrong. But I suspect it may be related to the dynamic nature of the OpenCL library. In fact, linking my framework, which is a static library, doesn't cause any issue.
I would like to know:

a) If anyone has had any contact with the NIF + MacOs + C++ world
b) If anyone know a workaround for this annoying situation.

Thanks in advance,
Alfredo Di Napoli
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Bob Ippolito-2
Do you also have the -framework OpenCL flag? Static libraries don't
automatically link in their dynamic dependencies.

On Tuesday, March 13, 2012, CharlesStain <alfredo.dinapoli> wrote:

> Hi everyone,
> I'm developing an Erlang binding to a C++ library of mine, which relies on
> OpenCL.
> I set up a basic environment, with proper extern "C", as well as linker
> flags. In my case the magic words are:
>
> -undefined dynamic_lookup -dynamiclib
>
> Without these additional flags my NIF shared library won't compile.
> Everything work well until I try to link OpenCL within my NIF library.
Bear

> in mind that I'm on Mac OS and OpenCL comes as a dynamic library (a Cocoa
> Framework to be more specific) and going to another platform like Linux or
> Windows is not feasible.
> When I try to load my "new" NIF library (with OpenCL linked with it), this
> is the result:
>
> laetus alfredodinapoli$ rebar eunit
> ==> elaetus (eunit)
> Compiled src/elaetus_app.erl
> Compiled src/elaetus_sup.erl
> Compiled src/elaetus.erl
> Trace/BPT trap: 5
>
> Which is not very informative about what's going wrong. But I suspect it
may
> be related to the dynamic nature of the OpenCL library. In fact, linking
my

> framework, which is a static library, doesn't cause any issue.
> I would like to know:
>
> a) If anyone has had any contact with the NIF + MacOs + C++ world
> b) If anyone know a workaround for this annoying situation.
>
> Thanks in advance,
> Alfredo Di Napoli
>
> --
> View this message in context:
http://erlang.2086793.n4.nabble.com/OpenCL-framework-cause-my-NIF-library-to-crash-tp4469412p4469412.html
> Sent from the Erlang Questions mailing list archive at Nabble.com.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120313/225d19f5/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Alfredo Di Napoli

On 13/mar/2012, at 17:54, Bob Ippolito wrote:

> Do you also have the -framework OpenCL flag? Static libraries don't automatically link in their dynamic dependencies.


Yes I've compiled with this flag both my static framework library as well as my shared NIF, but the problem still persist.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120314/6c311354/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Prashant Sharma
was wondering, if everyone is already aware of already existing
https://github.com/tonyrog/cl
-P

On Wed, Mar 14, 2012 at 1:39 PM, Alfredo Di Napoli
<alfredo.dinapoli> wrote:

>
> On 13/mar/2012, at 17:54, Bob Ippolito wrote:
>
> Do you also have the -framework OpenCL flag? Static libraries don't
> automatically link in their dynamic dependencies.
>
>
> Yes I've compiled with this flag both my static framework library as well as
> my shared NIF, but the problem still persist.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Alfredo Di Napoli

On 16/mar/2012, at 09:55, Prashant Sharma wrote:

> was wondering, if everyone is already aware of already existing
> https://github.com/tonyrog/cl
> -P
>

Sure, but the strange thing is that I've discovered that even the "cl" project above cause the NIF to crash.
In other words, I suspect it can be an Erlang VM bug.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120316/eb491c56/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Tony Rogvall-3
I just tried it, and you are totally correct.

The cl nif failed to load on R15B Darwin 11.3.0.
What Erlang release and OS/release are you using ?

/Tony


On 16 mar 2012, at 09:59, Alfredo Di Napoli wrote:

>
> On 16/mar/2012, at 09:55, Prashant Sharma wrote:
>
>> was wondering, if everyone is already aware of already existing
>> https://github.com/tonyrog/cl
>> -P
>>
>
> Sure, but the strange thing is that I've discovered that even the "cl" project above cause the NIF to crash.
> In other words, I suspect it can be an Erlang VM bug.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120316/175a2a06/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Alfredo Di Napoli

On 16/mar/2012, at 11:10, Tony Rogvall wrote:

> I just tried it, and you are totally correct.
>
> The cl nif failed to load on R15B Darwin 11.3.0.
> What Erlang release and OS/release are you using ?
>
> /Tony
>

Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang distribution R15B.
I suspect this isn't a problem with your bindings, though, because I'm the same guy who asked you help about OpenCL binding with NIF via email :)
I've also tried a brain-dead simple NIF application (a stupid app that performs a square of a number), compiling it from command line (so no Xcode involved :) )
The NIF works fine, until I link ANY Mac OS Framework. In my example I've ONLY linked the AppKit.framework: bare in mind that actually the NIF does not uses it in any function call!
The result? Abort trap!

So I guess this could be a Erlang VM bug, related to Mac Os Frameworks dynamic linking process.

Regards,
Alfredo



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120316/6d7ed89d/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Tony Rogvall-3
The problem seem to be dlopen, that it must be called from the main thread,
this used to work. Googling around I can see other people have this problem,
the work around for some projects is to run erlang as:

erl -smp disable

However, this is not possible with the cl binding since it require SMP( sending event messages from
various threads )
You can verify that the cl application loads ok with non smp, but then crash with

enif_send: env==NULL on non-SMP VMAbort trap: 6

as it should :-)

Any OTP takers ? Sverker / Bj?rn ?

/Tony





On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:

>
> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>
>> I just tried it, and you are totally correct.
>>
>> The cl nif failed to load on R15B Darwin 11.3.0.
>> What Erlang release and OS/release are you using ?
>>
>> /Tony
>>
>
> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang distribution R15B.
> I suspect this isn't a problem with your bindings, though, because I'm the same guy who asked you help about OpenCL binding with NIF via email :)
> I've also tried a brain-dead simple NIF application (a stupid app that performs a square of a number), compiling it from command line (so no Xcode involved :) )
> The NIF works fine, until I link ANY Mac OS Framework. In my example I've ONLY linked the AppKit.framework: bare in mind that actually the NIF does not uses it in any function call!
> The result? Abort trap!
>
> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks dynamic linking process.
>
> Regards,
> Alfredo
>
>
>

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120316/1df927ae/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Dan Gudmundsson-5
That is a pain ...

You can grab the main thread within erlang (undocumented ?)  because
the gui must also be run from the
main thread, which means that you can not combine OpenCL with wx (or esdl).

Or is it only the dlopen call that must be run from that thread?

Apple sometimes not so great..

/Dan

On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony> wrote:

> The problem seem to be dlopen, that it must be called from the main thread,
> this used to work. Googling around I can see other people have this problem,
> the work around for some projects is to run erlang as:
>
> erl -smp disable
>
> However, this is not possible with the cl binding since it require SMP(
> sending event messages from
> various threads )
> You can verify that the cl application loads ok with non smp, but then crash
> with
>
> enif_send: env==NULL on non-SMP VMAbort trap: 6
>
> as it should :-)
>
> Any OTP takers ? Sverker / Bj?rn ?
>
> /Tony
>
>
>
>
>
> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>
>
> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>
> I just tried it, and you are totally correct.
>
> The cl nif failed to load on R15B Darwin 11.3.0.
> What Erlang release and OS/release are you using ?
>
> /Tony
>
>
> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
> distribution R15B.
> I suspect this isn't a problem with your bindings, though, because I'm the
> same guy who asked you help about OpenCL binding with NIF via email :)
> I've also tried a brain-dead simple NIF application (a stupid app that
> performs a square of a number), compiling it from command line (so no Xcode
> involved :) )
> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
> not uses it in any function call!
> The result? Abort trap!
>
> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
> dynamic linking process.
>
> Regards,
> Alfredo
>
>
>
>
> "Installing applications can lead to corruption over time.?Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Tony Rogvall-3
Hi Dan!

I think (and hope) that it is only dlopen that needs to be run from the main thread,
is the undocumented feature accessible from the NIF's ?

Otherwise what about having a special async thread you could run in the main thread?

Apple still have not fixed poll ! Lets start a Facebook group ;-)

/Tony

On 16 mar 2012, at 12:09, Dan Gudmundsson wrote:

> That is a pain ...
>
> You can grab the main thread within erlang (undocumented ?)  because
> the gui must also be run from the
> main thread, which means that you can not combine OpenCL with wx (or esdl).
>
> Or is it only the dlopen call that must be run from that thread?
>
> Apple sometimes not so great..
>
> /Dan
>
> On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony> wrote:
>> The problem seem to be dlopen, that it must be called from the main thread,
>> this used to work. Googling around I can see other people have this problem,
>> the work around for some projects is to run erlang as:
>>
>> erl -smp disable
>>
>> However, this is not possible with the cl binding since it require SMP(
>> sending event messages from
>> various threads )
>> You can verify that the cl application loads ok with non smp, but then crash
>> with
>>
>> enif_send: env==NULL on non-SMP VMAbort trap: 6
>>
>> as it should :-)
>>
>> Any OTP takers ? Sverker / Bj?rn ?
>>
>> /Tony
>>
>>
>>
>>
>>
>> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>>
>>
>> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>>
>> I just tried it, and you are totally correct.
>>
>> The cl nif failed to load on R15B Darwin 11.3.0.
>> What Erlang release and OS/release are you using ?
>>
>> /Tony
>>
>>
>> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
>> distribution R15B.
>> I suspect this isn't a problem with your bindings, though, because I'm the
>> same guy who asked you help about OpenCL binding with NIF via email :)
>> I've also tried a brain-dead simple NIF application (a stupid app that
>> performs a square of a number), compiling it from command line (so no Xcode
>> involved :) )
>> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
>> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
>> not uses it in any function call!
>> The result? Abort trap!
>>
>> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
>> dynamic linking process.
>>
>> Regards,
>> Alfredo
>>
>>
>>
>>
>> "Installing applications can lead to corruption over time. Applications
>> gradually write over each other's libraries, partial upgrades occur, user
>> and system errors happen, and minute changes may be unnoticeable and
>> difficult to fix"
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>>

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120316/4d1c06bf/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Tony Rogvall-3
Update.

running cl works on 32 bit emulator.
So that is a great workaround, while poking around in the subject.

/Tony

On 16 mar 2012, at 15:41, Tony Rogvall wrote:

> Hi Dan!
>
> I think (and hope) that it is only dlopen that needs to be run from the main thread,
> is the undocumented feature accessible from the NIF's ?
>
> Otherwise what about having a special async thread you could run in the main thread?
>
> Apple still have not fixed poll ! Lets start a Facebook group ;-)
>
> /Tony
>
> On 16 mar 2012, at 12:09, Dan Gudmundsson wrote:
>
>> That is a pain ...
>>
>> You can grab the main thread within erlang (undocumented ?)  because
>> the gui must also be run from the
>> main thread, which means that you can not combine OpenCL with wx (or esdl).
>>
>> Or is it only the dlopen call that must be run from that thread?
>>
>> Apple sometimes not so great..
>>
>> /Dan
>>
>> On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony> wrote:
>>> The problem seem to be dlopen, that it must be called from the main thread,
>>> this used to work. Googling around I can see other people have this problem,
>>> the work around for some projects is to run erlang as:
>>>
>>> erl -smp disable
>>>
>>> However, this is not possible with the cl binding since it require SMP(
>>> sending event messages from
>>> various threads )
>>> You can verify that the cl application loads ok with non smp, but then crash
>>> with
>>>
>>> enif_send: env==NULL on non-SMP VMAbort trap: 6
>>>
>>> as it should :-)
>>>
>>> Any OTP takers ? Sverker / Bj?rn ?
>>>
>>> /Tony
>>>
>>>
>>>
>>>
>>>
>>> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>>>
>>>
>>> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>>>
>>> I just tried it, and you are totally correct.
>>>
>>> The cl nif failed to load on R15B Darwin 11.3.0.
>>> What Erlang release and OS/release are you using ?
>>>
>>> /Tony
>>>
>>>
>>> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
>>> distribution R15B.
>>> I suspect this isn't a problem with your bindings, though, because I'm the
>>> same guy who asked you help about OpenCL binding with NIF via email :)
>>> I've also tried a brain-dead simple NIF application (a stupid app that
>>> performs a square of a number), compiling it from command line (so no Xcode
>>> involved :) )
>>> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
>>> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
>>> not uses it in any function call!
>>> The result? Abort trap!
>>>
>>> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
>>> dynamic linking process.
>>>
>>> Regards,
>>> Alfredo
>>>
>>>
>>>
>>>
>>> "Installing applications can lead to corruption over time. Applications
>>> gradually write over each other's libraries, partial upgrades occur, user
>>> and system errors happen, and minute changes may be unnoticeable and
>>> difficult to fix"
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>
> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120317/864aaf6c/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Alfredo Di Napoli
So you think the problem may be caused by 64 bit?
I suppose that, in order to work, it need a 32 bit version of Erlang, isn't
it?
Bye
A.

Il giorno 17 marzo 2012 17:03, Tony Rogvall <tony> ha scritto:

> Update.
>
> running cl works on 32 bit emulator.
> So that is a great workaround, while poking around in the subject.
>
> /Tony
>
> On 16 mar 2012, at 15:41, Tony Rogvall wrote:
>
> Hi Dan!
>
> I think (and hope) that it is only dlopen that needs to be run from the
> main thread,
> is the undocumented feature accessible from the NIF's ?
>
> Otherwise what about having a special async thread you could run in the
> main thread?
>
> Apple still have not fixed poll ! Lets start a Facebook group ;-)
>
> /Tony
>
> On 16 mar 2012, at 12:09, Dan Gudmundsson wrote:
>
> That is a pain ...
>
> You can grab the main thread within erlang (undocumented ?)  because
> the gui must also be run from the
> main thread, which means that you can not combine OpenCL with wx (or esdl).
>
> Or is it only the dlopen call that must be run from that thread?
>
> Apple sometimes not so great..
>
> /Dan
>
> On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony> wrote:
>
> The problem seem to be dlopen, that it must be called from the main thread,
>
> this used to work. Googling around I can see other people have this
> problem,
>
> the work around for some projects is to run erlang as:
>
>
> erl -smp disable
>
>
> However, this is not possible with the cl binding since it require SMP(
>
> sending event messages from
>
> various threads )
>
> You can verify that the cl application loads ok with non smp, but then
> crash
>
> with
>
>
> enif_send: env==NULL on non-SMP VMAbort trap: 6
>
>
> as it should :-)
>
>
> Any OTP takers ? Sverker / Bj?rn ?
>
>
> /Tony
>
>
>
>
>
>
> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>
>
>
> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>
>
> I just tried it, and you are totally correct.
>
>
> The cl nif failed to load on R15B Darwin 11.3.0.
>
> What Erlang release and OS/release are you using ?
>
>
> /Tony
>
>
>
> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
>
> distribution R15B.
>
> I suspect this isn't a problem with your bindings, though, because I'm the
>
> same guy who asked you help about OpenCL binding with NIF via email :)
>
> I've also tried a brain-dead simple NIF application (a stupid app that
>
> performs a square of a number), compiling it from command line (so no Xcode
>
> involved :) )
>
> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
>
> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
>
> not uses it in any function call!
>
> The result? Abort trap!
>
>
> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
>
> dynamic linking process.
>
>
> Regards,
>
> Alfredo
>
>
>
>
>
> "Installing applications can lead to corruption over time. Applications
>
> gradually write over each other's libraries, partial upgrades occur, user
>
> and system errors happen, and minute changes may be unnoticeable and
>
> difficult to fix"
>
>
>
>
>
> _______________________________________________
>
> erlang-questions mailing list
>
> erlang-questions
>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120317/027e1912/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenCL.framework cause my NIF library to crash

Tony Rogvall-3

On 17 mar 2012, at 17:12, Alfredo Di Napoli wrote:

> So you think the problem may be caused by 64 bit?

Yepp.

> I suppose that, in order to work, it need a 32 bit version of Erlang, isn't it?

./configure --enable-m32-build; make

/Tony


> Bye
> A.
>
> Il giorno 17 marzo 2012 17:03, Tony Rogvall <tony> ha scritto:
> Update.
>
> running cl works on 32 bit emulator.
> So that is a great workaround, while poking around in the subject.
>
> /Tony
>
> On 16 mar 2012, at 15:41, Tony Rogvall wrote:
>
>> Hi Dan!
>>
>> I think (and hope) that it is only dlopen that needs to be run from the main thread,
>> is the undocumented feature accessible from the NIF's ?
>>
>> Otherwise what about having a special async thread you could run in the main thread?
>>
>> Apple still have not fixed poll ! Lets start a Facebook group ;-)
>>
>> /Tony
>>
>> On 16 mar 2012, at 12:09, Dan Gudmundsson wrote:
>>
>>> That is a pain ...
>>>
>>> You can grab the main thread within erlang (undocumented ?)  because
>>> the gui must also be run from the
>>> main thread, which means that you can not combine OpenCL with wx (or esdl).
>>>
>>> Or is it only the dlopen call that must be run from that thread?
>>>
>>> Apple sometimes not so great..
>>>
>>> /Dan
>>>
>>> On Fri, Mar 16, 2012 at 11:34 AM, Tony Rogvall <tony> wrote:
>>>> The problem seem to be dlopen, that it must be called from the main thread,
>>>> this used to work. Googling around I can see other people have this problem,
>>>> the work around for some projects is to run erlang as:
>>>>
>>>> erl -smp disable
>>>>
>>>> However, this is not possible with the cl binding since it require SMP(
>>>> sending event messages from
>>>> various threads )
>>>> You can verify that the cl application loads ok with non smp, but then crash
>>>> with
>>>>
>>>> enif_send: env==NULL on non-SMP VMAbort trap: 6
>>>>
>>>> as it should :-)
>>>>
>>>> Any OTP takers ? Sverker / Bj?rn ?
>>>>
>>>> /Tony
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 16 mar 2012, at 11:21, Alfredo Di Napoli wrote:
>>>>
>>>>
>>>> On 16/mar/2012, at 11:10, Tony Rogvall wrote:
>>>>
>>>> I just tried it, and you are totally correct.
>>>>
>>>> The cl nif failed to load on R15B Darwin 11.3.0.
>>>> What Erlang release and OS/release are you using ?
>>>>
>>>> /Tony
>>>>
>>>>
>>>> Hi Tony, I'm on a Mac Os X Lion (so SDK 10.7) with the latest Erlang
>>>> distribution R15B.
>>>> I suspect this isn't a problem with your bindings, though, because I'm the
>>>> same guy who asked you help about OpenCL binding with NIF via email :)
>>>> I've also tried a brain-dead simple NIF application (a stupid app that
>>>> performs a square of a number), compiling it from command line (so no Xcode
>>>> involved :) )
>>>> The NIF works fine, until I link ANY Mac OS Framework. In my example I've
>>>> ONLY linked the AppKit.framework: bare in mind that actually the NIF does
>>>> not uses it in any function call!
>>>> The result? Abort trap!
>>>>
>>>> So I guess this could be a Erlang VM bug, related to Mac Os Frameworks
>>>> dynamic linking process.
>>>>
>>>> Regards,
>>>> Alfredo
>>>>
>>>>
>>>>
>>>>
>>>> "Installing applications can lead to corruption over time. Applications
>>>> gradually write over each other's libraries, partial upgrades occur, user
>>>> and system errors happen, and minute changes may be unnoticeable and
>>>> difficult to fix"
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>
>> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"
>
>
>
>

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120317/7d8dacd6/attachment.html>

Loading...