is anybody using FASM to produce Mach-O binaries?
it's my assembler of choice and I thought it would be nice to learn whether that's possible to accomplish and whether somebody is already doing it.
thanks in advance.
Tomasz Grysztar (the author) said that Mach-O support is on the way ( http://board.flatassembler.net/topic.php?p=38075#38075 ), perhaps you should go there and ask for it to give him an extra push ;)
(edit)Sorry missed another thread: http://board.flatassembler.net/topic.php?t=9954 . There you'll see that someone succeeded by making an ELF object and then using an external tool to convert to Mach-O format before linking.
Related
Out of educational purposes I'm trying to use Eigen in my pet project. In order to speed the math I included macro EIGEN_USE_BLAS which activates use of blas library.
But I encountered an issue when I tried to upload my project to Testflight. The Apple response to that was:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: _saxpy_, _sgemm_, _sgemv_, _strmm_,
_strmv_. If method names in your source code match the private Apple
APIs listed above, altering your method names will help prevent this
app from being flagged in future submissions. In addition, note that
one or more of the above APIs may be located in a static library that
was included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I know that Apple has blas library as a part of Accelerate.framework and it should be use strictly through Accelerate API. But the thing is that Eigen also has their own blas included in their source and the library actually has no intention of using Accelerate.framework private guts. So that is why Apple asks me to rename those functions or remove them completely in order to get rid of that inconvenience.
But I'm not even sure that it is possible to do - to tune Eigen and its blas to use alternative names.
Is there maybe a way to solve that issue in some efficient manner? Or maybe I don't know something about Eigen usage in iOS environment?
I was lucky to figure out the problem with few tips from my fellow colleagues and a strong will to get the job done, and now I want to share with you my conclusions.
The problem: Eigen doesn't have BLAS binary provided, it only has it's headers. And when one uses EIGEN_USE_BLAS macro and it actually works, that means that Apple is linking Eigen BLAS functions to their binary - BLAS binary which is a part of Accelerate.framework. The trickiest part is that your project doesn't necessarily should have Accelerate.framework inside. XCode will add necessary files automatically and of course it won't bother to tell you that.
What's weird for me the most here is that using "naked" BLAS provided by Apple's Accelerate.framework is a clear violation because it's private API. So... from my perspective it's kind of XCode violates this rule without my intention and tells me nothing about it. Strange...
So, in order to fix it, you need to build BLAS or OpenBLAS binary (I have built OpenBLAS), add it to the project and link through Other linker flags in Build settings. After that the error is gone and you're able to upload your build to Testflight.
In order to save you some time in building OpenBLAS for iOS, I will leave you few links. I think those would be enough:
http://www.programmersought.com/article/2638161057/ - very clear tutorial on how to build OpenBLAS
https://github.com/xianyi/OpenBLAS/tree/release-0.2.21 - source code of the library
https://github.com/xianyi/OpenBLAS/issues/1531 - discussion where you can find solutions to problems you might encounter
What I found the most confusing part of this whole story is the message from Apple. Here's another copy of that:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: saxpy, sgemm, sgemv, strmm, strmv. If
method names in your source code match the private Apple APIs listed
above, altering your method names will help prevent this app from
being flagged in future submissions. In addition, note that one or
more of the above APIs may be located in a static library that was
included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I'm not a native English speaker but I feel pretty confident to say that this text is a non-sense and has absolutely nothing to do with the solving of the actual problem.
It says absolutely nothing about the fact that private API was linked to my code and that is the problem. And that I need to provide my own backend for those functions in order to make error disappear. It says about names matching and that altering my names will help to solve the problem, when it clearly will not in my case.
I hope Apple will bring more clarity into this problem and that errors descriptions will have more sense in the future.
I have been trying to work on an existing Objective C project provided by client and when i try to run the project i get this error. Could anyone help me how to fix this ?
Edit : I am actually sorry, i used a different image screenshot than what my actually problem is. I have replaced my image in the question now.
I have met this question days ago, my problem was I forgot drag one of my using-frameworks into Link Binary With Libraries. maybe you should check this.
Also you should check if ImageObjCommentTableViewCell these classes which mentioned in the error log contained in the Compile Sources.
The subject says it. But just to make it more clear, I wonder what the difference is in detail. I mean binary header, or some data alignment, or ways to map and remap functions or something else you know of?
Can you just use Android ARM ELF binary on iOS? Why not? I mean syscalls? libc? elf format difference? I know Darwin is not Linux. So maybe syscalls. But I am just guessing, I want to know from someone who knows.
For example I compile with arm-ios gcc, and then link with arm-linux ld, what will happen? Will it work? Or why exactly not if not?
Sorry, my wording is messy, because I lack some deep knowledge. But that is why I look for expertise. Otherwise I would know how to find this info myself.
Thank you
iOS binaries don't use ELF file format but mach-o file format. Which are totally different formats.
I received a device with an SDK (*.h *.a files) and built a small app with it.
Now I received a new SDK that does almost the same operation and the *.h file is identical to the first sdk.
The first SDK is used to do some measurements and the second does it differently. I would like to compare the results.
The question is: Can I integrate both sdk in the same app? What do I need to do?
I hope I was clear enough. If any more information is needed I'll be happy to supply it.
As far as my understanding the answer is NO.
The linker needs to setup function pointers during the linking process. If the header file is the same, that also implies the signature of the functions were the same. There's no way for the linker to differentiate the function signature and setup different function pointers for the resulting binary.
I've been building a static library to share between multiple iOS projects, and I want to use gcov (or any code coverage analysis tool) to tell me where I'm missing my tests. However, when I enable gcov by following these directions: http://supermegaultragroovy.com/blog/2005/11/03/unit-testing-and-code-coverage-with-xcode/
I get this error from Libtool:
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/libtool: can't locate file for: -lgcov
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/libtool: file: -lgcov is not an object file (not allowed in a library)
For some reason XCode4 can't find the libgcov.a file. It is in many places on my system but for some reason it can't be found. I'm fairly new to XCode, and gcc based programming in general, so I'm not sure how I can fix this, my guess is that I just have to tell it specifically where to find libgcov.a but I'm not sure how to go about that.
Looks like I found a solution. Crazy XCode seems to treat static libraries completely different when invoking gcc. And I thought MSBuild was a build system from hell... it's a snap and at least there are books about it.
Anyway, here's how you do it:
Add $(PLATFORM_DEVELOPER_USR_DIR)/lib to your "Library Search Paths" build setting for your static library and tick the "Recursive" check box.
Works for me, let me know if it works for you.
This may help in solving your issue, have a look in to it
GTM