I'm trying to convert a java library to objective-c using j2objc and include the generated objc files into my XCode project. I managed to generate the objc files, but XCode gives me the following error: https://i.stack.imgur.com/QX3zF.png
I used lipo -info on a .o file and I get this "architecture: x86_64". Does it mean those objc files are not meant to run on arm64 architectures and if so, how can I solve this ? Are there any flags I could use to generate the files for arm64 ?
A previous error I had was "ARC forbids explicit message" and I solved this by adding a compiler flag -fno-objc-arc to all the compile sources related to this error. Is this solution safe ?
To compile for arm64, the -arch arm64 and -isysroot IPHONE_SDK_DIRECTORY flags are needed. To find the IPHONE_SDK_DIRECTORY on your system, run xcrun -sdk iphoneos --show-sdk-path.
There's nothing J2ObjC-specific about this, they are normal iOS flags you'll find in you look at the log of a successful compile of an Objective C file in Xcode and click its right button to expand and show all the flags used.
J2ObjC by default does not generate ARC code, so the -fno-objc-arc flag is okay. If you would prefer ARC, run j2objc with its -use-arc flag. Don't compile those generated files with -fno-objc-arc, however, as objects won't be released when your app is finished with them.
Related
I downloaded Codeblocks bundled with GCC from here
The C part is running fine
I read this wiki tutorial which says having GCC will allow me to compile objective C by just adding -lobjc to the compiler options
However, I have followed the steps mentioned in this tutorial and added the -lobjc option, but it doesn't compile
This is the build error message I get in codeblocks:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o
mingw32-gcc.exe: error: CreateProcess: No such file or directory
Process terminated with status 1 (0 minute(s), 2 second(s))
1 error(s), 0 warning(s) (0 minute(s), 2 second(s))
As shown above, it does not show the -lobjc option
I have also tried manually compiling the above program in Windows cmd by going into the folder containing the .m file. I gave the following command:
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
But I get the same error in cmd
mingw32-gcc.exe: error: CreateProcess: No such file or directory
I also tried
gcc -g -fgnu-runtime -O -c some_class.m
that I got from here, but it gives me the same CreateProcess error. How do I start compiling Objective C code in Windows (preferably using GCC and Codeblocks) ?
--- EDIT 1 ---
I did as suggested in Mike Kinghan's answer below, and uninstalled my older Codeblocks instgallation, then reinstalled MinGW and codeblocks separately. The Codeblocks uninstall removed the Codeblocks folder in Program Files, but when I reinstalled Codeblocks again (version without MinGW bundled together), the "GNU GCC Obj-C" settings I made with the previous installation was still there, along with the -lobjc flag in the "linker settings" tab.
However, the problem is that it's still not working. I get the following error if I try to build from Codeblocks
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Obj-C Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\Program Files\CodeBlocks\MinGW/bin/mingw32-gcc.exe', but failed!
Skipping... Nothing to be done (all items are up-to-date).
This is what Toolchains executable looks like:
If I try to compile it from cmd by going in to the folder with the .m file and issuing the command
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
it gives the error
mingw32-gcc.exe: error: CreateProcess: No such file or directory
What is the problem here?
--- EDIT 2 ---
Following the suggestion in Mike Kinghan's answer I deleted the old instance of "GNU GCC Obj-C Compiler" in the list of compiliers, and recreated with the current version of "GNU GCC Compiler"
However, the program still does not work. This is the message I get in the build log:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
Linking stage skipped (build target has no object files to link)
Nothing to be done (all items are up-to-date).
Cleaning the project and then building it again gives the same message. Trying to run the project anyway gives me a dialog box saying the project is not built, and clicking on Yes to build the project just pops the same "project not built yet" dialog box up again. The file icons in the Workspace tree of the Projects tab also seem to be grayed out:
This is what Toolchain Executable looks like:
I have added -lobjc in Linker Settings as mentioned here as well.
I right clicked the project icon in the Project tree, went to Build Options and added -lobjc in the Linker Settings as well:
What is the problem with this project at the moment?
--- EDIT 3 ---
I ended up completely uninstalling Codeblocks (uninstall from windows start menu, delete codeblocks folder in %APPDATA%), uninstalling MinGW (deleting the c:\MinGW folder) and reinstalling everything from scratch. I followed all the instructions in the Wiki (except the Troubleshooting section, but I think that part is irrelevant) and it still doesn't work (same problem as described in Edit 2 in this post).
How do I get Codeblocks to detect and compile obj-C code? Also, it is not showing me the compiler command line arguments when I try to build it from the Codeblocks interface. Why is this and how can I get it to show me whatever the full command line it is using?
The GCC program we loosely call the "the compiler" - [mingw32-](gcc|g++) -
is actually a compiler/linker frontend that invokes a real language
compiler and/or linker depending on what the input files and commandline options
indicate you want it to do.
Input files with an .m extension indicate they are Objective C source files
that are to be compiled with the GNU Objective C compiler, cc1obj. But you
haven't got it. Hence the failure you see.
A GCC installation will include the C compiler cc1 and, optionally, compilers
for other languages - C++, Fortran, Objective (C|C++), Go ... You say you got your MinGW GCC installation as
bundled with Code::Blocks. That bundled MinGW omits the Objective C compiler, cc1obj , because the maintainers
reckon it a niche language.
Best remove your CB installation and bundled MinGW and then install MinGW GCC independently from
one of the rival projects:-
https://sourceforge.net/projects/mingw-w64/
https://sourceforge.net/projects/mingw/
Run the installer and ensure that you get Objective C as well as any other compilers you
want.
After that, replace your CB installation it with the codeblocks-17.12-setup.exe installer (not codeblocks-17.12mingw-setup.exe),
from https://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/. This installer includes no compilers and
will auto-detect your MinGW installation.
Then proceed as you already did to create a GNU GCC Obj-C compiler setup in the CB IDE.
Later ... still not working
Your GNU GCC Obj-C compiler-setup has persisted from your previous
CB install and has been rendered out-of-date by the fact that your
new MinGW installation is no longer part of Code::Blocks. As you see,
it still looks for the toolchain executables in C:\Program Files\Codeblocks\MinGW,
whereas your new MinGW is somewhere else.
When you reinstalled Code::Blocks you should have seen its attempt to auto-detect compilers,
and that it detected your MinGW toolchain in (say) C:\MinGW. It will have configured
a compiler setup for GNU GCC Compiler on that basis, with the correct path to
the toolchain executables. But it will not have modified any persisting compiler setups that
you created yourself, such as GNU GCC Obj-C.
First check that the auto-detected setup GNU GCC Compiler is good just
by creating a "Hello world" C console project and seeing that you can build it.
I assume you'll be able to, but if not, then go into the GNU GCC Compiler setup
yourself and manually set the Compiler's installation directory correctly.
Then, set the same Compiler's installation directory for your GNU GCC Obj-C
compiler setup.
I am trying to compile a project for iOS 6 in XCode, and I am using the following headers, which include the functionality I need:
#include "cdjpeg.h" /* Common decls for cjpeg/djpeg applications */
#include "transupp.h" /* Support routines for jpegtran */
Those are straight out of jpegtran utility sources. I have installed the jpeg library before, and there is libjpeg.a in my /usr/local/lib/.
However when I try to compile, I am getting an error "Undefined symbols for architecture i386" or "Undefined symbols for architecture armv7", depending on whether target is an iPhone simulator or not.
Here are the keywords it can't find symbols for:
"_jpeg_stdio_src"
"_jpeg_finish_compress"
"_jcopy_markers_execute"
"_jpeg_copy_critical_parameters"
"_jtransform_adjust_parameters"
"_jpeg_destroy_compress"
"_jtransform_execute_transform"
"_jpeg_finish_decompress"
"_jpeg_read_header"
"_jtransform_request_workspace"
"_jpeg_write_coefficients"
"_jpeg_read_coefficients"
"_jpeg_destroy_decompress"
"_jpeg_stdio_dest"
"_jcopy_markers_setup"
I have encountered the missing symbol errors before, and always ended giving up on using 3rd party libraries, but in that particular case there's no way around.
What am I doing wrong here?
EDIT: I have added libjpeg.a to project settings and it did go further, but stopped now at:
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: i386-apple-darwin12.2.0
Thread model: posix
"lots-of-debug-paths"
ld: library not found for -ljpeg
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I recently needed libjpeg for iOS too (as a dependency of another third party library)
I ended up simply using the libjpeg-turbo, which comes with a precompiled fat binary
Architectures in the fat file: libjpeg.dylib are: i386 x86_64 armv6 armv7 armv7s arm64
I dunno how you compiled it. But you need to change the make install in order to compile it in i386 and armv7. I'm pretty sure you just run the make, so it compiled it for you mac, which is certainly a x84_64 arch, and this is certainly not what you want
You can check with
lipo -info /usr/local/lib/libjpeg.a // if libjpeg.a is at this path
or
file /usr/local/lib/libjpeg.a
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.
When compiling Objective-C from the command line (gcc), what are some good flags to use? Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C.
I currently just use -lobjc and -frameworkwith various frameworks.
Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C
-Wall works perfectly fine with Objective-C.
The thing to do is build an Objective-C file with Xcode and have a look at the build transcript. I've just done that and here are some highlights:
-x objective-c I guess that means "compile as Objective-C", probably important
-arch x86_64 build for a particular CPU architecture
-std=gnu99 build for C99 + GNU extensions (actually surprised me, I thought Xcode used -std=c99).
-isysroot .... specifies the location of the SDK.
-mmacosx-version-min=10.6 I am compiling for 10.6 and up
-fobjc-gc-only this file was intended to be used with garbage collection and won't work without it, so I compile for GC only.
-Wall the obvious.
If you are compiling from the command line, it's probably a good idea to set the option to treat warnings as errors. I don't from within Xcode because the build results window remembers the uncleared warnings from previous builds.