Related
Hi,
when I compile android (using instructions from source.android.com/download) it does not compile some source files. For example there is external/bluetooth/bluez/sbc/sbc.c which is not compiled. There are also other such files.
It's possible those files need not to be compiled. Or it might be that I need some special configuration to compile them.
Either way, if it is possible, I'd like to compile them all. Is there some way to do it? Maybe some "compile_all" make target? Some additional options that need to be set?
(I believe the reason why I want to compile all source files is not important)
Hi ,
enter to the build directory and do
1) " . envsetup.sh " ( you can read this file to get informations about building )
2) after return to the top of directory and make just " m "
tell me what happened
regards
Hi,
I've download the Android source with "repo", and it includes cross compiler toolchains for various architectures.
I want to build a package (for now, mtd-utils) for my android phone (a htc hero), but I'm having limited success understanding how to get this working. I was thinking there was something I could do, like change my $PATH and set up some other environment variables, that would use the tools from the toolchain instead of the system default ones, so that the binaries would be built for the phone instead of for my computer. But it certainly doesn't seem to be that easy...
I've reverted to attempting a "Hello world" program, but when I try to compile even that using the included toolchain tools, I run into trouble:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -o hello hello.c
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:5: warning: incompatible implicit declaration of built-in function 'printf'
so I tried a couple of other variants:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/bionic/libc/include -o hello hello.c
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/ndk/build/platforms/android-8/arch-x86/usr/include/ -o hello hello.c
but they both give (different) errors about what other include files are missing when referenced from somewhere.
Is there some "easy" way to android-ify a source tree, so that I can build sources using the cross compiler toolchains? Or should I fetch a different cross compiler toolchain to use, like benno did in his document from 2007? He uses a codesourcery toolchain and builds with that instead (as referenced in other articles here on the subject).
Would much appreciate any shared tips or experiences on how to accomplish this.
The tool chain is fine the problem is non of the include/lib are set up correctly to find the needed version of the includes. Remember the default includes under linux depend on glibc and android only supplies bionic.
Have a look here for more info on setting up bionic:
http://android-dls.com/wiki/index.php?title=Compiling_for_Android
Though if you get the full source for glibc (or precompiled arm binaries) you could compile a dependant program staticly (I think that's what busybox does)
Building for older versions of Android
I was actually able to compile a program manually today, specifically one of the programs in the mtd-utils package. After lots of jumping back and forth, I have found out that the 64 bit version of Ubuntu is what I needed, and also sun-java-1.6, contrary to almost all information I found out there. Then I was able to build AOSP, and then I was able to get "agcc" working, the wrapper that sets environment variables automatically as needed.
So I compiled the app, but it didn't work on my Android. Trying to run it in an adb shell gave approximately this error (from memory):
/bin/sh: ./program: No such file or directory
though the program was there. I didn't use strace, but concluded that this is because of a missing shared library. I have a very recent version of AOSP, while the phone is running Android 2.0 or something like that, so that's a plausable reason why this is happening.
I tried to rebuild the program using "agcc -static ...", but that doesn't work because I don't have the static version of libc after building AOSP, so it just dies with a linker error complaining that it can't find -lc.
So now I need to figure out how to build for old Android version using my checked out version of AOSP, or I need to figure out how to check out an old version of AOSP using repo.
Any tips would be much appreciated.
Greetings everyone...
As you might know: I'm the tech freak guy who compiled the GlibC and some Linux applications for HTC Desire.
As I have published my findings, I've recieved messages about how I'm compiling the applications given the source code. I try to help about this, but sadly I think half of what I say is not understandable without a proper guide. Ergo, this thread will suply this!
When?
Well, soon; because I'm still preparing it.
What will it include?
It'll be a basic guide about how to compile applications with your toolchain (Here is the guide about how to make a toolchain of yourself: How to make a toolchain). I'm planning to show it with GlibC compilation.
What's the extend of this help?
Frankly, compiling from the source sometimes can be quite messy and most of the time, a compilation/configuration line is never same with different applications. However, since most sources come with either Autotools or with a Makefile, most of the times, all you need is to change a few command line variable with a proper value.
I'm not planning to show you the code changes or "patchworks" they might be necessary, because this is quite application specific thing and I'm not an expert about this either. I'm just going to show you a guide about the compilation process.
What's the catch / scum of this help?
There is no catch in it. I just want to help curious nerdy guys like me )), so that we can learn from each other; or maybe improve each others work! I learned a lot from guys here, and I want to help to this community as much as I can as well.
Compilation Guide from Source code
Well, let's begin
We're going to compile the GlibC, with all internals to make it ready. After you prepare this, you might also check DoomLord's post here (http://forum.xda-developers.com/showthread.php?t=1041064) to make a recovery zip to flash this to your device. Make yourself comfortable now; because I'm going to explain everything we use here, thus this might be loong guide
1- Obtain the Sources
First, obtain the sources that you're going to compile. Check all the dependencies of the package and download them (and compile them) before. In our case, since we'll compile GlibC and all it needs is a working toolchain; we don't need to worry about this.
You can obtain GlibC source code from http://ftp.gnu.org/gnu/glibc/ address. Note that, since we're building GlibC for ARM devices and since GlibC seperated ARM support to "Ports" package, we need to download that as well. Make sure you download the same versions of Glibc and Glibc-Ports packages.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
2- Extract the Sources, and make a build directory
Extract the sources to some folder; say /home/<user>/Desktop/glibc . Also extract the glibc-ports package to some direcorty, say /home/<user>/Desktop/glibc-ports.
After this, rename the folder "glibc-ports" to just "ports" and then move it inside to the "glibc" folder. If you don't do this step, you'll have "ARM is unsupported" error in configuration step.
Since glibc cannot be compiled from the directory which sources are in it (a restriction made by the developers, to make sources unchanged and ready to be compiled again), we need to make another folder from which we're going to call the compilation tools. Let's say this directory is named as "glibc-build", also at /home/<user>/Desktop .
3- Start "configure"
Now, open a terminal emulator window ( you can use Ctrl+Alt+T keys under Ubuntu to easily open one ). Change into the glibc-build directory.
Code:
cd /home/<user>/Desktop/glibc-build
After this operation, we've to call the glibc's auto-configure script from this folder. Note that ".." is a "special folder name" which denotes the upper level directory (so basicly, we're changing into the upper level in directory tree - Desktop in our case - and then call something from a folder inside that)
Code:
../glibc-2.14/configure --help
When you run the above command, configure will give you the options you can use to configure this package for your needs. Nearly 90% of the time, checking the output of this command gives you the options you need to set to compile properly.
Code:
`configure' configures GNU C Library (see version.h) to adapt to many kinds of systems.
Usage: ../glibc-2.14/configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking ...' messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..']
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/c-library]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--disable-sanity-checks really do not use threads (should not be used except
in special situations) [default=yes]
--enable-check-abi do "make check-abi" in "make check" (no/warn/yes)
[default=no]
--enable-shared build shared library [default=yes if GNU ld & ELF]
--enable-profile build profiled library [default=no]
--enable-omitfp build undebuggable optimized library [default=no]
--enable-bounded build with runtime bounds checking [default=no]
--disable-versioning do not include versioning information in the library
objects [default=yes if supported]
--enable-oldest-abi=ABI configure the oldest ABI supported [e.g. 2.2]
[default=glibc default]
--enable-stackguard-randomization
initialize __stack_chk_guard canary with a random
number at program start
--enable-add-ons[=DIRS...]
configure and build add-ons in DIR1,DIR2,... search
for add-ons if no parameter given
--disable-hidden-plt do not hide internal function calls to avoid PLT
--enable-bind-now disable lazy relocations in DSOs
--enable-static-nss build static NSS modules [default=no]
--disable-force-install don't force installation of files from this package,
even if they are older than the installed files
--enable-kernel=VERSION compile for compatibility with kernel not older than
VERSION
--enable-all-warnings enable all useful warnings gcc can issue
--enable-multi-arch enable single DSO with optimizations for multiple
architectures
--enable-experimental-malloc
enable experimental malloc features
--enable-nss-crypt enable libcrypt to use nss
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-gd=DIR find libgd include dir and library with prefix DIR
--with-gd-include=DIR find libgd include files in DIR
--with-gd-lib=DIR find libgd library files in DIR
--with-fp if using floating-point hardware [default=yes]
--with-binutils=PATH specify location of binutils (as and ld)
--with-elf if using the ELF object format
--with-selinux if building with SELinux support
--with-xcoff if using the XCOFF object format
--without-cvs if CVS should not be used
--with-headers=PATH location of system headers to use (for example
/usr/src/linux/include) [default=compiler default]
--with-tls enable support for TLS
--without-__thread do not use TLS features even when supporting them
--with-cpu=CPU select code for CPU variant
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
CXX C++ compiler command
CXXFLAGS C++ compiler flags
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
Report bugs to <glibc>.
GNU C Library home page: <http://www.gnu.org/software/c-library/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
The help is quite straightforward, and all explanations are already done. The most important options for our case here is "prefix" and "host". Also, for compilation of GlibC, we need to give "with-headers", "with-tls" and "with-ports" proper values.
"Prefix" is a very important option. This options specifies where the installed binaries and libraries "think" they are. Some binaries and libs. are quite flexible: they don't care about where they are, thus the value of prefix isn't much of importance, but most of the time, it is. Omitting a prefix value here will make PREFIX value of "/usr/local" - which is quite dangerous because it may screw your own system (/usr/local is usually where your own PC applications are - most probably you cannot screw this folder if you're not a super-user but, well, anyway...); so always change this value to something proper when you're cross compiling.
Also, make sure that this path exists in your target device. If you set a prefix, say /cache, and then copy the stuff at, say, /data; it's highly probable that your applications will search for it's config files at /cache, and will complain that they are not found - since they're at /data. Since AFAIK, there is no way to change this in most application after compilation of software, you have to recompile the program to fix such errors (or move the application to the prefix it's set).
I usually use /data as prefix, because I install the stuff to there.
Host is another very important option. If you don't give this parameter, auto-configure will think you're compiling this application for the PC you're using. We've to give "host" the machine specification we're compiling the app for. For ARM based devices, this is mostly something line "arm-xxx-linux" or "arm-linux" or "arm-xxxx-linux-gnueabi" or such.
How do you found this out? Well, simple: If you followed my crostool-ng tutorial and used the same options as I did; your host name will be in "arm-xxxxxx-linux-gnueabi" format. "xxxxx" here is what your vendor name is. If you set a vendor value when making the toolchain, you must write it here. If you left it empty, xxxxx will be "unknown".
The other way to check this is your toolchain's name of gcc command: If your ARM GCC toolchain name is "arm-myvendor-linux-gnueabi-gcc" then, your host name is "arm-myvendor-linux-gnueabi".
Most of the times, there are other options that you must give. As for an example, here is what I generally use to compile glibC:
Code:
../glibc-2.14/configure --host=arm-msm-linux-gnueabi --prefix=/data --with-tls --with-ports="nptl, ports"
I use host as "arm-msm-linux-gnueabi" because this is my cross compile target name.
We set "with-tls" option here: it's for GlibC to support Thread Local Storage. This is a programming scheme that allows threads to have their own storage area; and we give this configuration here to give GlibC a support for this. More info about TLS can be found online in programming wiki's.
We also set "with-ports" because we're also installing some extra plugins for our GlibC install. NPTL is an advanced threading library that supports many advanced features like TLS and such. There is also a "linuxthreads" but it's older. New versions of GlibC is not shipped with "linuxthreads" either. The other port, "ports" is for ARM support.
You must also give the kernel source directory here with a parameter of "with-headers" if you're using some other toolchain and your kernel sources are in some other place. Thanks to crostool-ng that it moves all the headers to the toolchain folder and makes them automatically reachable, so you can omit this parameter.
Well, when you give the command and supply the options and press ENTER, it shall start configuring the package:
When there is a missing dependency or option, it shall generally give you a warning at this step and terminate the configuration. You must then find the solution of this error (install the necessary dependency etc.) and then try to configure the package again - as I said, this is usually not the case for GlibC .
3- Start "make"
After configuration process is done without errors, you can pass to the compilation phase. If you did configuration properly, you don't have to use special parameters and such for most packages. Just issue the command "make" and wait
Code:
make
Once this is completed without errors, you're nearly ready for the shipment Note that, if you get any errors in this process, you should definitely google it; since errors in this level is quite application and build environment (your machines configs. etc.) specific. The errors in this phase is usually needs some tricks to fix, and they are usually not so easy to fix
3- Start "make install"
Once the compilation is successful, you can install the application to the "PREFIX" folder you specified whilst configuring the package. In order to do that, just issue:
Code:
make install
However, issuing just this command isn't what we want generally: Since we've cross compiled the application, we're not interested in installing that to our PC! We want it to be somewhere we can easily access, so that we can distribute easily right?
For most packages, three important variables are necessary to make this. Which variable is heeded is highly dependent of package, however it's DESTDIR usually used.
DESTDIR: The variable usually used in makefiles. When you set DESTDIR while giving "make install", the application becomes installed to DESTDIR/PREFIX folder, instead of just PREFIX folder without changing the prefix info inside the application so it makes it easier for us to distribute the package.
install_root : GlibC uses this variable, instead of DESTDIR. I didn't see any other packages using this.
INSTALL_TOP: OpenSSL and Lua packages use this variable instead of DESTDIR.
Which of these variable is used cannot be identified either without examining the Makefile, or without testing it
How are you going to give it a value? Simple: you just assign the variable a value, after giving "make install" command:
Code:
make install DESTDIR=/home/<user>/myapp
For GlibC, this becomes:
Code:
make install install_root=/home/<user>/glibc
Which makes glibc installed to /home/<user>/glibc folder.
You can take the files from this folder and make a flashable zip; and send it to your device!
5- NOTES
- Be careful about the PREFIX value, you should install the files to this place in your device as well.
- Most of the times, you don't need the "include" folder - this folder keeps the header files for your packages, so that other applications may be compiled with them. Since we're not compiling applications in our device, we don't need headers. Compiled applications don't use headers anymore.
- Most of the times, .a files under the "lib" folder is unnecessary - these are static libraries that are usually used when applications are being compiled. Since we don't compile stuff at our device, we don't need them - they are usually quite big too! Be careful though: some packages don't offer .so files (which are dynamic libraries for applications to use dynamically) - it might be necessary to keep .a files then.
- .la files are needed for application compilation with libraries, you can erase them as well.
- pkgconfig can be erased in distribution packages. PKGConfig is a tool for compilation that automatically parses the files in pkgconfig dirs to give necessary compilation parameters with dynamic libraries to the applications at compile time. Like we don't need headers, we don't need those files.
Well, that's it. I hope I could be of some help. See you next time and happy Android'ing!
< Reserved for other stuff for guide, like hints.. >
Maybe also include a precompiled toolchain for download?
Can do that, but first need to compile a "static" toolchain for this. Actually, this seems like a good idea
Let me work on this next
Nice...big thx...i love such guide´s
with kind regards...Alex
theGanymedes said:
Can do that, but first need to compile a "static" toolchain for this. Actually, this seems like a good idea
Let me work on this next
Click to expand...
Click to collapse
Tried that: The output is huge, and even though the toolchain works without any need to any library, it still needs the libraries to be compiled in order to compile the other binaries - makes sense, since you need the libraries to compile against them anyway
So isn't it possible to package your toolchain which contains gcc, initial glibc and libraries, so that we can download and use them right away? It would save a lot of time and would be a far better option than the ndk.
Sent from my HTC Desire using Tapatalk
Droidzone said:
So isn't it possible to package your toolchain which contains gcc, initial glibc and libraries, so that we can download and use them right away? It would save a lot of time and would be a far better option than the ndk.
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
That's possible, but only if you're also using Ubuntu 10.10 or 10.04 and a 64-bit machine
For some reason - guess library version differences - toolchains done in 11.10 was not working at 10.04; so I had to redo it, for instance. This technique you say might or might not work - there is no guarantee in it.
Ah well.. I'm using a 32 bit Ubuntu 11.10 on a 64 bit machine. Anyway I have the toolchain I compiled on this one with your help..But if you remember I took a couple of days to get it done, even when I had your excellent help..Newcomers might find it difficult I guess. But if it werent for your toolchain compilation guide in the glibc thread, it'd have been next to impossible!
Droidzone said:
Ah well.. I'm using a 32 bit Ubuntu 11.10 on a 64 bit machine. Anyway I have the toolchain I compiled on this one with your help..But if you remember I took a couple of days to get it done, even when I had your excellent help..Newcomers might find it difficult I guess. But if it werent for your toolchain compilation guide in the glibc thread, it'd have been next to impossible!
Click to expand...
Click to collapse
Thanks Actually, it took me 3 days to make a bootstrap GCC and 8 days to make a Stage 1 GCC when I first began this I could never compile GlibC with those, because of the messy patches needed
I'm never claiming the process to be easy; but believe me: making a toolchain is the most irritating part. Most of the other programs do compile and run just fine, once their dependencies met. Only "very massive projects" like Xorg gives headaches time to time: because normal users do never try to compile those stuff from the source; and because of that, the developers don't try to make the process error-free.
Still, "grep" and knowledge of C makes wonders time to time
Droidzone said:
Maybe also include a precompiled toolchain for download?
Click to expand...
Click to collapse
I have a precompiled toolchain for android, it is in alpha stage with work still ongoing, and needs 2Go of storage. See: http://forum.xda-developers.com/showthread.php?p=43256170#post43256170
Hi my name is ashy and I need some help regarding building a kernel from source for an ongoing project called H1droid here: h**p://samsungi8320.freeforums.org/portal.php
Basically I am just getting into this kind of stuff and at best Iam a hacker and a modder not a developer, so Linux is pretty new to me. However I learn fast and have a good grasp on what's what.
I am trying to build the Kernel for this project from this source h**p://samsungi8320.freeforums.org/onenand-mtd-multiboot-recovery-cm7-2rc1-t765.html
These sources were created originally by R3D4 who doesn't come to our fourms any more, so I am here to ask for help.
In a nut shell I am trying to build the kernel from R3D4's sources. I have Ubuntu, the tool chains, cloned the source and have managed to build the kernel. The problem is that the kernel requires to be in uImage format with built in ramdisk, however for the life of me I can't figure out how to create the valid boot.img..
I have pulled the config file from the device to use as the default .config, and haven't changed anything in menuconfig when compiling.
I have tried flashing the resulting image to the device, but it doesn't boot at all. It seems that there is no ramdisk to boot a rootfs.
I notice in .config it expects an initramfs to be in a specified directory, however my problem is I have no idea how to create the initramfs to build into the kernel when compiling.
This is probably something easy, but I have searched and searched and can't figure it out, so I am asking here for someone who has the knowledge if they can guide me in the right direction as to how to build the initramfs into the kernel and then compile it as a boot.img to flash via recovery.
I appreciate any and all help.
Thanks, ashy
Please help!
Update: I have managed to compile the kernel with built in initramfs, however the phone still doesn't boot.
Can anybody help here I'm stumped. Iam using Ubuntu 11.10 in VMware and these are the steps I have taken:
1. Clone sources as in first post
2. copy initramfs files into directory specified in config file: CONFIG_INITRAMFS_SOURCE="../out/target/product/nowplus/root"
2. Open terminal in Kernel directory
3. use command: make ARCH=arm nowplus_defconfig (this is the config file from the phone)
4. start the build of the kernel: make ARCH=arm CROSS_COMPILE=/home/user/cm7/arm-2012.03/bin/arm-none-eabi- uImage
During the compile there are warnings regarding unused variables or something, but believe these are normal. However at the end of the build modpost reports: WARNING: modpost: Found 2 section mismatch(es).
Is this significant?
Could really do with some help here, I am new at this stuff and getting really frustrated as I've been at it for 2 weeks now. I have searched and searched the whole internet for an answer.
ashyx said:
Update: I have managed to compile the kernel with built in initramfs, however the phone still doesn't boot.
Can anybody help here I'm stumped. Iam using Ubuntu 11.10 in VMware and these are the steps I have taken:
1. Clone sources as in first post
2. copy initramfs files into directory specified in config file: CONFIG_INITRAMFS_SOURCE="../out/target/product/nowplus/root"
2. Open terminal in Kernel directory
3. use command: make ARCH=arm nowplus_defconfig (this is the config file from the phone)
4. start the build of the kernel: make ARCH=arm CROSS_COMPILE=/home/user/cm7/arm-2012.03/bin/arm-none-eabi- uImage
During the compile there are warnings regarding unused variables or something, but believe these are normal. However at the end of the build modpost reports: WARNING: modpost: Found 2 section mismatch(es).
Is this significant?
Could really do with some help here, I am new at this stuff and getting really frustrated as I've been at it for 2 weeks now. I have searched and searched the whole internet for an answer.
Click to expand...
Click to collapse
Ok have managed to make a little progress, it seems the rootfs is loading as it boots up to a screen with blue A N D R O I D text and then changes to a flashing cursor in the top left of the screen. I guess this means the kernel isn't booting.
Still looking for pointers out there on this, can nobody give me a hint or a way to debug this problem?
ashyx said:
Ok have managed to make a little progress, it seems the rootfs is loading as it boots up to a screen with blue A N D R O I D text and then changes to a flashing cursor in the top left of the screen. I guess this means the kernel isn't booting.
Still looking for pointers out there on this, can nobody give me a hint or a way to debug this problem?
Click to expand...
Click to collapse
Hey, like you i'm an user which enjoy to experiment stuff with linux, so, i want just thank you to share your experience, it helped me
Hello.
Been working on how to get a device kernel from source for the Mi note 10 pro (Mi CC9 Pro). I have gotten up to the point where it builds but fails due to dts folder is not found.
I need an example of what goes in DTC_EXT=
All I see on the net is DTC_EXT=dtc
Please help.
I use the kbuild/clang system that has a config that I can run.
I have CC, aosp toolchain, build-tools, qcom 8.0 llvm as real_cc. All linked, the only thing that fails is the dts files not being found
this is the issue i have
find: ‘arch/arm64/boot/dts/’: No such file or directory
terminal below
Spoiler: Terminal
Setting up for build
+ cd xsource
+ make CC=/home/avm/android/xkernel/prebuilts-master/clang/host/linux-x86/clang-r353983c/bin/clang HOSTCC=/home/avm/android/xkernel/prebuilts-master/clang/host/linux-x86/clang-r353983c/bin/clang O=/home/avm/android/xkernel/out/android-4.14/xsource mrproper
make[1]: Entering directory '/home/avm/android/xkernel/out/android-4.14/xsource'
find: ‘arch/arm64/boot/dts/’: No such file or directory
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN .config
Used config
Spoiler: Build config
ARCH=arm64
SUBARCH=arm64
BRANCH=K4.14Q
CLANG_TRIPLE=aarch64-linux-gnu-
CROSS_COMPILE=~/android/xkernel/tsource/toolchains/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
CROSS_COMPILE_ARM32=~/android/xkernel/tsource/toolchains/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-
KBUILD_DEFCONFIG=~/android/xkernel/tsource/arch/arm64/configs/tucana_user_defconfig
DEFCONFIG=tucana_user_defconfig
POST_DEFCONFIG_CMDS=""
DTC_EXT=dtc
DTC_PREBUILTS_BIN=/scripts/dtc
KBUILD_OUTPUT=out
HOSTCC=gcc
CC=clang
AS=clang
AR=ar
CLANG_PREBUILT_BIN=/toolchains/clang/host/linux-x86/clang-r353983c/bin
BUILDTOOLS_PREBUILT_BIN=/toolchains/build-tools/linux-x86/bin
FILES="
arch/arm64/boot/Image.gz
vmlinux
System.map
"
Found out it has something to do with the arch folder itself.
I replace it with the arch folder in the AOSP-kernel folder and it does not show up saying its not found.
Still crashing due to a new error about the include folder and a file or 2 that is in it. still trying my best to get it working.
SOLUTION to DTS MISSING:
Replace the makefile in the boot directory of your ARCH= type for the device. with the make files in aosp kernel same location.
Just want to point out that you may not need to do any of this and it is normal for the build not to find anything due to it, needing to be created during the kernel build process. the Make file that is located in boot under the ARCH type has some settings in it if you are using a device source other then google devices which contains information that i think the build needs, in order to be made.
After everything I said above, further investigation has proven that the Make file in {ROOT}/arch/arm64/boot is incorrect based off the one in aosp-coral-4.14 correct config is below. copy and replace the whole thing in the file.
Spoiler: Correct Make file config
#
# arch/arm64/boot/Makefile
#
# This file is included by the global makefile so that you can add your own
# architecture-specific flags and dependencies.
#
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# Copyright (C) 2012, ARM Ltd.
# Author: Will Deacon <[email protected]>
#
# Based on the ia64 boot/Makefile.
#
include $(srctree)/arch/arm64/boot/dts/Makefile
OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo dtbo.img
DTB_NAMES := $(subst $\",,$(CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES))
ifneq ($(DTB_NAMES),)
DTB_LIST := $(addsuffix .dtb,$(DTB_NAMES))
else
DTB_LIST := $(dtb-y)
endif
DTB_OBJS := $(shell find $(obj)/dts/ -name \*.dtb)
DTBO_OBJS := $(shell find $(obj)/dts/ -name \*.dtbo)
# Add RTIC DTB to the DTB list if RTIC MPGen is enabled
ifdef RTIC_MPGEN
DTB_OBJS += rtic_mp.dtb
endif
rtic_mp.dtb: vmlinux FORCE
$(RTIC_MPGEN) --objcopy="${OBJCOPY}" --objdump="${OBJDUMP}" \
--binpath="" --vmlinux="vmlinux" --config=${KCONFIG_CONFIG} \
--cc="${CC} ${KBUILD_AFLAGS}" --dts=rtic_mp.dts && \
$(DTC) -O dtb -o rtic_mp.dtb -b 0 $(DTC_FLAGS) rtic_mp.dts
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
$(obj)/Image.bz2: $(obj)/Image FORCE
$(call if_changed,bzip2)
$(obj)/Image-dtb-hdr: $(obj)/Image FORCE
echo -n 'UNCOMPRESSED_IMG' > [email protected] && \
$(call size_append, $(filter-out FORCE,$^)) >> [email protected]
$(obj)/Image-dtb: $(obj)/Image-dtb-hdr $(obj)/Image $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)
$(obj)/Image.lz4: $(obj)/Image FORCE
$(call if_changed,lz4)
$(obj)/Image.lzma: $(obj)/Image FORCE
$(call if_changed,lzma)
$(obj)/Image.lzo: $(obj)/Image FORCE
$(call if_changed,lzo)
$(obj)/Image.gz-dtb: $(obj)/Image.gz $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/Image.lz4-dtb: $(obj)/Image.lz4 $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/dtbo.img: $(DTBO_OBJS) FORCE
$(call if_changed,mkdtimg)
install:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
zinstall:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image.gz System.map "$(INSTALL_PATH)"
All this does is fix the build saying dts not found.
***UPDATE 2022***
You require dtc binary file from AOSP prebuilts/misc/dtc
Copy it to the devices kernel folder in scripts/dtc. Was able to build kernel (not sure if it works)
Does it come from any commit of git hub, could you give me the link, mine arch/arm... makefile is similar to your old but it compile with no error. so strange
namhoang235 said:
Does it come from any commit of git hub, could you give me the link, mine arch/arm... makefile is similar to your old but it compile with no error. so strange
Click to expand...
Click to collapse
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Squida said:
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Click to expand...
Click to collapse
yeah, your experiment is very useful for me, i am in these trouble you 've met yesterday.i help me a lot. thank again
i really dont want to edit makefile as i see many source have the same make file, so it is a compiler tool with some another input file for it to make, so i only edit makefile when it got error itsefl, if it is the path error, then i really dont want to edit it,
Squida said:
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Click to expand...
Click to collapse
can you give me a hint?
my kernel can make standarlone with bash script, but when compile with rom it make tons of errors about path, so which file i need to puth something like cc=clang,.... to make it pass when build rom
namhoang235 said:
can you give me a hint?
my kernel can make standarlone with bash script, but when compile with rom it make tons of errors about path, so which file i need to puth something like cc=clang,.... to make it pass when build rom
Click to expand...
Click to collapse
A hint. Sir I would tell you exactly if I knew how. I myself have failed to be able to get a working kernel let alone a rom running. When flashing a kernel that fails and it's supposed to be from the phone. So that tells me the device tree is incomplete and thus if it is, it fails the build as well as the kernel. I know of Qualcomm's own device builder but I am unable to get that working due to it, unable to locate clang for build. No matter how much I try and set a path I get errors using Qualcomm's builder. AOSP won't build the rom for the device because AOSP does not have the device tree or build files required to build it. You get a template from Qualcomm's builder. Though I can never get it to build. It's all because Xiaomi have not released the device tree or build files. And the people who have gotten it working are probably using someone else tree and build files or has edited their own. That is also why some features of ROMs do not work. It's due to missing info on device tree. Hope this all gives you a better understanding why it's hard for beginners to build a rom for this phone. Because Xiaomi does not have the files on their open source repo.
Squida said:
A hint. Sir I would tell you exactly if I knew how. I myself have failed to be able to get a working kernel let alone a rom running. When flashing a kernel that fails and it's supposed to be from the phone. So that tells me the device tree is incomplete and thus if it is, it fails the build as well as the kernel. I know of Qualcomm's own device builder but I am unable to get that working due to it, unable to locate clang for build. No matter how much I try and set a path I get errors using Qualcomm's builder. AOSP won't build the rom for the device because AOSP does not have the device tree or build files required to build it. You get a template from Qualcomm's builder. Though I can never get it to build. It's all because Xiaomi have not released the device tree or build files. And the people who have gotten it working are probably using someone else tree and build files or has edited their own. That is also why some features of ROMs do not work. It's due to missing info on device tree. Hope this all gives you a better understanding why it's hard for beginners to build a rom for this phone. Because Xiaomi does not have the files on their open source repo.
Click to expand...
Click to collapse
i built for ginkgo (superior rom) it have enough compile source, device, kernel, vendor (vendor is fine), but device and kernel not come from official source tree, maybe it have conflict and have to fork to edit mysefl. very hard for beginer
namhoang235 said:
i built for ginkgo (superior rom) it have enough compile source, device, kernel, vendor (vendor is fine), but device and kernel not come from official source tree, maybe it have conflict and have to fork to edit mysefl. very hard for beginer
Click to expand...
Click to collapse
Yeah building from a custom rom is easier then building from AOSP. Especially if the files for the device are available for building. Usually that's why you see ROMs that say unofficial and official ROMs. Unofficial is usually a modified version of another custom rom for another device to suit your own. Heavily modified. I could be wrong but this is how I took it.
Squida said:
Yeah building from a custom rom is easier then building from AOSP. Especially if the files for the device are available for building. Usually that's why you see ROMs that say unofficial and official ROMs. Unofficial is usually a modified version of another custom rom for another device to suit your own. Heavily modified. I could be wrong but this is how I took it.
Click to expand...
Click to collapse
they put tons of personal stuff without a comment, and some source are not update even they release rom once a week, they fear of clone their source while they clone from git too, they are destroy the ideal of open source itself
@Squida sir, do you meet this, i have gcc 9.3.0 by default and prebuilt gcc in source are updated, so what path i need to config for this can recognize my gcc
error Sorry, your version of GCC is too old - please use 5.1 or newer
In file included from /root/super/kernel/xiaomi/ginkgo/include/linux/compiler_types.h:58:0,
from /root/super/kernel/xiaomi/ginkgo/include/linux/kconfig.h:74,
from <command-line>:0:
/root/super/kernel/xiaomi/ginkgo/include/linux/compiler-gcc.h:159:3: error: #error Sorry, your version of GCC is too old - please use 5.1 or newer.
# error Sorry, your version of GCC is too old - please use 5.1 or newer.
Click to expand...
Click to collapse
namhoang235 said:
@Squida sir, do you meet this, i have gcc 9.3.0 by default and prebuilt gcc in source are updated, so what path i need to config for this can recognize my gcc
error Sorry, your version of GCC is too old - please use 5.1 or newer
Click to expand...
Click to collapse
Make sure no other versions of gcc are being detected. Probably have more then one.
Also could be it may not be set as default.
Type gcc --version in terminal to check what is installed
Squida said:
Make sure no other versions of gcc are being detected. Probably have more then one.
Also could be it may not be set as default.
Type gcc --version in terminal to check what is installed
Click to expand...
Click to collapse
[email protected]:~/super# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)
[email protected]:~/super#
Click to expand...
Click to collapse
This is a nut with me now.
namhoang235 said:
This is a nut with me now.
Click to expand...
Click to collapse
Lol yeah no idea. That's a lot of info for just doing a version check. If you don't want to uninstall and reinstall Linux. I would Google on how to set gcc xxx as default and see if that helps maybe even seeing if there is an automated .sh you can run so it installs and fixes the problems. I would do a search in the Linux repo on gcc and have a look for anything that says default. Usually those installers will also set it to default for you automatically. I myself am not good with Linux. So that's about as far as I could help on this situation you are in.
The gcc you may need is this https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/