With the ROOTFS_TARGET conversion, EXT2_OPTS gets evaluated very early
(before TARGET_DIR is populated with files), so the calculated
blocks/inodes numbers are wrong.
Fix it by moving the calculation to a shell script wrapper around
genext2fs, so it only gets executed just before genext2fs runs.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_TARGET_ROOTFS_EXT2_RESBLKS is an int, so test against 0 rather than
the empty string - Otherwise the test is always true and a -m option
without arguments is added to the argument list, causing genext2fs to
get confused.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We only bother updating the defconfigs that need a non-default
BR2_ROOTFS_DEVICE_TABLE value.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We have a special case for Xtensa, which was patching the generic
device_table.txt. Instead of doing this, we just keep a copy of the
device table, specific to Xtensa, with Xtensa specifities. The fact
that the patch wasn't applying anymore on the generic device table is
a sign that the existing approach wasn't working anyway.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, the location of the device table was specified by a
variable in board Makefiles. Unfortunately, this variable is not
accessible from fs/common.mk, since the target/ code is included
*after* fs/common.mk.
Anyway, the general idea is to move away from these boards Makefile,
and provide configuration option for things like the device table
location.
Therefore, this patch adds a BR2_ROOTFS_DEVICE_TABLE option which
allows to specify which device table should be used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The installation procedure of cramfs was broken when
$(HOST_DIR)/usr/bin didn't exist (i.e, cramfsck was installed as
$(HOST_DIR)/usr/bin directly). Use install -D with a proper
destination argument to make it work.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When compiling Busybox, according to readelf -A, all object files were
properly compiled according to the select architecture (-march=armv4t
for example), but the final busybox binary could be of a different
architecture (ARMv5t even if ARMv4t was selected).
This patch changes the way we configure/compile Busybox so that our
CFLAGS aren't anymore passed through the make EXTRA_CFLAGS variable,
but through the .config CONFIG_EXTRA_CFLAGS variable. Unfortunately,
those variables don't have exactly the same semantic for the Busybox
build system.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Multilib toolchains provide different versions of the base libraries
for different architecture variants. For example, the ARM Codesourcery
toolchain provides base libraries for ARMv5 (default), ARMv4t and
Thumb2.
Depending on the -march= argument passed to gcc, the sysroot used by
the compiler is therefore different. This means that the sysroot
location in CROSS-gcc -v cannot be used. Instead, we must use
CROSS-gcc -print-sysroot when available and fall back to the old way
if unavailable.
Moreover, we cannot simply copy the full sysroot as we used to do,
because the sysroot organization of multilib toolchain is more
complicated. In Codesourcery toolchains, we have :
/
etc -- for ARMv5
lib -- for ARMv5
sbin -- for ARMv5
usr -- for ARMv5 (includes headers)
armv4t
etc -- for ARMv4t
lib -- for ARMv4t
sbin -- for ARMv4t
usr -- for ARMv4t (no headers!)
thumb2
etc -- for Thumb2
lib -- for Thumb2
sbin -- for Thumb2
usr -- for Thumb2 (no headers!)
So we have the default ARMv5 architecture variant that is installed in
the main directory, and we have subdirectories for the ARMv4t and
Thumb2 architecture variants.
Copying the full sysroot to the staging directory doesn't work. All
our packages are based on the fact that they should install libraries
in staging/usr/lib. But if ARMv4t is used, the compiler would only
look in staging/armv4t/usr/lib for libraries (even when overriding the
sysroot with the --sysroot option, the multilib compiler suffixes the
sysroot directory with the architecture variant if it matches a
recognized one).
Therefore, we have to copy only the sysroot that we are interested
in. This is rendered a little bit complicated by the fact that the
armv4t and thumb2 sysroot do not contain the headers since they are
shared with the armv5 sysroot.
So, this patch :
* Modifies how we compute SYSROOT_DIR in order to use -print-sysroot
if it exists. SYSROOT_DIR contains the location of the main sysroot
directory, i.e the sysroot for the default architecture variant.
* Defines ARCH_SUBDIR as the subdirectory in the main sysroot for the
currently selected architecture variant (in our case, it can be
".", "armv4t" or "thumb2"). ARCH_SYSROOT_DIR is defined as the full
path to the sysroot of the currently selected architecture variant.
* Modifies copy_toolchain_lib_root (which copies a library to the
target/ directory) so that libraries are taken from
ARCH_SYSROOT_DIR instead of SYSROOT_DIR. This ensures that
libraries for the correct architecture variant are properly copied
to the target.
* Modifies copy_toolchain_sysroot (which copies the sysroot to the
staging/ directory), so that it copies the contents of
ARCH_SYSROOT_DIR, and if needed, adds the headers from the main
sysroot directory and a symbolic link (armv4t -> . or thumb2 -> .)
to make the compiler believe that its sysroot is really in armv4t/
or thumb2/.
Tested with Codesourcery 2009q1 ARM toolchain, Crosstool-NG ARM glibc
and ARM uClibc toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The copy_toolchain_lib_root function was making the assumption that
all libraries were stored inside the /lib directory of the sysroot
directory. However, this isn't true for certain toolchains,
particularly for the libstdc++ library.
The function is therefore reworked to find the library and its related
symlink either in /lib or /usr/lib in the sysroot, and copies it at
the same location in the target directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, many TARGET_CFLAGS where missing when using an external
toolchain, due to how package/Makefile.in was written. Now, a lot more
definitions are common between the Buildroot toolchain case and the
external toolchain case.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also cleanup autotools symbols and add libatomic_ops dependency
for Intel part.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
These options are part of the default set of options passed to
./configure by the AUTOTARGETS infrastructure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the introduction of the AUTOTARGETS infrastructure, the dummy
example is no longer correct. Moreover, the documentation now contains
extensive details about how new packages should be added, either using
the GENTARGETS or the AUTOTARGETS infrastructures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bumping the version from 2.5.9 to 2.6 allows to avoid adding a patch
(merged upstream) to fix patch's Makefile install target.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
