Xcode Linker Issue - Other LD Flags won't clear - xcode

I am a noob and am having an issue with linker flags.
I tried building my own ssh2 libraries, and then afterwards I cloned a git repository with a project in the libraries already built.
Before I downloaded the compiled binaries, I was building with gcrypt and added the -lgrcrypt library to the other linker flags.
With this new library set that I am using, I no longer require gycrpt and so I removed the linker flags. However that did not clear the linker options. I am still getting all of the old linker flags in spite of clearing them in the project properties.
The error shows that the -lgrypt is still being processed as a linker flag:
-no_implicit_dylibs -mios-simulator-version-min=6.0 -lgcrypt
How can I reset the linker flags to what they were?
Thanks in advance

well i presume you have checked the flags and removed the path for that lib in your target level of the project, and also have clean the build and removed the previouse builds from organizer and inside xcode, and also have reset your simulator, and also have checked the project folder on your computer and removed that lib from the library folder of the project. these are the necessary steps and if you have done all of these then i cant think of anything else other than port your code to a new project and try to compile again. good luck my friend.

Related

Where are Linker Flags in External C Library?

I have a C library which I need to use in my ongoing Xcode project. I used Cmake to build and install that Library. I gave the paths to Headers files and I can include the files into my Xcode project. However, when I run the project it says:
linker command failed with exit code 1 (use -v to see invocation)
I suspect that problem is with Linker Flags. I haven't included any Linker Flags and I don't know which flags do I need to add. Please tell me where in the library would I get all the required Linker Flags.
git hub link of the library which I want to add:
https://github.com/cbalint13/pba
From xcode left side window.
Under Project Navigator, click on your project, click on build settings.
Select "All" and "Combined" sections, then search for "Linker Flag"
Don't forget to switch to your target's build settings as well. As you might change just the "Project", not the "Target".

Building libraries that have ExternalProjects Added using CMake and Xcode

I am trying to use CMake to build a library (which in turn links to other libraries built via CMake). I am having a couple of issues with this process and would love to have some guidance.
For the library, I have a CMakeLists.txt which essentially has
set(SRC srcfile1.cpp srcfile2.cpp)
set(HEADERS srcfile1.h srcfile2.h)
add_library(myLib ${SRC} ${HEADERS})
INSTALL(FILES ${HEADERS} DESTINATION “include/myLib”)
For a “Unix Makefiles” generator, with cmake command
cmake -DCMAKE_INSTALL_PREFIX=. -DCMAKE_BUILD_TYPE=debug -G “Unix Makefiles” ..
I get an appropriate debug library libMyLib.a in build/src. For a release build type, a release build of libMyLib.a is placed in build/src
However, for an Xcode generator, the library is placed in src/Debug. The issues I am facing here are
a. Doing an Archive in Xcode doesn’t seem to have any effect. I don’t see a corresponding Release library being created anywhere
b. I also have a myLibTests target (which uses googles gtest) which is defined in it’s CMakeLists.txt as
set(SRC myTest.cpp)
add_executable(myLibTests ${SRC})
add_dependencies(myLibTests myLib gtest)
set(gTestLib External/src/gTestLib)
target_link_libraries(myLibTests myLib gTestLib)
When the cmake generator is “Unix Makefiles” myLibTests build, links and runs fine. gTestLib is placed in External/src/gtest-build/. But, when it is “Xcode”, it can’t find the gTest libraries. because, the library is placed in External/src/gTestLib/Debug(or Release) as the case may be (and the above path set in CMakeLists.txt is no longer valid). I am not sure how to set it’s path appropriately in the above set statement.
Since, debug/release is controlled in Xcode (and the configure process in CMake is unaware of this), I assume there isn’t a way to separate the release/debug builds of the gTestLib and also have CMake configure Xcode to pick up the appropriate version while building myLib i.e if I do a debug build of myLib it also does a debug build of gTest and links to it (similar for release builds)? Alternatively, is it possible to configure Xcode to place both the Debug and Release builds in the same location (and then hardcode it’s path above)? What would be the best way of configuring this?
Thanks

