I am a newbie with Autotools and currently trying to create a configure.ac file in order to check for several dependencies for the later installation of my program.
Now, I want to check the existence of certain libraries and I have found that using AC_CHECK_LIB can do the trick. I think PCK_CHECK_MODULES could help too but I would like to stick to the former unless PCK_CHECK_MODULES solved my problem:
AC_CHECK_LIB does what is expected to do which is to look for the library and perform an action if found or another one if not found, but, my question then is:
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library? That is to say, if the AC_CHECK_LIB I have is:
AC_CHECK_LIB (foo, function, [action-if-found], [action-if-not-found])
Is there any way for me to get the exact path of this foo library if it is found?
Thanks,
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library?
AC_CHECK_LIB does not provide any mechanism by which you could do so. It does not determine an actual location itself. Per its documentation, this is what it actually does:
Test whether the library library is available by trying to link a test
program that calls function function with the library. function should
be a function provided by the library.
When AC_CHECK_LIB succeeds, then, it knows only that the linker found a library corresponding to the given library name that provides a function having the specified function name. It doesn't know where the linker found it. On the flip side, when that macros does not find a library, that does not necessarily mean it is unavailable, but rather that the linker does not find it subject to the link options, if any, in effect at that point.
Note, too, that that's perfectly satisfactory for many purposes. You need to know the actual location only if you want to use that to locate some other, related resource. And it's rare that configure can find a library without help, yet needs extra information to locate related resources.
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 am new to opencv and I am using opencv for windows. How can I see the source code for a specific function of an opencv library ? I just one want to get an idea of how that specific machine vision algorithm is implemented.
You can get the OpenCV source code from https://github.com/opencv. An easy way to find the header for a function is to open an explorer window in OPENCV_HOME\build\include (where is the location where you chose to install OpenCV) and use the search box to find the header file that contains your function - this will help you know what module it is in. Then you can search in OPENCV_HOME\modules\MODULE_NAME\src to find the source of the the function. This is even easier if you install a search tool like grepWin.
Looking at the source is almost essential for finding out why those pesky OpenCV exceptions are thrown. It also means that you can answer most things about OpenCV yourself without having to ask here.
Here is a direct link to an excellent source code search, courtesy of Github. This is a very straightforward way to find the implementation and internal usages of a function or type.
All the source is now on github:
https://github.com/opencv/opencv and you can use it's search functionalities as well.
I found the answer by Drew Noakes to be the most helpful, especially given the fact that repository structures keep changing over time.
To search in the code or in other places inside a repository using a keyword, the instructions here can be followed.
What would be even easier for first-timers however, would be to simply search for a key word in the github search bar. Then the appropriate advanced search option would generate the tags described in the the earlier linked tutorial.
Am I correct that boost's file recursion requires that the file using the recursion must be in the include path?
I don't see it anywhere in the documentation, but I just debugged a problem where this seems to be the case. This makes using this as a means to generate boilerplate code automatically somewhat limited when used for a library as the library header file may not be in the include path.
Any comments?
It looks to be true. So I wrote a library to deal with this situation. Here it is if anyone else is having the same problem: https://sourceforge.net/projects/relativeiterate/
I am working on an iOS app which links several static libraries. The challenge is, those linked libraries define same method names with different implementations. Oddly, I don't get any duplicate symbol definition errors; but, to no surprise, I end up with access to only one implementation of the method.
To be more clear, say I have libA and libB and they both define a global C method called func1()
When I link both libA and libB, and make a call to func1(), it resolves to either libA's or libB's implementation without any compilation warning. I, however, need to be able to access both libA's func1() and libB's func1() separately.
There's a similar SO post that explains how it can be done in C (via symbol renaming) but unfortunately, as I found out, objcopy tool doesn't work for ARM architecture (hence iPhone).
(I will submit it to the App Store, hence, dynamic linking is not an option)
It appears that you are in luck - you can still rename symbols with the ARM binary format, it's just a bit more hacky than the objcopy method...
NOTE: This has only been tested minimally, and I would strongly advise you to make a backup of all libraries in question before trying this!
Also note that this only works for files not compiled with the C++ compiler! This will fail if the C++ compiler was used on these files.
First, you will need a decent hex editor, for this example, I will be using Hex Fiend.
Next, you will open up a copy of your of of your libraries, let's call it lib1-renamed.a, and do the following with it:
Find the name of the symbol you wish to re-name. It can be found using the nm tool, or, if you know the header name, you should be set.
Next, you will use hex fiend, and to a textual replace of the old name (in this case foo), and give it a new name (in this case, bar). These names must have the same length, or it will corrupt the binary's offsets!
Note: if there is more than one function that contain's foo's name in it, you may have problems.
Now, you must edit the headers of the library you changed, to use the new function name (bar) instead of the old one.
If you have done the three simple† steps above properly, you should now be able to compile & link the two files successfully, and call both implementations.
If you are trying to do this with a universal binary (e.g. one the works on the simulator as well), you'd be best off using lipo to separate the two binaries, using objcopy on the i386/x64 binary, and then using my method on the ARM binary, and lipo it back together.
†: Simplicity is not guaranteed, nor is it covered by the Richard J. Ross III super warranty. For more information about the super warranty, call 1-800-FREE-WARRANTY now. That's 1-800-FREE-WARRANTY now!
I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.