How to set up C::B for Android NDK compiler?

[amarty]

I try to set up Code::Blocks with Mentor Graphics CodeSourcery ARM GCC - this works fine.
In the same manner I try to set up Code::Blocks for Android NDK ARM GCC and got an error:

"Project - debug" uses an invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!].
Probably the toolchain path within the compiler options is not setup correctly?! Skipping...

Summary information about my NDK installation:

NDK root        : D:\android-ndk-r8b
arm-linux-androideabi-g++.exe and others are in
                   : D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin
make.exe is in: D:\android-ndk-r8b\prebuilt\windows\bin\

My Code::Blocks setting is:

1) Compiler's installation directory (the 'bin' removed fom path)
     - D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows
2) Additional paths
     - D:\android-ndk-r8b\prebuilt\windows\bin
     - D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin

I try to set 1 and 2 in varios ways, but result is the same - error. I can't understand, is it my fail, or it is some bug or misconfiguration in C::B or NDK?

Can anybody help me?

[MortenMacFly]

arm-linux-androideabi-g++.exe and others are in

Did you name the compiler's executables names like that?

The algorithm is very simple:
C::B searches for all given tools (i.e. "g++.exe") in either the main or "bin" sub-folder and any additional provided folders.

So either the names of your tools are wrong, or the path's.

[amarty]

arm-linux-androideabi-g++.exe and others are in

Did you name the compiler's executables names like that?

Yes, compiler executables have such names. CodeSourcery Tollset compiler has name "arm-none-linux-gnueabi-g++.exe", but it works fine.

So either the names of your tools are wrong, or the path's.

I checked all names and paths more than ten times

[amarty]

 May be, the problem is that the NDK under Windows requires Cygwin or MSYS, and, when I compiling code in Eclipse, all paths seems like unix style path: windos path "D:\android-ndk-r8b\toolchains" looks like /d/android-ndk-r8b/toolchains. If it is true, my problem has no solution ;(

[Jenna]

Do you have a valid executable in the C-compiler field ?
If not you get this error, if I remember correctly.

If no C-compiler is available, you should additionally put the C++-compiler in the C-compiler field.

[dmoore]

We need to do something about that error message. Can't we do something like:

Code

Error: the tool chain [compiler|linker|other] command [was not set|'[command name or command line]' was not found], please check your tool chain settings in Settings -> Compiler

[MortenMacFly]

We need to do something about that error message.

Although we did quite some time in the past already, but: Yes (even before he release). Will you take the action?

[dmoore]

We need to do something about that error message.

Although we did quite some time in the past already, but: Yes (even before he release). Will you take the action?

I will take a look, but unless it is really simple it may take a bit of time for me to get a patch for. (The simplest thing would be to just sharpen the wording without trying to add the context)

[amarty]

Do you have a valid executable in the C-compiler field ?

Yes, all fields are properly filled

[MortenMacFly]

Yes, all fields are properly filled

You can use the cb_share_config tool, export the compiler settings in question and attach it to a post here, besides you PATH environment variable, and again the exact path where you installed your compiler into.

BTW:  I didn't even know there is a GCC for android... interesting... :-)

[amarty]

We need to do something about that error message.

It's a good idea.
First, it is not quite how works the "Autodetect" button - it simply reports that nothing is found and fills "Compiler install dir" with "C:\Program Files (x86)\GNUARM" value.
Next, The executable are under bin subdirectory of taken directory, but I can't understand, is path incorrect or something wrong then compiler tryed to run.
Third, what is strange restriction when binaries must be placed under "bin" subdirectory? I think, much better to point exact to directory which contains compiler executables.
Fourth, near all fields, near [...] button will be cool if one more button be placed, [AutoLocate] - pressing on it C::B looks for files in "compiler/install/dir/bin" with mack "*gcc", "*g++", "*ar", "*gdb" etc.

[dmoore]

Next, The executable are under bin subdirectory of taken directory, but I can't understand, is path incorrect or something wrong then compiler tryed to run.

Related: because the IsValid() check returns false, we get this "invalid" compiler message instead of attempting to run the toolchain command. It's bizarre that the check is only based on the C toolchain command and apparently not anything else.

@op: did you install the NDK while C::B is open? Sometimes I have found you need to close and reopen C::B for the environment to pick things up correctly. (This one is probably a stretch)

[amarty]

You can use the cb_share_config tool, export the compiler settings in question and attach it to a post here, besides you PATH environment variable, and again the exact path where you installed your compiler into.

NDK root: D:\android-ndk-r8b
Binaries are in: D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin
Path : c:\arc;C:\Program Files\ImageMagick-6.7.8-Q16;C:\Program Files (x86)PHP;C:Program Files (x86)IntelComposer XE 2011 SP1\redist\ia32\tbb\vc10;C:\Program Files (x86)IntelComposer XE 2011 SP1\redist\intel64\tbb\vc10;C:\Program Files (x86)IntelComposer XE 2011 SP1\redist\intel64\ipp;C:\Program Files (x86)IntelComposer XE 2011 SP1\redist\ia32\ipp;C:\Program Files (x86)IntelComposer XE 2011 SP1\redist\intel64\mkl;C:\Program Files (x86)IntelComposer XE 2011 SP1\redist\ia32\mkl;C:\Program Files (x86)Common Files\Microsoft Shared\VSA\10.0\VsaEnv;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\intel64\mpirt;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\ia32\mpirt;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\ia32\compiler;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)Common Files\Intel\Shared Libraries\redist\ia32\compiler;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;f:\usr\bin;c:\Program Files (x86)Microsoft SQL Server\90\Tools\binn\;C:\Program Files\7-Zip;C:\Program Files (x86)Microsoft Visual Studio 8\Team Tools\Performance Tools;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\Program Files (x86)Graphviz 2.28\bin;C:\Program Files (x86)Javajre7bin;C:Program Files (x86)Javajre7binclient;D:apache-antbin;D:android-sdkstools;D:MinGWbin;D:MinGWmsys1.0bin;D:necessitasAndroidQt482armeabibin;D:necessitasapache-ant-1.8.4bin;D:CMakebin;C:Program Files (x86)Subversionbin;C:Program Files\TortoiseSVN\bin

