Freeimage missing symbols for 32bit for 0.9.3 on OS X #4993
Comments
|
Can be tracked back to PR #4977 |
|
Argh. Sorry. It appears that the apothecary script is not building both for some reason ... seems like travis could also catch things like this no? |
|
@danoli3 Any thoughts on this? |
|
Ah, I'd say it could be the merge into 1 pass optimisations @arturoc made, it must be skipping past i386 instead of doing both. |
|
I just checked the Makefile, it looks like it should be correct, I'll have a look internally at the objects during a test build... trying now. |
|
Hmmm my generated build seems okay in terms of creating the objects: |
|
It has to be related to the damn FreeImage header. |
|
Sounds like we need to revert the header to 0.9.2 and recompile on a 10.9+ machine to get the best of all solutions. |
|
Yeah definitely: Look here: "_TIFFSetSubDirectory", referenced from: Issue: Being of course the type in the function... "uint64" |
|
I'll revert the FreeImage repo changes we made, should be good from there I think |
|
The 0.9.0 freeimage.a is 18.6MB and the 0.9.3 one is 16.4MB so thats probably the missing symbols. Probably erring the same as it pulls from: https://github.com/danoli3/FreeImage @danoli3 sounds good - reading your replies as I write this :) |
|
@danoli3 did it work for you? still getting the same errors over here. |
|
It was a force reset, and yeah, same error, baffled. On Tuesday, 15 March 2016, Theodore Watson notifications@github.com wrote:
|
|
Maybe remove that strip -x from the script On Tuesday, 15 March 2016, Daniel Rosser danoli3@gmail.com wrote:
|
|
hey, just to let you know that i didn't modify the freeimage script to use one pass. only poco but in any case since it'll use clang to compile if you manage to pass: to the compiler it'll compile for both architectures without need to compile twice, use lipo.... |
|
Yeah sorry @arturoc yeah we realized it wasn't any of that, still unsure why it's doing this now. Any ideas, Sent from my iPhone
|
|
okay I have a fix for this. |
|
yeah i reopened the 0.9.4 milestone this morning. we shouldn't touch the 0.9.3 branch anymore since it's already released. there's also a couple of other issues that are milestoned for 0.9.4 so let's create a 0.9.4 branch from current stable or 0.9.3 and PR this against that branch |
|
just created the branch |
|
Okay this should be fixed now in the 0.9.4 branch. |
|
can you send a PR to the apothecary repo too so this doesn't get lost once we move to having the libraries built there? |
|
Nice work @ofTheo ! |
|
Yeah I had a look! Very interesting, I wonder why it started messing up now, maybe something in the new clang merging the libs, no idea, lets keep this in mind for issues post 0.10.x libs merge. |
From the forum: https://forum.openframeworks.cc/t/of-0-9-3-not-building-32-bit-on-osx/22777
Doing a lipo -i it shows a FAT lib.
But it looks like its missing 32bit for TIFF/PNG etc
I am able to reproduce with the current 0.9.3 download building an example with 32bit target.
ping @bakercp
The text was updated successfully, but these errors were encountered: