Apothecary: OpenCv 2.4.9

[ofTheo]

Static libs, headers and apothecary formulas for architectures included:

• OSX FAT (32 bit w/ libstdc++ and 64 bit w/ libc++)
• iOS FAT (armv7, armv7s, arm64, i386, x86_64 all with libc++)
• Linux (32 bit)
• Linux (64 bit)
• Linux Armv6l
• Linux Armv7l
• Android - armeabi (@arturoc ?)
• Android - armeabi-v7a (@arturoc ?)
• Android - x86 (@arturoc ?)
• VS (?)
• win_cb (?)

---

Creates a single FAT opencv.a lib with O3 optimization and 64bit libc++ and 32bit libstdc++

don't merge yet.
still to do.

• don't use build root - use build folder.
• find a better way to keep _buildroot folder clean ( right now lipo will suck up any lib in _buildroot/lib/)
• remove libtiff lib

ping @pizthewiz

changes

• removed OpenCL as it was causing errors
• removed some other libs not needed ( CUDA etc )
• lipo for loop wasn't working - fixed.
• error suppression for lipo incase lib is already FAT
• libtool into a single opencv.a

formula based off of @pizthewiz gist - addresses #3039

[pizthewiz]

Glad that mostly worked out. Is the libtooling into a single static lib a something that should be done with other libs and platforms? Would the result be better named libopencv.a?

[ofTheo]

thanks for all your hard work on it!

for OS X its unfortunately necessary to remove the lib prefix see: #2252 (comment)

the libtool into a single .a just makes it a bit easier for manually adding opencv to an existing project.

[bakercp]

Hey @ofTheo I know we've talked about this before (your comment on #2252 being the location) but I'm still not sure why having the lib prefix would cause linking problems if a given project is set up correctly.

The main motivation for tracking this down is that it makes the apothecary formulas much cleaner if we don't deviate from the default settings / names produced by each library's makefiles.

Can you provide a quick reproducible example of where this fails for you? I'd like to try to track this down and figure out the exact cause (again, because it will make apothecary formulas for osx about 25% smaller).

[ofTheo]

this last commit builds the 32bit and 64bit libs seperately in a subdirectory of _buildroot ac8bb9f

the structure create looks like this:

the lipo phase merges the libs from 32bit and 64bit into FAT and then the copy phase copies the includes and lib from FAT into the ofxOpenCv addon lib location.