BTW:  I didn't even know there is a GCC for android... interesting... :-)

Android Native Development Kit - NDK

[MortenMacFly]

First, it is not quite how works the "Autodetect" button - it simply reports that nothing is found and fills "Compiler install dir" with "C:\Program Files (x86)\GNUARM" value.

This is by design. The folder is the default folder, where the compiler usually is installed, if you run its installer.

Next, The executable are under bin subdirectory of taken directory, but I can't understand, is path incorrect or something wrong then compiler tryed to run.

Well you can - what I told you is true: If you see this message, CodeBlocks cannot find the compiler computed by [list of path's] + compiler executable.

Third, what is strange restriction when binaries must be placed under "bin" subdirectory? I think, much better to point exact to directory which contains compiler executables.

Again, this is by design. Most compilers are setup in a way that they have a root folder, which has at least the sub-folders "bin" for the tool chain executables, an"include" folder for its includes and a "lib" folder for libraries. So having to setup the root path is just convenient to find all the rest. Otherwise it will become so complicated that out forum will be flooded with messages "I don't get the compiler to run" - trust me.

Fourth, near all fields, near [...] button will be cool if one more button be placed, [AutoLocate] - pressing on it C::B looks for files in "compiler/install/dir/bin" with mack "*gcc", "*g++", "*ar", "*gdb" etc.

Nope. We also support compilers like MSVC where you don't have such executables and even non c/c++ compiler (take Fortran, for example). Also, we support compilers that do not have such a standard folder structure. So your suggestion will break all these cases. the way it is now works for all of them and more.[/list]

[amarty]

@op: did you install the NDK while C::B is open? Sometimes I have found you need to close and reopen C::B for the environment to pick things up correctly. (This one is probably a stretch)

No, NDK installed some time ago, and some time I use Eclipse for development, but C::B is more nice IDE (I had the experience of using it before), and now I try to configure C::B for NDK.

[MortenMacFly]

[...]

Your compiler setup is wrong.

Accoridn to your config, you setup a wrong C toolchain executable. If your compiler does not have a GCC, setup the G++ here, too.

I just successfully configured NDK on my PC - so it definitely works with the right setup.

[MortenMacFly]

Related: because the IsValid() check returns false, we get this "invalid" compiler message instead of attempting to run the toolchain command. It's bizarre that the check is only based on the C toolchain command and apparently not anything else.

Well the reason for this is that i.e. for MSVC you might only have a C compiler and nothing else. So we don't want to have it overdone. the only exception I can think of is to check for if either the C or the C++ executable is present. But the rest we should leave. Remember that there might even be no "make", no "linker", no "resource compiler".

I think IsValid() should return an enumeration that helps to identify what the error is. Or (maybe a bit ugly) a wxString with the exact error description and wxEmptyString if all is OK.

[amarty]

Next, The executable are under bin subdirectory of taken directory, but I can't understand, is path incorrect or something wrong then compiler tryed to run.

Well you can - what I told you is true: If you see this message, CodeBlocks cannot find the compiler computed by [list of path's] + compiler executable.

But compiler exact under that path - I try to copy path, paste it to console, type "\bin\", copy and paste execuatable name, press enter - compiler launches.

Fourth, near all fields, near [...] button will be cool if one more button be placed, [AutoLocate] - pressing on it C::B looks for files in "compiler/install/dir/bin" with mack "*gcc", "*g++", "*ar", "*gdb" etc.

Nope. We also support compilers like MSVC where you don't have such executables and even non c/c++ compiler (take Fortran, for example). Also, we support compilers that do not have such a standard folder structure. So your suggestion will break all these cases. the way it is now works for all of them and more.[/list]

Yes, I understand this. I gave just one example of search mask for C/C++ toolset tools. Also, as I see, in that dialog only C/C++ toolsets can be configured.

[amarty]

I think IsValid() should return an enumeration that helps to identify what the error is. Or (maybe a bit ugly) a wxString with the exact error description and wxEmptyString if all is OK.

Yes, I told about something like your proposal too.

[amarty]

[...]

Your compiler setup is wrong.

Accoridn to your config, you setup a wrong C toolchain executable. If your compiler does not have a GCC, setup the G++ here, too.

Can you tell me, what is wrong, exact?
Configuring CodeSourcery toolchain in the same manner works fine, and it's executables also named as "arm-none-linux-gnueabi-*.exe".
Also, under Eclipse these executables working fine.
Next, I find another executables in NDK under the deeper path D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\arm-linux-androideabi\bin - they have short "standard" names - gcc.exe, g++.exe and so on, but configuring C::B with that path also reports error.

I just successfully configured NDK on my PC - so it definitely works with the right setup.

Hmm, I can't undestand, why I can't start it work.
My configuration is Win7 x64; C::B 8.05 with MinGW, 32 bit; 32bit NDK.

Can you export your C::B settings for NDK and attach it?

[MortenMacFly]

But compiler exact under that path - I try to copy path, paste it to console, type "\bin\", copy and paste execuatable name, press enter - compiler launches.

No. You setup "arm-linux-androideabi-gcc.exe" as C toolchain application. This file does not exist. Therefore, your compiler setup is wrong. Thats what the error message tells you.

(...or maybe I misunderstood. Is it working now?!)

[MortenMacFly]

My configuration is Win7 x64; C::B 8.05 with MinGW, 32 bit; 32bit NDK.

Oh dear - you mean 08/02? You really try to use an IDE that is so old that android did not even exist at that time?!

[amarty]

But compiler exact under that path - I try to copy path, paste it to console, type "\bin\", copy and paste execuatable name, press enter - compiler launches.

No. You setup "arm-linux-androideabi-gcc.exe" as C toolchain application. This file does not exist. Therefore, your compiler setup is wrong. Thats what the error message tells you.

(...or maybe I misunderstood. Is it working now?!)

This file exist in my NDK. List of files under "D:\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin"
arm-linux-androideabi-addr2line.exe
arm-linux-androideabi-ar.exe
arm-linux-androideabi-as.exe
"arm-linux-androideabi-c++.exe"
"arm-linux-androideabi-c++filt.exe"
arm-linux-androideabi-cpp.exe
"arm-linux-androideabi-g++.exe"
arm-linux-androideabi-gcc.exe
arm-linux-androideabi-gcc-4.4.3.exe
arm-linux-androideabi-gcov.exe
arm-linux-androideabi-gdb.exe
arm-linux-androideabi-gprof.exe
arm-linux-androideabi-ld.exe
arm-linux-androideabi-nm.exe
arm-linux-androideabi-objcopy.exe
arm-linux-androideabi-objdump.exe
arm-linux-androideabi-ranlib.exe
arm-linux-androideabi-readelf.exe
arm-linux-androideabi-run.exe
arm-linux-androideabi-size.exe
arm-linux-androideabi-strings.exe
arm-linux-androideabi-strip.exe

[MortenMacFly]

This file exist in my NDK.

Ok - but what shall I say? Even if I setup with this executable, it works for me. Maybe you should try a  nightly (or 12/11-RC1).

[amarty]

My configuration is Win7 x64; C::B 8.05 with MinGW, 32 bit; 32bit NDK.

Oh dear - you mean 08/02? You really try to use an IDE that is so old that android did not even exist at that time?!

Yes. I use only official releases, not nightly builds or release candidates. And, I'm lazy for installing MinGW separately, so I'm waiting for C::B 12.11.
And what the problem with old C::B? Executables still executables, GCC still GCC.

PS. Sorry, my C::B version is 10.05, 8.02 is my first used C::B version.


UPD Few days ago I'm looking for new C::B, and see news about 12.11-RC1, but can't find link to download this package.

[MortenMacFly]

...btw: You are not down the road once you made this work I can tell you - you'll need to do a lot low-level stuff in addition so it actually not only compiles, but also links.

My suggestion: Try at the command line first with the "hello world" project. Because you'll definitely need the platform flags, #defines and a lot more to setup your compiler correctly. Its easy if you see the command line one time so you are not stepping in the dark (...at least I found no good tutorial about it).

[amarty]

...btw: You are not down the road once you made this work I can tell you - you'll need to do a lot low-level stuff in addition so it actually not only compiles, but also links.

My suggestion: Try at the command line first with the "hello world" project. Because you'll definitely need the platform flags, #defines and a lot more to setup your compiler correctly. Its easy if you see the command line one time so you are not stepping in the dark (...at least I found no good tutorial about it).

Configuring compilers flags for android platfrom seems not hard for me - I can grab them from eclipse build logs, so, I think, this is next step after NDK compiler can run under C::B.  
Currently I'm really thinking about the work from the command line, but using C :: B would be much more convenient.

UPD Setting "C compiler" same as "C++ compiler" to g++ not solve the problem.

[MortenMacFly]

Configuring compilers flags for android platfrom seems not hard for me - I can grab them from eclipse build logs

Can you provide me with one here, so I can try, too?

Currently I'm really thinking about the work from the command line, but using C :: B would be much more convenient.

Sure, in the end it will be way more convenient - but I said that to get the command line - if you have the Eclipse way - do it like this.

UPD Setting "C compiler" same as "C++ compiler" to g++ not solve the problem.

Well that is weird. What you can try now: Use the EnvVar plugin and clean up your PATH environment variable. You have plenty of compilers in the path, so this may interfere.

Alternatively, just create yourself a batch file like this:

Code

set CB_ROOT=[...DO IT!...]
set WIN_ROOT=[...DO IT!...]

SET PATH=%WIN_ROOT%;%WIN_ROOT\sytem32;%CB_ROOT%
"%CB_ROOT%\codeblocks.exe" %*

...and run it.

[amarty]

Configuring compilers flags for android platfrom seems not hard for me - I can grab them from eclipse build logs

Can you provide me with one here, so I can try, too?

Code

**** Build of configuration Default for project GorgeousKarnaugh ****

bash D:\android-ndk-r8b\\ndk-build V=1 
Invalid attribute name: 
    package
rm -f ./libs/armeabi/lib*.so ./libs/armeabi-v7a/lib*.so ./libs/mips/lib*.so ./libs/x86/lib*.so
rm -f ./libs/armeabi/gdbserver ./libs/armeabi-v7a/gdbserver ./libs/mips/gdbserver ./libs/x86/gdbserver
rm -f ./libs/armeabi/gdb.setup ./libs/armeabi-v7a/gdb.setup ./libs/mips/gdb.setup ./libs/x86/gdb.setup
Compile++ arm    : GorgeousKarnaugh <= GorgeousKarnaugh.cpp
/d/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-g++ -MMD -MP -MF ./obj/local/armeabi/objs/GorgeousKarnaugh/GorgeousKarnaugh.o.d.org -fpic -ffunction-sections -funwind-tables -fstack-protector -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__  -march=armv5te -mtune=xscale -msoft-float -fno-exceptions -fno-rtti -O2 -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -I/d/agg-2.5/include -I/f/work/carno/include -I/d/android-ndk-r8b/sources/cxx-stl/gnu-libstdc++/4.6/include -I/d/android-ndk-r8b/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi/include -I/d/android-ndk-r8b/sources/cxx-stl/system/include -Ijni -DANDROID -Werror -Wa,--noexecstack   -O2 -DNDEBUG -g   -I/d/android-ndk-r8b/platforms/android-14/arch-arm/usr/include -c  jni/GorgeousKarnaugh.cpp -o ./obj/local/armeabi/objs/GorgeousKarnaugh/GorgeousKarnaugh.o && ./obj/convert-dependencies.sh ./obj/local/armeabi/objs/GorgeousKarnaugh/GorgeousKarnaugh.o.d
In file included from jni/GorgeousKarnaugh.cpp:2:0:
d:/android-ndk-r8b/platforms/android-14/arch-arm/usr/include/jni.h:592:13: note: the mangling of 'va_list' has changed in GCC 4.4
Compile arm    : GorgeousKarnaugh <= gkcstuff.c
/d/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/local/armeabi/objs/GorgeousKarnaugh/gkcstuff.o.d.org -fpic -ffunction-sections -funwind-tables -fstack-protector -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__  -march=armv5te -mtune=xscale -msoft-float -O2 -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -I/d/agg-2.5/include -I/f/work/carno/include -I/d/android-ndk-r8b/sources/cxx-stl/gnu-libstdc++/4.6/include -I/d/android-ndk-r8b/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi/include -I/d/android-ndk-r8b/sources/cxx-stl/system/include -Ijni -DANDROID -Werror -Wa,--noexecstack -O2 -DNDEBUG -g -I/d/android-ndk-r8b/platforms/android-14/arch-arm/usr/include -c  jni/gkcstuff.c -o ./obj/local/armeabi/objs/GorgeousKarnaugh/gkcstuff.o && ./obj/convert-dependencies.sh ./obj/local/armeabi/objs/GorgeousKarnaugh/gkcstuff.o.d
SharedLibrary  : libGorgeousKarnaugh.so

/d/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/
arm-linux-androideabi-g++ -Wl,-soname,libGorgeousKarnaugh.so 
-shared --sysroot=/d/android-ndk-r8b/platforms/android-14/arch-arm 
./obj/local/armeabi/objs/GorgeousKarnaugh/GorgeousKarnaugh.o ./obj/local/armeabi/objs/GorgeousKarnaugh/gkcstuff.o ./obj/local/armeabi/libstdc++.a   
-Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now 
-L/d/android-ndk-r8b/platforms/android-14/arch-arm/usr/lib 
-lstdc++ -lc -lm -o obj/local/armeabi/libGorgeousKarnaugh.so

Install        : libGorgeousKarnaugh.so => libs/armeabi/libGorgeousKarnaugh.so
mkdir -p ./libs/armeabi
install -p ./obj/local/armeabi/libGorgeousKarnaugh.so ./libs/armeabi/libGorgeousKarnaugh.so
/d/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded  ./libs/armeabi/libGorgeousKarnaugh.so

UPD Setting "C compiler" same as "C++ compiler" to g++ not solve the problem.

Well that is weird. What you can try now: Use the EnvVar plugin and clean up your PATH environment variable. You have plenty of compilers in the path, so this may interfere.

Alternatively, just create yourself a batch file like this:

Code

set CB_ROOT=C:\Program Files (x86)\CodeBlocks
set WIN_ROOT=C:\Windows
SET PATH=%WIN_ROOT%;%WIN_ROOT\system32;%CB_ROOT%
"%CB_ROOT%\codeblocks.exe" %*

Same result - error.

[dmoore]

Didnt we once have issues with mingw installed on d drive and C::B on c drive on win 7? Did you try putting everything on one drive?

[amarty]

Didnt we once have issues with mingw installed on d drive and C::B on c drive on win 7? Did you try putting everything on one drive?

One MinGW shipped with C::B, placed in C::B folder and works fine in C::B. Other MinGW on disk D installed for other reasons, and also fulfills its mission. I have no problems with MinGW in C::B, problem is with NDK

[stahta01]

Didnt we once have issues with mingw installed on d drive and C::B on c drive on win 7? Did you try putting everything on one drive?

IIRC, there was a version of MinGW that had the issue NOT CB itself.

Tim S.

[MortenMacFly]

I have no problems with MinGW in C::B, problem is with NDK

Well the only difference between me (where it works) and you is that  am using a recent build. So let me encourage you again to try 12/11-RC1. Since 10/05 we did change the way how compiler path's are handled.

[dmoore]

Have you tried setting the tool chain commands as a full path to the command?

Or how about setting a known executable that works just in the C tool chain (something located in a path that works such as your mingw) to get around the "invalid" compiler message, then compile a C++ file with the C++ tool chain command still set for the NDK as you have now and see what message you get.

[amarty]

I have no problems with MinGW in C::B, problem is with NDK

Well the only difference between me (where it works) and you is that  am using a recent build. So let me encourage you again to try 12/11-RC1. Since 10/05 we did change the way how compiler path's are handled.

Ok. Can you give the link to download this version of C::B? I can't find it on C::B site

[MortenMacFly]

Ok. Can you give the link to download this version of C::B? I can't find it on C::B site

Use BerliOS here:
http://developer.berlios.de/project/showfiles.php?group_id=5358

[amarty]

Ok. Can you give the link to download this version of C::B? I can't find it on C::B site

Use BerliOS here:
http://developer.berlios.de/project/showfiles.php?group_id=5358

Can I install new version over previous, or I need first to uninstall 10.05?

[stahta01]

You SHOULD use an empty folder to do the installation.

DO NOT INSTALL TO THE SAME FOLDER UNLESS CONTENTS WAS ALL DELETED.

Tim S.

[tdakic]

Has this issue been resolved?

I'd like to do the same - use C::B for Android NDK compiler.

Thanks,

Tamara

-----

You SHOULD use an empty folder to do the installation.

DO NOT INSTALL TO THE SAME FOLDER UNLESS CONTENTS WAS ALL DELETED.

Tim S.

[stahta01]

Has this issue been resolved?

I'd like to do the same - use C::B for Android NDK compiler.

Thanks,

Tamara

-----

You SHOULD use an empty folder to do the installation.

DO NOT INSTALL TO THE SAME FOLDER UNLESS CONTENTS WAS ALL DELETED.

Tim S.

Since my post was never an issue; but, directions. I would say your question makes no sense to me.

Edit: If you are asking do user still do user errors, the answer is yes.

Tim S.

[tdakic]

Oh, I just want to know if I anyone managed to use C::B with NDK. It seems that one user was trying and gave up? I think I know what I am doing and I am not afraid of compiling C::B from source, but would prefer to avoid large amounts of work.

Thanks,

Tamara

[stahta01]

Oh, I just want to know if I anyone managed to use C::B with NDK. It seems that one user was trying and gave up? I think I know what I am doing and I am not afraid of compiling C::B from source, but would prefer to avoid large amounts of work.

Thanks,

Tamara

That person likely do NOT know how to install a Compiler and then setup Code::Blocks to use it.

Tim S.

[empty head]

There appears to be a problem in Code::Blocks when setting up a new compiler for Android.

Having set up the new compiler and compiled the current project successfully, after exiting Code::Blocks and restarting it the project will no longer compile.

To get the project to compile again go to Settings->Compiler->Toolchain executables and set the compiler's installation directory to some other path and click OK. Then go to Settings->Compiler->Toolchain executables again and set the correct (*) compiler installation directory. Click OK. Now the project compiles successfully. However, the problem will occur again after exiting Code::Blocks and restarting it.

A permanent solution to the problem is to also set the compiler path in the the 'Additional Paths' section.
An example:
  In the 'Compiler's installation directory' put:
    E:\android-ndk-toolchain\arm-linux-androideabi (*)

  And in the 'Additional Paths' put:
    E:\android-ndk-toolchain\bin

* note: This is in fact not the correct location but one that Code::Blocks accepts.

[stahta01]

An example:
  In the 'Compiler's installation directory' put:
    E:\android-ndk-toolchain\arm-linux-androideabi (*)

  And in the 'Additional Paths' put:
    E:\android-ndk-toolchain\bin

* note: This is in fact not the correct location but one that Code::Blocks accepts.

What did you try as the correct value in 'Compiler's installation directory'?

Tim S.

[empty head]

An example:
  In the 'Compiler's installation directory' put:
    E:\android-ndk-toolchain\arm-linux-androideabi (*)

  And in the 'Additional Paths' put:
    E:\android-ndk-toolchain\bin

* note: This is in fact not the correct location but one that Code::Blocks accepts.

What did you try as the correct value in 'Compiler's installation directory'?

Tim S.

My Android toolchain bin directory is E:\android-ndk-toolchain\bin. So, for the compiler's installation directory I specify E:\android-ndk-toolchain. but this is not accepted by Code::Blocks.

It seems to me that the reason Code::Blocks likes E:\android-ndk-toolchain\arm-linux-androideabi for the directory is that there is also a bin folder in there which contains g++.exe but this is not the correct .exe. The correct .exe for Android is arm-linux-androideabi-g++.exe in E:\android-ndk-toolchain\bin.