Cross compiling for arm using crystax NDK

The android ndk supplied by google is unable to compile call to c++11 functions such as std::to_string() and std::stoul etc. {I had tried it in r10b one from the official site}. So the suggestion in SO was to try crystax NDK. I have downloaded and placed the root folder next to the google's NDK. All I changed in my root CMakeLists.txt file was:
from:
set(PLATFORM_PREFIX "/some-path/android-ndk-r10b/platforms/android-19/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
To:
set(PLATFORM_PREFIX "/some-path/android-ndk-r8-crystax-1/platforms/android-14/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
and cmake command-line from:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r10b
To:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r8-crystax-1
ie., changed from normal ndk to crystax-ndk. The program was compiling fine previously till it tried to compile a file with call to std::to_string() etc. But after the change Cmake gives an error that it is unable to compile a simple test program because:
/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -lcrystax
I can see libcrystax.a and .so in directorie:
/some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a
I tried adding link_directories("path-to-above") right at the beginning of the CMakeLists.txt file too, but that didn't solve it either.
It should find it there (after i supply the --sysroot etc above) just like the normal ndk. So how should this be solved ? Any other cmake variable to be set or something ?
I don't know how your cmake-based build system works, but actually if you properly add path /some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a to linker search paths, it should find libcrystax and link with it successfully.
Please note that NDK have several parts separated each from other - i.e. sysroot, libcrystax, C++ library - all are separated. It is done to work with NDK build system which offer some flexibility choosing C++ standard library implementation, and NDK build system know where to find all of them. In your case this approach is not so good so I suggest you first make standalone toolchain, which contains all things assembled together. In other words, it would be classic cross-compile toolchain which contains sysroot, libcrystax and GNU C++ standard library in places known to compiler/linker without passing of any additional options.
To create such toolchain, cd to NDK root directory and run the following command:
./build/tools/make-standalone-toolchain.sh --system=linux-x86_64 --toolchain=arm-linux-androideabi-4.7 --platform=android-14 --install-dir=$HOME/arm-linux-androideabi
Then use $HOME/arm-linux-androideabi as full standalone toolchain for your cmake-based build system.
Please note, however, that application built with CrystaX NDK r8 will not run on newest Android 5.0 due to changes in Bionic (libc). Previous Android versions (<=4.4) are all fine. We fixed that issue (and many others) in upcoming r10 release which is on final testing stage. In the meantime you could adopt your project to our r8 release and quickly switch to r10 when it done - the same approach will work with r10 as well as with r8.

code::blocks linking doesn't work for lib files

I just had a fresh new version of Code::Blocks(12.11) and tried to make a glut example project, but the generated code has some linking issues.
The minGW settings are is set to the correct values, since I successfully linked ad compiled a glfw project from *.a files. My problem is the linker just can't handle .lib files for some reason. I always get undefined reference errors, despite of the linking of the correct libraries.
I just don't know what to do/link...
How can I link *.lib files in the new Code::blocks?
IF I cannot, are there any glut binaries in the format of *.a files, or should I build it myself?
Finally I found this link, used this package, and did a clean build(rebuild) of the project, instead of Build. Works like a charm!

Bundling dylibs, headerpad_max_install_names not working

I have another OSX application problem. I want to bundle in my final application several dylibs, all of them needed by the application and by other dylibs.
I change its references using the install_name_tool, but some of the libraries couldn't be changed properly, having this error:
install_name_tool: changing install names or rpaths can't be redone for: aLibrary.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
So I added the headerpad_max_install_names option flag on the linker flags of the xcode project (Project Properties-Build Settings-Linking-Other Linker Flags). Also I verified in the build log, if the option flag was included, and the option flag was included properly.
But still having the same error in the last dylibs.
Is there any way to bundle all the libraries needed in a unique Framework? Or am I doing something wrong in the building process?
Hope I'm clear with the main problem.
Thanks!
I had this same problem, using C++ and Code::Blocks, and I fixed it by switching from g++ to clang++

Resources