I'm trying to use the ffmpeg libraries in Xcode on Mac. I want to address to 64bit-systems like Lion and Mountain Lion. I tried to compile with
./configure --enable-static --enable-nonfree --enable-version3 --enable-gpl --disable-doc --disable-programs --arch=x86_64 --cc=cc --disable-yasm --host-cflags="-arch x86_64" --host-ldflags="-arch x86_64" --prefix=ffmpeg
Then I copied the ffmpeg-directory (with lib and include folders) into my project folder. I added the .a-files to my project and added the .a files to "Link binaries with Libraries"). Also I adjusted the header and library folder in the project settings. So far so good.
I'm a beginner with those libraries, so I started with opening a video. Works fine.
Now I'm trying to decode a given input file. Therefore I looked at this example file: http://ffmpeg.org/doxygen/1.0/decoding__encoding_8c-source.html
I copied the video_decode_example function. But at compiling I'm getting the following error:
Undefined symbols for architecture x86_64:
"_decode_write_frame", referenced from:
_video_decode_example in cutClass.o
ld: symbol(s) not found for architecture x86_64
What did I wrong at compiling ffmpeg?
decode_write_frame() is not part of ffmpeg — it's part of the sample code you were referring to. Read the sample code more closely and implement your own equivalent. (The implementation in the decoding_encoding.c sample is almost certainly not something you'd want in production code -- it just writes every frame to disk as a PGM image file.)
Related
I've done hours and hours of searching and still no luck (read a lot of stackoverflow as well).
I am trying to implement FDTake via Cocoapods. When I try and run it I get the following:
undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_FDTakeController", referenced from:
objc-class-ref in VendeViewController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I know there is many similar questions around SO but all their solutions don't seem to work for me.
From the logs I can assume that you would be using a static library which is not build for simulator(architecture x86_64).
The library is only compiled for device and it needs to be complied and build for simulator also. Then the two static files (one abc.a for device and one abc.a for simulator) needs to be fat file i.e these files should be merged together using lipo command on terminal to create a fat file. Now when you use this fat file it will work both for simulator as well as device.
But the important thing is that you should have the source to compile and build the static libraries for simulator and device. After which you merge these to create a fat file which will work on all the defined architectures.
In case you are using third party static library (SDK) then you need to contact the respected party.
Everything was fine. I just deleted the old TestFlight folder from my Xcode project, and then dragged the new TestFlight SDK 3.0 into my project, and tried to build and got these errors.
ld: warning: directory not found for option
'-L"/Desktop/Work/Games/ClanKingdom/Game/src/Classes/TestFlightSDK1.2.4"'
ld: warning: directory not found for option
'-L"/Desktop/Work/Games/ClanKingdom/Game/src/Classes/Flurry"' ld:
warning: directory not found for option
'-L"/Desktop/Work/Games/ClanKingdom/Game/src/TestFlightSDK2.0.0"' ld:
warning: directory not found for option
'-L"/Desktop/Work/Games/ClanKingdom/Game/src/Flurry"' ld: warning:
directory not found for option
'-F"/Desktop/Work/Games/ClanKingdom/Game/src/FacebookSDK"' ld: library
not found for -lFlurry_4.2.3 clang: error: linker command failed with
exit code 1 (use -v to see invocation)
Why would it be giving me some issue for Flurry? I've not changed anything for Flurry, also I'm not sure why it's trying to link those older versions of TestFlight as I've deleted them.
Any ideas?
I know you've resolved this issue already, but for completeness you were linking your libraries using absolute file paths to a location where they no longer existed.
It looks like you were linking to the TestFlight library on your desktop. This is a really bad idea, you should either keep all your libraries in one sensible location, or keep copies of them locally in the source code of your project. That way you can modify your 'Library Search Paths' to a relative link, e.g.
$(SRCROOT)/Code\ Folder/Third\ Party\ Classes/Google\ Analytics
So $(SRCROOT) will point to the directory in which your xcode project lives, and you can manually enter the path to your library from there. The advantage being you will be able to move your libraries around with your codebase, but also in this instance simply replace the files within the folder at the path you've chosen, and everything should magically work!
Trying to ready metadata (e.g kCGImagePropertyExifBodySerialNumber or kCGImagePropertyExifLensModel) from images using ImageIO framework.
Unfortunately during the compilation linker has a trouble:
Undefined symbols for architecture x86_64:
"_kCGImagePropertyExifBodySerialNumber", referenced from:
-[AppDelegate applicationDidFinishLaunching:] in AppDelegate.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ImageIO/CGImageProperties.h is of corurse imported, and ImageIO.framework is included on the list "Linked Frameworks and Libraries" in target configuration.
It happends only when I'm trying to use kCGImagePropertyExifBodySerialNumber or kCGImagePropertyExifLensModel. It the same project kCGImagePropertyExifFocalLength, kCGImagePropertyExifExposureTime are used without any problems
Any ideas ?
Those constants seem to not be defined in the SDK versions of the ImageIO framework. You can check this yourself with the following command:
nm /Volumes/Applications/Developer\ Tools/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/imageio | grep -F kCGImagePropertyExifBodySerialNumber
(Edit the path to Xcode as appropriate.)
I'm on a Lion machine at the moment, and the system version of the same framework does have it:
% nm /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/imageio | grep -F kCGImagePropertyExifBodySerialNumber
00000000000e4898 s _kCGImagePropertyExifBodySerialNumber
So, I suggest filing a bug and then, as a workaround, unsetting SDKROOT (“Base SDK”) in your project's build settings. With no SDK set, it should use the frameworks and headers of the system you're building on.
The downside of that workaround is that if you're using anything introduced on Mountain Lion, you won't be able to build on Lion.
Why exactly is it that when I create an iOS static library project or framework project in Xcode, I don't need to link any iOS SDK frameworks to the project in order to make use of their headers and objects -- for example, I can #import <AudioToolbox/AudioToolbox.h> and put AudioToolbox code in the static library or framework without actually having AudioToolbox added under "Link Binary with Libraries" in build settings or having it present in the file navigator, and the project will build without issue, something that wouldn't work in an app project -- but when a developer then uses the static library or framework product in an app, they do have to link to the framework in order to use the same headers and objects?
I have a vague idea of why this would be, but I'd be really interested in hearing from someone who knows for sure.
Static libraries are just a bundle of .o files. They're not "linked" in any meaningful way; just concatenated together. It's not until you perform a real link step that symbols are resolved.
There is basically no difference between linking a .a with your executable and copying the equivalent source code into your executable's project. So there's no need to link with any additional frameworks or libraries until that time.
The following exercise may be educational:
Create the following comptest.c:
#include <stdio.h>
int main() {
printf("Hello world.\n");
return 0;
}
See what the pre-processor does:
gcc -E comptest.c > comptest-cpp.c
This removes the #include and replaces it with the contents of the referenced file. This file is what the compiler actually sees.
Now see what the compiler does (I'm using the > syntax here and below so that things are parallel with -E):
gcc -S comptest.c > comptest.s
This is the generated assembly language after pre-processing and compilation. Now we turn that into a .o:
gcc -c comptest.c > comptest.o
Now let's see what's in that .o:
$ nm comptest.o
0000000000000040 s EH_frame0
000000000000002d s L_.str
0000000000000000 T _main
0000000000000058 S _main.eh
U _puts
The important things here are _main and _puts. _main is defined in this file at address 0. _puts is undefined. So something we link with had better provide it. Let's try linking without anything:
$ gcc -nodefaultlibs comptest.o
Undefined symbols for architecture x86_64:
"_exit", referenced from:
start in crt1.10.6.o
"_puts", referenced from:
_main in comptest.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(_exit is implicit from the C runtime; it's not directly referenced in the .o)
OK, so now we're ready to put it all together. We'll be explicit:
gcc -nodefaultlibs comptest.o /usr/lib/libc.dylib -o comptest
This says to link together comptest.o and the dynamic library libc. It promises that every symbol referenced will be provided by one of these files. It makes a note in the resulting binary that it should dynamically load symbols from /usr/lib/libc.dylib (this is a symlink to libSystem.B.dylib, which is itself an "umbrella framework" rather than a proper library, but that goes a little past what you need to know in most cases; you can pretend that puts() is in libSystem):
$ otool -L comptest
comptest:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
If you link with a static library, it's identical to listing all the .o files included in it on the command-line.
Notice that at the link step, we just have .o and .dylib files (.a is just a package of .o). There are no .c files, no .h files, no .s files, no source code. Just object files that need symbols resolved. This is why header files don't matter here, but do matter when you're compiling.
When I try to run my application in the iOS 4.3 simulator (Xcode 4.2), I crash when I hit #autoreleasepool{}, with:
dyld: lazy symbol binding failed: Symbol not found: _objc_autoreleasePoolPush
I looked around, and I see the workaround is to add libarclite_iphoneos.a. There's a version of this for the simulator, too, as libarclite_iphonesimulator.a.
I need to add both libraries to my project to make it run on both the simulator and hardware. But whichever I build, it complains that the other library is for an unsupported architecture.
For example, building for simulator:
ld: warning: ignoring file /Developer-4.2/Platforms/iPhoneOS.platform/
Developer/usr/lib/arc/libarclite_iphoneos.a, missing required architecture
i386 in file
How do I fix both of these simultaneously? Or should I just stick with the old NSAutoreleasePool syntax for now?
After a trials like clean, clean folder, resetting iPhone Simulator and even a restart, I changed the IPHONE_DEPLYMENT_TARGET on the target build setting down from iOS 5.0 to iOS 4.2.
Worked.
You can use the Other Linker Flags build setting to link in the library, and specialize the value based on whether it's "Any iOS" or "Any iOS Simulator".
You can also merge the two static libraries to one universal library. Go to the Terminal and say
lipo -create -output /where/you/want/it/libarclite_universal.a /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/arc/libarclite_iphoneos.a /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/arc/libarclite_iphonesimulator.a
You can verify the resulting file by saying (in Terminal)
file /where/you/put/it/libarclite_universal.a
It should output:
libarclite_universal.a: Mach-O universal binary with 3 architectures
libarclite_universal.a (for architecture i386):current ar archive random library
libarclite_universal.a (for architecture armv6):current ar archive random library
libarclite_universal.a (for architecture armv7):current ar archive random library
Since this lib is linked statically, your final app wont grow because of the included sim library since only whatever is needed by your app will get linked into your final app.