Note that I am new to iOS (actually, iDevices) internals.
I'm trying to compile iRecovery,
a tool used to communicate with iBoot, iOS's bootloader. Sadly... I'm getting errors about libusb while compiling :
./configure: line 15323: syntax error near unexpected token `libusb,'
./configure: line 15323: `PKG_CHECK_MODULES(libusb, libusb-1.0 >= 1.0.3)'
libusb is installed :
$> pkg-config --libs libusb
-L/opt/local/lib -lusb
$> pkg-config --libs libusb-1.0
-L/opt/local/lib -lusb-1.0
I tried to comment out the line that checks for libusb, but then I get a bunch of not found symbols, such as :
"_libusb_set_configuration", referenced from:
_irecv_open_with_ecid in libirecovery_la-libirecovery.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
My simple question is... WHY ?!
Thanks for any help...
Okay, so here's a dirty workaround :
open (NOT RUN) autogen.sh file, and comment out the "PKG_CHECK_MODULES(libusb, libusb-1.0 >= 1.0.3)" line
save
run autogen.sh modified file provided
open the makefile located in /src : add "-lusb-1.0 -L/usr/local/lib/ -I /usr/local/include/ - I /usr/local/include/libusb-1.0" to the "GLOBAL_CFLAGS" variable
save
cd to main directory (parent of /src)
make
make install
Once done, your should be able to run irecovery from your shell.
Please note that it is not really clean, and that it is only confirmed to work for iRecovery.
But - It Works !
Related
I am currently trying to compile a cpp program with openmp. From what I have read online this is the command that I need to use for indeed using openmp on apple silicon:
g++ -Xpreprocessor -fopenmp -I/opt/homebrew/Cellar/libomp/14.0.6/include -L/usr/local/lib -lomp heat2D.cpp
I have installed everything required for openmp (libomp,llvm,etc...) but it gives me this error:
ld: library not found for -lomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
In addition if try to remove the lomp flag:
g++ -Xpreprocessor -fopenmp -I/opt/homebrew/Cellar/libomp/14.0.6/include heat2D.cpp
this is the error i get:
Undefined symbols for architecture arm64:
"_omp_set_num_threads", referenced from:
_main in heat2D-0b5aaa.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Since you mention that you installed GCC (and LLVM) via Homebrew, the problem is probably (as Jim Cownie suggested) that when you type "g++", you are running the default link to Apple's LLVM installation (which, alas, does not support OpenMP).
The problem is that Homebrew installs its versions of the compiler binary commands using versioned names -- e.g., "g++-12" if you installed the latest version of GCC. So you have to use those names if you want to run the Homebrew versions. (They are probably installed in /opt/homebrew/bin/ in your case, since you have an Apple Silicon Mac.)
(I haven't installed Homebrew's version of LLVM, but it's probably a similar situation for that as well, since you wouldn't want it to overwrite Apple's LLVM commands.)
I'm writing a small C program that uses librt. I'm quite surprised that the program won't compile if I place the link flag at the start instead of at the end:
At the moment, to compile the program I do:
gcc -o prog prog.c -lrt -std=gnu99
If I were to do the following, it will fail to find the functions in librt:
gcc -std=gnu99 -lrt -o prog prog.c
Yet, this works with other libraries. I found the issue when attempting to use a simple Makefile. make actually compiled prog.c without liking first (using -c flag) and then did the linking.
This is the Makefile:
CC = gcc
CFLAGS = -std=gnu99
LIBS= -lrt
LDFLAGS := -lrt
prog: prog.o
$(CC) -o prog prog.c -lrt -std=gnu99
The output I would get when typing make would be:
gcc -std=gnu99 -c -o prog.o prog.c
gcc -lrt prog.o -o prog
prog.o: In function `main':
prog.c:(.text+0xe6): undefined reference to `clock_gettime'
prog.c:(.text+0x2fc): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make: *** [buff] Error 1
I have now crafted a Makefile that puts the linking at the end of the gcc line, however I'm puzzled why it doesn't work if the linking flag is at the start.
I would appreciate if anybody can explain this to me. Thanks.
As the linker processes each module (be it a library or a object file), it attempts to resolve each undefined symbol while potentially adding to its list of undefined symbols. When it gets to the end of the list of modules, it either has resolved all undefined symbols and is successful or it reports undefined symbols.
In your case, when it processed librt, it had no undefined symbols. Processing proc resulted in clock_gettime being an undefined symbol. gcc will not go back and look in librt for the undefined symbols.
For that reason, you should always have your code first, followed by your libraries, followed by platform provided libraries.
Hope this helps.
From the ld (the GNU linker) documentation (http://sourceware.org/binutils/docs/ld/Options.html#Options):
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.
So if you specify the library too early, the linker will scan it, but not find anything of interest. Then the linker moves on to the object file produced by the compiler and finds references that need to be resolved, but it has already scanned the library and won't bother looking there again.
I am building opencv-3.1.0 and I want to use ffmpeg, which is installed in custom path /media/sdcard/usr/lib, /media/sdcard/usr/include.
Normally, linker gives me an error:
/usr/lib/gcc/i586-poky-linux/4.9.1/../../../../i586-poky-linux/bin/ld: cannot find -lavcodec
So I gave cmake some additional flags: -DCMAKE_SHARED_LINKER_FLAGS="--library-path /media/sdcard/usr/lib", DCMAKE_INCLUDE_PATH=/media/sdcard/usr/include.
Include seems not to work at all, but as for linker flags, cmake gave me the following output:
Linker flags (Release): --library-path /media/sdcard/usr/lib
Linker flags (Debug): --library-path /media/sdcard/usr/lib
But when I tried to run make, I got an error:
c++: error: unrecognized command line option '--library-path'
My ld knows '--library-path' flag and finds necessary libraries, e.g. if I run
ld -lavcodec --library-path /media/sdcard/usr/lib --verbose
it gives me
attempt to open /media/sdcard/usr/lib/libavcodec.a succeeded
I may be missing some ground understanding of the whole process.
I am trying to compile the freetype2 library for arm7, using Xcode's command line tools in OSX. I am using the following parameterisation of the project's configure script:
Compiling FreeType for iPhone?
These errors were produced when running the script:
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E conftest.c
In file included from conftest.c:10:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/include/limits.h:15:25: error: limits.h: No such file or directory
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E -traditional-cpp conftest.c
conftest.c:12: error: assert.h: No such file or directory
configure:3426: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
configure:3465: result: /lib/cpp
configure:3485: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
I can see that the missing files actually do exist in the directories output in the error messages.
CFLAGS and LDFLAGS contain the following parameter, which should allow for the inclusion of system header files:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/
The other odd thing that I noticed with these error messages, is that the architecture identifier in the directory structures is i686-apple-darwin10. The -arch armv7 compiler flag is being used, so why are i686-apple-darwin10 directories being inspected at all?
* UPDATED *
I also tried parameterising the configure script as per another example:
https://stackoverflow.com/a/12594507/1704014
The following error terminated its execution:
checking for suffix of native executables... ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
configure: error: native C compiler is not working
This also indicates that a different target architecture (OSX 10.6) is being built against, not arm7.
Any help much appreciated.
The problem in my OSX build environment was the Xcode command line tools installation. I reinstalled the latest distribution of the tools, and was able to compile successfully from then on.
To build the freetype2 library for arm7 and arm7s architectures, I found the following suggested commands useful:
https://stackoverflow.com/a/12594507/1704014
I'm trying to compile OpenCV version 2.3.1 on an Ubuntu 11.10 following instructions described here. I'm getting following error. Can't understand what is happening... /usr/local/lib/libavcodec.a exists but linker can't link against it, or something else?
error:
[ 20%] Built target pch_Generate_opencv_highgui
Linking CXX shared library ../../lib/libopencv_highgui.so
/usr/bin/ld: /usr/local/lib/libavcodec.a(avpacket.o): relocation R_X86_64_32S against `av_destruct_packet'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
The problem is that you are attempting to link libopencv_highgui.so with libavcodec.a. The latter is built from code compiled without -fPIC (which is quite usual), and such code can not be linked into shared libraries on x86_64.
Your choices are:
Obtain libavcodec.so and arrange to link against it, or
Remove libavcodec or -lavcodec from the link line completely.
For the first, you most likely just need to install libavcodec-dev package.
If you do the second, you will still have to arrange for symbols that libopencv_highgui.so needs from libavcodec to be available at runtime. You can achieve that by linking the main executable with libavcodec (either archive or shared variant).
my take would be that, first run sudo apt-get remove libavcodec , then re-install with sudo apt-get install libopencv-dev
I once had similar issue, and the above resolved it
Running a 64-bit version of Ubuntu you have to configure and build ffmpeg with
./configure --enable-shared --enable-pic
as it is described in step 7b and 8b