We have been using Xcode 4 and LLVM 2.0 for a couple of months now and after finishing a huge update to our application we thought we would send it off to Apple.
What we couldn't imagine however, was that although the program was able to be built for both the simulator and devices, when it came to archiving, XCode just threw a nasty linking error and left us hanging there.
The error is related to the ZipKit library (we previously discussed the issues we had with making it work under XCode 4).
This is what we get:
ld: library not found for -ltouchzipkit
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang failed with exit code 1
So the question is: do we need to change any settings for an app that builds fine to be able to get archived as well?
Not trying to be flip, but it looks like the problem is that the linker can't find a library called "touchzipkit". The fact that this problem only comes up when you archive would seem to indicate your target has (at least one) build setting that has different values for "debug" and "release"... and that the "release" value is broken.
Not being familiar with ZipKit, I'm just shooting in the dark here. But I'd start checking out your build settings one by one, paying particular attention to library search paths and compiler flags where the debug and release settings are different.
Related
On its website OpenFlipper says it can be compiled in three steps as:
cd build
cmake ..
make # or, even better, make -j8
However I get an error saying Qt is unable to be found at the cmake step and that I should specify a QT5_INSTALL_PATH. However even if I do this OpenFlipper is still issuing the same complaint!
You are not supposed to specify where Qt is installed in the QT5_INSTALLED_DIR but prior to that as environment variable in your terminal:
# assuming Qt was installed in your home directory, as is default
export CMAKE_PREFIX_PATH=~/Qt5.7.0/5.7/gcc_64/
# note that you now have to call cmake etc from that process
Compiling and running it after that you might get errors telling you GL_ARB_vertex_buffer_object is not present, even if your glxinfo | grep ARB_vertex_buffer is telling you it is.* Clicking "Ignore" results in a crash. To mitigate this, you have to manually change (4,3) to (3,0) in
OpenFlipper/widgets/coreWidget/CoreWidget.cc
If you still experience errors, try deleting your cmake cache, this is accomplished by using cmake-gui (was in the package cmake-qt-gui for me) and hitting "Delete Cache"
(optional) remove the very annoying warning message you get at every start of OpenFlipper by removing the line concerning "renderers shipped" in
OpenFlipper/Core/Core.cc
*: My teaching assistant told me that there is a bug in Qt (<5.9) that forces OpenFlipper to use the OpenGL Compatibility Profile. Additionally Intel and AMD drivers hand back an OpenGL 3.0 Core Context when asked for an OpenGL 4.3 Compatibility Context (my TA described this behavior as a "bug", I'm not so sure about this), leading to a crash in Qt. So this should be resolved in Qt 5.9 (not out yet). This seems to affect also mainly integrated graphics, so one could try using a dedicated GPU.
I'm trying to set up pocl-0.11 on an ARM (llvm-3.3). I used ./configure --enable-debug --disable-icd --enable-testsuites=all (I'd like to get pocl to run without ICD loader as a first step).
During configure I got a couple of warnings about disabled tests due to missing glut, libDSL, boostlib, etc. Since the warnings 'only' concern some testsuites, I assume the configure is fine and I guess some basic tests will still be enabled!?
Furthermore I get the output:
checking LLC host CPU... cortex-a9
configure: using the ARM optimized kernel lib for the native device
<stdin>:1:19: error: 'test' declared as an array with a negative size
constant int test[sizeof(long)==8?1:-1]={1}; (Is that relevant? I don't really know what to do with this message.)
Eventually configure succeeds and make & make install run without any hint of a problem.
make check then fails all tests, even: check for pocl version FAILED (testsuite.at:29)
The 001/testsuite.log file indicates a linker problem!?
Do you have any idea?
Am I missing a configure flag or an environment variable? I didn't touch --prefix or any other paths.
LLVM 3.3 is quite old and its support will be dropped after the next pocl release. The configure error message you see probably means it fails to detect your CPU features correctly, but the testsuite error indicates that not all LLVM symbols are properly linked in. You can try fixing this by using a shared LLVM library, but I really suggest you to upgrade LLVM. The upcoming 3.7 should work now and has fixed several issues and includes better OpenCL C Clang support.
Typescript compilation task works fine on linux machines but on a mac fails with the following not particularly useful error message and what looks like a binary dump.
$ grunt
Running "ts:build" (ts) task
Compiling...
Fast compile will not work when --out is specified. Ignoring fast compilation
Using tsc v1.4.1
������������=��AF���=����
>> Error: tsc return code: 3
Warning: Task "ts:build" failed. Use --force to continue.
Aborted due to warnings.
Im using nvm with node v0.11.4 and rvm with ruby v2.2.0.
Any ideas how to fix this, or even debug?
As the question includes debugging, here are some pointers which might help determine where the problem is.
Try compiling from the command line with tsc alone (no grunt), in case the problem is with grunt or the ts:build task (looks like grunt-ts).
Maybe one of your source files is causing the tools to crash (perhaps they can't cope with a file's encoding?). If a single, simple file will compile, then try removing subsets of your source from the build. If some of those files are causing the crash (whether valid TypeScript or not) you may be able to find a temporary workaround.
Try compiling with different versions of tsc. If you need 1.4.1 features you could try using the latest from https://github.com/Microsoft/TypeScript (see here for how to do this with grunt-ts).
The problem was with a malfunctioning node installation. I upgraded to node 0.12 which fixed the problem.
Just to check the problem wasn't node 0.11.4 specific I removed all previous versions of node and reinstalled 0.11.4 and the error no longer occurs.
I took these steps after removing all node modules, clearing the cache and reinstalling with no luck. I also tried using multiple typescript compiler versions.
I've been working on a program called RoboJournal and I recently finished the 0.4.1 release. I'm currently in the process of packaging it for Fedora but for some reason the program won't compile on that OS. The exact same code builds fine on Windows and any Debian-based Linux (Debian itself, Ubuntu, Mint, et al). I had no problems packaging this for Debian. Here's the the compiler output error message (running on Fedora 18 KDE version):
/usr/bin/ld: dblogin.o: undefined reference to symbol 'XkbGetIndicatorState'
/usr/bin/ld: note: 'XkbGetIndicatorState' is defined in DSO /lib64/libX11.so.6 so try adding it to the linker command line
/lib64/libX11.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
The problem seems to be that the Linker can't find whatever is supposed to control the XkbGetIndicatorState signal (one of the X11 libs). This is used to determine whether caps lock is enabled while a certain dialog is active. Apparently, anything Debian-based includes this library out of the box while Fedora does not. I think this error is simply caused by a missing package but I'm not sure which one. Google gave me nothing useful. Any ideas?
Anyone who wants to test this for themselves can clone from git://github.com/pwizard2/robojournal.git. The app depends on the following packages (so far): qt, qt-assistant, qt-mysql, qt-devel, qt-webkit, qt-webkit-devel.
The problem is probably that you're not linking your program against libX11 so you need to add -lX11 to your link command and then everything will work.
The reason it works on some other linux distributions is that they allow symbols to be resolved using libraries that have only been pulled in indirectly - so if your program links against a library that is linked against libX11 then you will be able to call routines in libX11.
Fedora has not allowed this indirect linking (by default) for several years now (see UnderstandingDSOLinkChange) and several other distributions have also now followed suit.
I am using SQLite 3 for Database management in my ARM9 based microprocessor.
I want to cross compile the latest version of the SQLite 3 for my project in Linux (Ubuntu 10.04). I am using the arm-none-linux-gnueabi-gcc compiler for development.
I tried to cross compile using following commands,
Downloaded the sqlite-amalgamation-3.7.0.tar
I extract it and then write the following command on Terminal,
sudo ./configure --exec-prefix=/media/8CCC8E9BCC8E7F68/SQLIte3/sqliteinstall/ --host=arm --target=arm CC=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-gcc AR=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ar STRIP=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-strip RANLIB=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ranlib CFLAGS="-Os"
It successfully cross compiled the SQLite.
Then,
sudo make command.
It successfully run.
Now "make install " command.
It did not give me an error but when i went to the config.log file i found there is some sentences as following,
1.conftest.c:17:7: error: size of array 'off_t_is_large' is negative
2.conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
compilation terminated.
3.conftest.cpp:23:28: error: ac_nonexistent.h: No such file or directory
4.conftest.c:67:13: error: invalid type argument of unary '*' (have 'int')
I doubt that weather it has been cross compiled properly or not.
I can not understand.
I inserted the library on my board it works fine but the problem is that the speed got very slow. I think there is some problem that i have not set any flags for the GCC compiler.
I could not find any options.How I can set the particular flags for the GCC compiler so that unnecessary features can be omitted.
You probably shouldn't try to do cross-compilation manually. Instead, use an embedded Linux build system that will do that for you, and automate the cross-compilation process entirely. My favourite is of course Buildroot (http://buildroot.org), but there are plenty of others (with varying levels of quality, complexity and features) : OpenEmbedded, Yocto, PTXdist, etc.