Hi All,
We're developing an SDK for iOS, the SDK is delivered in a statically-linked
framework. Our library uses openCV and we link OpenCV into the delivered
framework binary.
This SDK was deployed successfully with some clients but we're having an issue
with one client whose application also
> On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
>
> We are aware that the following are possible solutions to the problem:
> a. Switch to use the same version of OpenCV as our client.
> b. Build our framework as a dynamic library (where we a supposed to be able
> to hide openCV inside)
> Both
On 4 Apr 2018, at 17:25, Redler Eyal wrote:
>
> We're developing an SDK for iOS, the SDK is delivered in a statically-linked
> framework. Our library uses openCV and we link OpenCV into the delivered
> framework binary.
>
> This SDK was deployed successfully with some clients but we're having
> On Apr 4, 2018, at 11:34 AM, Alastair Houghton
> wrote:
>
> You could rename the symbols in your copy of OpenCV so that they don’t match
> the standard ones. One way to do that is with the preprocessor (use #defines
> to change the names of the OpenCV functions you use), which potentially
>> On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
>>
>> We are aware that the following are possible solutions to the problem:
>> a. Switch to use the same version of OpenCV as our client.
>> b. Build our framework as a dynamic library (where we a supposed to be able
>> to hide openCV inside)
>>
>>
>> We're developing an SDK for iOS, the SDK is delivered in a statically-linked
>> framework. Our library uses openCV and we link OpenCV into the delivered
>> framework binary.
>>
>> This SDK was deployed successfully with some clients but we're having an
>> issue with one client whose appl
With the symbols, I believe you only need to convert the public symbols. Not
sure how much of an undertaking it is with that library. You can also do this
with other c flags using the -D=
The x86 and arm binaries will need to be stripped during archive time for your
client, leaving only the pro
Saagar Jha
> On Apr 4, 2018, at 12:17, Redler Eyal wrote:
>
>>> On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
>>>
>>> We are aware that the following are possible solutions to the problem:
>>> a. Switch to use the same version of OpenCV as our client.
>>> b. Build our framework as a dynamic
On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
We are aware that the following are possible solutions to the problem:
a. Switch to use the same version of OpenCV as our client.
b. Build our framework as a dynamic library (where we a supposed to be
able to hide openC
Saagar Jha
> On Apr 4, 2018, at 12:55, Redler Eyal wrote:
>
> On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
>
> We are aware that the following are possible solutions to the problem:
> a. Switch to use the same version of OpenCV as our client.
> b. Build our framework as
> On Apr 4, 2018, at 12:17 PM, Redler Eyal wrote:
>
> 1. It makes it easier to pirate our technology (having our stuff neatly
> packaged seperaterly)
> 2. (More importantly) It makes the client's binary larger since it will have
> to include our full library, including simulator code. (corre
> On Apr 4, 2018, at 2:17 PM, Redler Eyal wrote:
>
>>> On Apr 4, 2018, at 9:25 AM, Redler Eyal wrote:
>>>
>>> We are aware that the following are possible solutions to the problem:
>>> a. Switch to use the same version of OpenCV as our client.
>>> b. Build our framework as a dynamic library (w
> On Apr 4, 2018, at 2:38 PM, Saagar Jha wrote:
>
>
> Saagar Jha
>
> I may be misunderstanding you, but why does your code need to be separate?
> Can’t you statically link against your framework, which dynamically opens
> OpenCV (packaged as a framework)?
>
>> 2. (More importantly) It makes
13 matches
Mail list logo