curious what you think of this approach @bakercp as a good practice for all libs. ( Windows wouldn't have the FAT folder just 32bit and 64bit )

[bakercp]

@ofTheo I'm renaming and organizing the apothecary-related PRs. I moved parts of the title to the description.

[bakercp]

@ofTheo Let's make this PR the central PR for all platforms. I'd suggest that collaborators should PR against your branch so we can keep the formula, headers, and related build-settings in sync across platforms.

[ofTheo]

perfect - sounds like a good plan!

[ofTheo]

got iOS working. it might need some tweaks to do all the different arch we want. but it is doing the simulator + device now.

[bakercp]

Hey @ofTheo and @julapy Are we building iOS fat libs for:

(armv6?) armv7 armv7s arm64 and for the simulator i386 x86_64

If so, which of those should be using libc++ and which of them should be using libstdc++?

On desktop, all 32 bit osx platforms are staying with libstdc++ for now, so should all 32 bit ios related archs also use build using libstdc++?

[ofTheo]

That's a great question!
I don't know the answer. I think we dont need two archs for simulator.

We should just do one I think.

On Aug 11, 2014, at 7:14 PM, Christopher Baker notifications@github.com wrote:

Hey @ofTheo and @julapy Are we building iOS fat libs for:

(armv6?) armv7 armv7s arm64 (simulator) i386 x86_64

If so, which of those should be using libc++ and which of them should be using libstdc++?

On desktop, all 32 bit osx platforms are staying with libstdc++ for now, so should all ios related libs also use libstdc++?

—
Reply to this email directly or view it on GitHub.

[julapy]

@danoli3 has a much better handle on iOS libs compilation.
Dan, can you advise?

[pizthewiz]

I think we dont need two archs for simulator.

Without an x86_64 slice, users will not be able to simulate 64-bit iOS hardware, currently:

• iPad Air
• iPhone 5 / iPhone 5s

and likely any to-be-releaed hardware updates. I'm not sure what the iOS plans are for OF-0.9.0, but if dependencies are built via Apothecary, why not build armv7, armv7s, arm64, i386 and x86_64?

[bakercp]

All of those archs (and @pizthewiz's reasoning) sound good to me. I'm going to proceed with all for Poco and FreeImage. They will be very FAT. :)

[ofTheo]

Haha yeah!
Okay sounds good to me.

I'll work in getting those in for opencv

On Aug 11, 2014, at 8:23 PM, Christopher Baker notifications@github.com wrote:

All of those archs (and @pizthewiz's reasoning) sound good to me. I'm going to proceed with all for Poco and FreeImage. They will be very FAT. :)

—
Reply to this email directly or view it on GitHub.

[pizthewiz]

On a related note, could the iOS and iOS Simulator libs be united? Universal Binaries can of course technically handle this but I wasn't sure if we had a reason too. The Xcode build process will strip out the unused architectures (I believe the default setting). It might simplify the targets/linking too, just like libtooling all the OpenCV libs together.

[bakercp]

Yeah, that's my plan lipo them all together in one giant fat lib. Should work no?

[pizthewiz]

Yup that'll work, for some reason I thought we had separate iOS and iOS Simulator libs - nothing to see here…

[arturoc]

i think i'm going to remove opencv binaries from linux and just add it to the install_dependencies script. the packages are usually up to date, ubuntu 14.04 has 2.4.8 and the next version to be released in october already has 2.4.9. only problem is if someone is on an older linux version but i think nothing should break unless you are on a really old version

[bilderbuchi]

what about header changes in opencv, won't that be a problem, if we have the headers in OF, but the binaries from the OS?

[arturoc]

we can just ignore the headers through addons_config.mk and use the ones in the system

[bilderbuchi]

but the the ofxCv* files would see different headers than they expect, right? Sounds like great potential for bugs.

[arturoc]

no, those files won't never be used with the right exclusion rule in addons_config

[arturoc]

oh, you mean that it might be different versions? yes but it's the same with every library in the core, from time to time we need to do some change specific to a different version in linux but it's ok cause at some point that same version is updated in every other platform

[julapy]

the plan is to make iOS5 the minimum version in OF as per #2568
so dropping armv6 goes in hand with that.

[ofTheo]

okay iOS is done.
I cleaned up the script a fair amount as well - its at a fairly good point for someone to build off of for other platforms.

here is how it looks once I build for iOS and OS X - folders are created for each arch and then lipoed into the FAT folder.

the only significant thing was that I can't create one mega lib.
when I do that the boundaries between libstdc++ and libc++ get totally messed up. so now we have opencv_core.a opencv_calib.a etc.

[danoli3]

hey @ofTheo

iOS all working? I tried to build, seemed to infinite loop in the build.
Is this right how to target it?
./apothecary -t ios update ofxOpenCV

Edit: Hmm no I think it just takes a long time to compile! haha XD

1 thing you may need to add for arm64 is
-miphoneos-version-min=7.0 instead of 5.0 (only for arm64)

[ofTheo]

ahh okay.
will add that now and will add the libs to this PR too.

[ofTheo]

okay OS X and iOS libs are in there now.
let me know if anyone notices any issues.

[arturoc]

ok android is ready too.

one thing in the copy rule, it should delete the old folders sometimes some files are not there any more so it's not enough with overwriting them cause the old ones remain

[bakercp]

Ready to merge @arturoc @ofTheo ? What's the status of win?

[kylemcdonald]

hey @elliotwoods could you take a look here, maybe help with checking vs/cb? you're the person who i think would be most frustrated if opencv broke on windows ;)

[elliotwoods]

heya!
i think you mean i'd be the one who'd act the most on my annoyance, right? :)
I've been generally making my own libs recently for ocv, but i can have a check

I'm upside-down busy between now and the end of the year. So I can check libs if they work, but setting up repos/apothecary isn't something I have the attention for right now sorry.

If somebody could send me a zip of their repo with apothecary then I could try to run build on that here with apothecary and check some common opencv functions in a test app.

Elliot

[ofTheo]

closed for #3635

[arturoc]

i'm reopening this since it seems the changes for android weren't included in the new PR. @ofTheo can you take a look and merge this with your version?

[ofTheo]

Thats fine - sorry I missed those commits.
The other PR I merged was just for the apothecary formula - I was going to wait before bringing in the libs. But happy if you think we should just get all the libs in now!!

[bilderbuchi]

just leaving a note, this probably solves #2081

[kylemcdonald]

with everything but windows solved, should we close this in favor of a windows-specific checklist issue?

[ofTheo]

yup def should close. thanks!