OS X / Xcode linker problems...

[drd]

I'm working on some cross platform code... links fine on Windows, not on OS X... read some other threads, no solutions... here's what I'm linking against:

libippscemerged.a
libippscmerged.a
libippsemerged.a
libippsmerged.a
libippiemerged.a
libippimerged.a
libippcvemerged.a
libippcvmerged.a
libippacemerged.a
libippacmerged.a
libippsremerged.a
libippsrmerged.a
ibippcore.a

...given the above, I've managed to get the f/iir calls to link, but the vector stuff is being stubborn, for example, link errors:

"_ippsAddC_32f_I", referenced from:
"_ippsMulC_32f_I", referenced from:
"_ippsThreshold_GT_32f_I", referenced from:

and most disturbing of all:

"_ippStaticInit", referenced from:

er, shouldn't that be in core or something? I'm sure there's a simple answer to this, but it's eluding me, and I'm tired.


Being mainly a C++ developer (very little c), I'm having a tough time in general adjusting to the vast and seemingly unorganized ipp libraries. When working with VSTs, almost every variable I deal with is either a float or array or floats, and while most functions provide a version to deal with floats exclusively, others require conversions to ints, with no rhyme or reason other than some allusion to "precision"... I don't need that much. In general there seems to be very little consistency, not just in the signatures, but even in the order of arguments, for example the "state" argument position is different depending on whether I'm setting taps or setting delay line on the state. Thank god for Visual Assist. The pdf is practically unusable without an example of every method, er function, but given that volume one alone is already 1600+ pages, I guess I understand why. I'm hoping the book I ordered will introduce some "order" to the chaos. Certainly this is good stuff to learn in general, but if it actually ends up adding some performance to my applications then maybe it's actually worth it. Sorry, most of the APIs/SDKs I've been dealing with recently have been fairly intuitive, so I almost forgot that's uncommon.

[Vladimir_Dudnik]

Hello,

Actually IPP API is pretty much consistant with the rules defined for it. It might be different from other SDKs you tried.

Did you look at IPP sample package, we have several samples which can be built on Windows, Linux and Mac OS. This may help you to find where is your problem.

Regards,
Vladimir

[drd]

Thanks Vladimir,

I did read the rules, at least what is presented in the documentation, but I had to get them tattooed on my arm. Us lazy function overloading C++ guys aren't used to having to commit that much to memory ;)

Unfortunately there's only one xcode project in the samples and it isn't statically linked, but it turns out that while my project and all it's dependencies were set to i386, the build target still had ppc as one of the archs... I don't know why that's buried there, seems there should be some global project setting, but whatever, I only use xcode to hit "compile".

Quick question:

This doc...

http://software.intel.com/en-us/articles/intel-avx-realization-of-iir-filter-for-complex-float-data

...implies that the coeffs (taps) are normalized to a0 when you initialize the state (or for that matter, I imagine also when you set the taps on a state as well)... is this correct? or, do I need to normalize them before hand. Also, the "conclusion" seems to imply that I'm not going to see any performance improvements with first order filters... did I read that correctly?

Thanks :)

[Vladimir_Dudnik]

The comment from our expert is:

1. You do not need to care on normalization for a0, it is done at initialization stage by ippsIIRInit function
2. first order filter is equivalent to multipication on constant and was not specifically optimized (you can use ippsMulC function)

Vladimir