gcc installs the C++ headers in ${PREFIX}/include/ but we trash
that directory at the end of the build.
We previously removed that directory as it contained the companion
libraries header files. But it's been some time now that we isntall
the companion libraries in their own dedicated place, so we do not
need to remove that directory.
Until we have a better fix, just keep that directory for now.
Reported-by: Bob Rossi <bob@brasko.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Reformat the error messages:
- strip ${CT_LIB_DIR} from scripts path names
- strip ${CT_TOP_DIR} from build.log path and docs path
- overall shorter lines
- point to the known-issues file
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case date(1) does not support nanosecond resolution, it does
not interpret '%N', and leave it as-is. So we have to remove it.
Note that some versions replaces '%N' with 'N', so we have to
take this into account as well.
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Using CT-NG with progress bar disabled, still prints CR ('\r') characters
on the output. When you capture the output to a file as part of an
automated build, it shows extra empty lines.
For example:
------------------------------------------------------------
[INFO ] Performing some trivial sanity checks
[INFO ] Build started 20110404.113619
[INFO ] Building environment variables
[EXTRA] Preparing working directories
[EXTRA] Installing user-supplied crosstool-NG configuration
------------------------------------------------------------
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Managing the shared version of the companion libraries
has become cumbersome.
Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.
As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
PPL 0.11+ installs three libs: lippl, libppl_c and libpwl.
libppl_c has a dependency on libpwl (at least for watchdog stuff).
While gcc correctly links with libppl and libppl_c, it does not
pull libpwl in. In case of shared libs, this is not a problem, as
libppl_c has a NEEDED dependency on libpwl. But for static libs,
that does not work. Although libppl_c.la exists and has a correct
dependency on lipwl, somehow gcc misses it. So we have to force
pulling libpwl when needed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There was a mishap when cut-n-pasting code from the final
step into the core step: a variable was not renamed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In a lot of places, we need to call some commands with specific
variable settings, a-la:
var1=val1 var2=val2 /foo/bar/buz opt1 opt2
Unfortunately, we currently can not log the variable settings.
Enhance CT_DoExecLog with a crude heuristic that works pretty well
and that can also log setting variables.
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Users tend to look for the build log in the current working directory,
rather than in the toolchain's installation dir. While bundling the build
log in the toolchain installation dir is nice for distribution and review,
it can be easier to have the build log readily available in the working
directory, as it is quicker to get to it.
So, the build log stays in the working directory until the toolchain is
completely and successfully built, and then a (compressed) copy is made.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The heuristic to find shell script is deficient. Fix it.
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Doing a chmod on the whole source dir after every packages
are extracted can take a hell of a lot of time.
The offending packages are far from legion, and they now
have their own chmod u+w to cleanup their own mess...
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Building the start files requires a shared-capable compiler, which we do
not have when the threading implementation is LinuxThreads.
So, only build the start files when the threading implementations is NPTL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default, recent versions of glibc and eglibc will build some
functions that take format strings (eg. printf, syslog...) with
run-time checks against some format string attacks. This is
called a fortified build.
Unfortunately, this fails somehow while building the instrumented
version of syslog, with some kind of circular dependency...
Disable fortified builds by default, and hide the enabling option
behind EXPERIMENTAL for daring users...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As companion tools might or might not be used to build each
toolchain, they do belong to that toolchain's build tools,
not to the generic override tools.
Fix a typo in the autoconf URL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Consider the buildtools install directory as a prefix directory,
that is, install buildtools in prefix/bin/, not in prefix/.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There is absolutely *no* reason for the buildtools (wrappers to gcc, g++,
as, ld... for the local machine) to be in the toolchain directory. Moreover,
they are removed after the build completes.
Move them out of the toolchain directory, and into the build directory (but
yet the part specific to the current toolchain). This means we no longer
need to explicitly remove them either, BTW, but we need to save/restore them
for the restart feature.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the buildtools are installed relative to ${CT_PREFIX_DIR}.
Change that by introducing ${CT_BUILDTOOLS_DIR}, which is
still set relative to ${CT_PREFIX_DIR}, but which will make it easy
to change in the future.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If we set PATH to the tools wrappers before we create the
makeinfo wrapper, then we may well wrap an existing wrapper
from a previous run.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The gcc used by linaro has a version number specific to Linaro, but
identifies itself with its upstream version numbering scheme.
This breaks the strip in the finish step, because the actual gcc version
is not the same as the configured one (eg. 4.5.2 vs. linaro-4.5-2011.02-0).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We make it an option, as not all combinations of architectures
vs. compiler vs. glibc/eglibc exhibit the issue. Mostly visible
on old glibc versions, it seems...
This is a missing part from the glibc/eglibc merger... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Enabling plugins in binutils is not enough, and gcc also
needs to be ./configured with --enable-plugins, although
this is not documented anywhere... :-/
Reported-by: karthik duraisami <kdconstant@hotmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since the advent of make-3.82, some packages now break due to changes
in make-3.82, being stricter than 3.81 when interpreting the Makefiles.
This has bugged us a bit too much so far, and I believe fixing all
of them is a long road, while simply building make-3.81 is the easiest
route for now.
Of course, in the long term, packages will get fixed upstream, and we
should back-port the fixes to old versions, and get rid of building
make-3.81. In the meantime...
Reported several times on the mailing list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In certain circumstances, removing the destination/installation directory
is a bad idea. For example, when the build environment is already taking
care of sanitising the build tree, and pre-installs stuff in there, it is
a very bad idea to remove the destination directory.
This happens now in buildroot, as the crostool-NG backend now installs the
toolchain in the common host-tools directory, and pre-install there a few
host-utilities (eg. host-automake and host-gawk).
Provide a config knob to turn on/off the removal of the destination
directory, defaulting to 'y' (previous behavior), and forced to 'n' when
used as a backend.
Reported-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Under mingw, it seems that there is a mix between the traditional /usr
directory, and a similar-purposed /mingw directory (both in the sysroot).
Currently, we create /mingw as a symlink to /usr, and we removed it in
the libc-finish step.
Unfortunately, this prevents the pre-processor to find the headers.
Keeping the symlink makes it magically work...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Computed paths may contain double slashes.
This is not an issue but it is just ugly to look at.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.
Add an option for that.
Default to 'sysroot' to match the existing literature.
While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.
Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Final step at sharing code between glibc and eglibc.
Fall, wall of shame, fall!... :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.
See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc and eglibc each have two very similar ways of building this list.
This can, and should definitetly, be shared.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It will be possible to use that also with eglibc, so this hunk belongs to
the common code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the common procedure, shared between glibc and eglibc. This requires
that glibc-specific bits be included in the shared procedure.
But still build the full libc with the glibc-specific procedure. This will
be commonalised in a future commit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The build procedure for eglibc is generic enough to
be shared between glibc and eglibc. This includes:
- headers install (empty!)
- start files build
- complete libc build
- libc finish (empty!)
- add-ons list
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
mingw already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
uClibc already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This is an obsolete version which is no longer used by any sample (the only
user, the ia64 sample, has been removed).
It also makes the code path a bit complex, with twists just to accomodate
that version. Removing the version will make those twists go away, and
will ease commonalisation of glibc and eglibc in the future (hopefully!).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ia64 is broken in every gcc/glibc combinations I tested (except for the
existing sample that used very old versions).
Nobody complained on the list about not being able to build recent versions.
So the only way forward I can see is to remove the architecture altogether.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The location of the longterm Linux kernels on FTP has changed.
Here is a simple (but not very versatile) fix.
Signed-off-by: "Björn A. Herwig" <herwig@gdsys.de>
[yann.morin.1998@anciens.enib.fr: make it generic/versatile]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Latest version of CLooG does not have properly generated autoconf files,
so they need to be regenerated before the call to ./configure
Signed-off-by: "Ilya A. Volynets-Evenbakh" <ilya@total-knowlege.com>
[yann.morin.1998@anciens.enib.fr: make it conditional on 0.15.10 only]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ltrace 0.5.3 currently fails to build for target mips because MY_TARGET
(introduced by patches/ltrace/0.5.3/150-allow-configurable-arch.patch)
is set to 'mips' via CT_ARCH, while the mips specific stuff in ltrace
(0.5.3) is stored under sysdeps/linux-gnu/mipsel:
result: *** No rule to make target `mips/arch.h', needed by `sysdep.h'.
Stop.
The following patch fixes this issue
Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: reformat commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To properly enable LTO with gold, gcc has to install a plugin that gold
uses to handle the LTO information.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When both gold and ld are installed, add a wrapper that calls
to either gold or ld.
In case the wrapper is installed, we also need to symlink ld.bfd
and ld.gold for the core_cc steps.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When configured with support for threads, gold can link in
parallel, possibly cooperating with a make jobserver.
Add an option enabling threads.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is a new, optimised, multi-threaded linker with support
for plugins.
Add support for gold starting with binutils 2.21. Although 2.20
also had gold, the configure flags have changed, and supporting
2.20 would be a mess in the code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libelf is used by gcc to build the lto-plugin used
by binutils' gold to perform LTO.
This requires that files in libelf be compiled with
-fPIC to generate a proper .so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Hidden version names for uClibc conflicted:
LIBC_UCLIBC_V_0_9_30_2
LIBC_V_0_9_30_1
name them constantly as:
LIBC_UCLIBC_V_<version>
Also update the build script where we use snapshots by version or snapshots by date.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Like rev 2002, eglibc installs some bash scripts, but use the path to the
buildtool bash as the interpreter (on the shebang line). This is only a
symlink to the real bash, and thus is not available at runtime.
Fix that by assuming that shell on the target *will* be /bin/bash.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
headers_install makes .install and ..install.cmd files.
headers_check makes .check and ..check.cmd files.
Remove these files uncoditionaly after installing (and checking) header files
into the sys-root.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[Yann E. MORIN: reformat the patch, move hunk out of headers_check conditional]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It appears, that the configure scripts of libelf versions 0.8.13 and
0.8.12 do not honour the --host option. The compiler must be given as an
environment variable or the process will use the command "gcc" as the
compiler.
It seems that this is already done in the function do_libelf_target in
scripts/build/companion_libs/libelf.sh, but not in function do_libelf.
Do not try to strip any script.
Previously, only shell scripts were ignored, but when the Java frontend
is installed, it also installs a Python script. So we have to ignore
any "script text executable", and not restrict it to "shell script text
executable".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Using a list of files to strip misses a few of them.
Now, scan appropriate directories, and strip all ELF
executables and shared objects.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
- add a new parameter to do_cc_core: build_statically=[yes|no]
- pass build_statically=yes in core_pass_2 when doing bare_metal
- fix handling the static / static libstdc++ / static complibs stuff
- add a commment to keep both blocks (in core and final) in sync
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build the final gcc statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build binutils statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This rules out 0.15.5 and previous versions, that did not
have this option, so remove them from the list. Anyway,
they were marked 'OBSOLETE', so it's not a big loss...
[Yann E. MORIN: remove obsolete versions]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Download to an intermediate temp file, and rename it to its final
name only of download succeeds.
This catches both a failed download, and also the case where the user
interrupts the download. Thus, the a partial download gets discarded,
and we no longer try to extract a partial tarball, which we would
previously have done.
Suggested by Thomas PETAZZONI.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It can happen, in some circumpstances, than one can succeed where
the other would fail. Those cases involves convoluted enterprise
networks with proxies playing tricks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The RPATH tags allow a binary to tell the dynamic linker what
directories to search for libraries. The so-added paths are
searched into before any other paths.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Once a NEEDED dependency has been solved, do not report it
if other dependencies depend on it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add debug traces to help understand how xldd finds the
libraries, what directories it scans, in which order...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Scan /etc/ld.so.conf for paths to search for libraries.
Also follow include directives in there.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Only starting with 4.4 does gcc have a -print-sysroot option.
For 4.3 or before, we have to play some tricks:
- ask gcc where libc.so is,
(we expect it in ${sysroot}/usr/lib/libc.so)
- trim /usr/lib/libc.so from the result
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Break the library search loop as soon as a match is found.
Previously, if a library was present in different places,
then the last occurence would be returned, when the first
one would have been used at runtime.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The version string was hard-coded.
Now, the version string follows the crosstool-NG version.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since Subversion 1.6.13 was released, it is no longer possible
to checkout/export to the current working directory using '.'
(eg. "svn co bla://blabla/foo/bar ." no longer extracts the content
of bar into ./ but into ./bar).
Fix this by luring Subversion to extract into "$(pwd)", which has
the advantage of working both with all known versions so far.
At the same time, remove the useless redirection.
On some systems, we also need to overide LANG as well as LC_ALL.
Reported-by: Geoffrey Lee <geoffl@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Adds support to enable/disable IOs of floating point values
(float, double, and long double).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This was intended as a fix for g++ not finding its headers,
but it breaks in othe horrible ways. So just revert it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The save/restore state output is voluminous; using this flag allows us
to quickly see or ignore when something is just being saved.
[Yann E. MORIN: this is a blind log level, and is used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed. Adding these two levels allows me to
differentiate between those cases.
[Yann E. MORIN: Those are blind log levels, and are used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
In case we build the C++ compiler, we have to tell gcc where to put the C++
headers, or else it will try to # put it in prefix/tuple/include, which we
make a symlink to sysroot/usr/include during the build, and that we delete
(the symlink!) after the build, but gcc will not look in sysroot/usr/inlcude
for C++ headers by default.
Implements a fix suggested by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libssp is the run-time Stack-Smashing Protection library.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libgomp is the GNU implementation of the OpenMP API.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Unconditionally create the lib32 -> lib/ and lib64 -> lib/ symlinks.
This is reportedly a fix to build a toolchain for a 32-bit target on
a 'pure' 64-bit host (eg. on Fedora FC12, host libs are in lib64/,
and there is no lib -> lib64 symlink, as we can see on other distors,
as Debian). As gcc only puts static host lib in lib64/ (along with
target files in subdirs), we can safely create the symlinks.
Also note that the symlinks are summarily removed at the end
of the build.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
[Yann E. MORIN: fix a comment, rephrase the commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To decide whether we need to backup the companion libraries,
do not rely on the !shared case. In the future other cases
may require not to save the companion libraries (eg. if using
the ones provided by the host distro).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Force gcc to not link with some companion libraries when
there are not needed (because selected-out).
There is no option to tell gcc *not* to build the Graphite and/or
LTO stuff. They *will* be built if gcc finds the suitable companion
libraries. If we do not provide them, but the host has them, then
gcc *will* find them, and link with them.
Consider the following:
- host has suitable PPL and CLooG (eg. Debian Squeeze)
- user wants to build gcc>=4.4
- user de-selects GRAPHITE
- gcc will find the hosts PPL and CLooG, and will use them
- the user moves the toolchain to an older host that does
not have them (eg. Debian Lenny)
- the toolchain fails, when it was properly setup not to
So, explicitly tell gcc *not* to use unneeded companion libs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
While GMP and MPFR are required by gcc>=4.3 (to build the frontends),
and MPC is required by gcc>=4.5, the other libs are not. If they are
present then gcc will enable advanced features; if they are missing,
then gcc will (should) simply disable those features.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the MIPS ABI selection to properly munge the uClibc config file.
This has the side effect to force the ISA:
- n32 ABI -> MIPS-III ISA
- n64 ABI -> MIPS64 ISA
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This adds selection for one of the o32, n32 and n64 ABIs.
Later, we can easily use those boolean options, rather than
relying on a user-supplied string option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The symlinks are needed only during the build process.
The final gcc will still search those dirs, but will also search
the standard lib/ dirs, so we can get rid of the symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some archs (eg. ppc64 with n32 ABI) will install their
variants in lib32/ instead of lib/, so do for lib32 as
we do for lib64->lib symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For now, ncurses is the only dependable target library built for gdb.
But expat is coming, and there's no reason to install each library in
its own place.
So, install ncurses in a generic directory, where other dependable
libraries can be installed as well.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As there's no longer any user of the companion libraries on the
target, nuke the build for the target.
Well, at least, there's libelf that's still needed by ltrace, so
we keep it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Although the gdb ./configure advertises for GMP and MPFR, those libraries
are not used by gdb (the ./configure is used across different packages,
hence the check for GMP/MPFR). See:
http://sourceware.org/ml/crossgcc/2010-08/msg00168.html
The same applies to MPC.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When targeting mingw32, gcc expects to find its include files
in "mingw/include" instead of the traditional "usr/include".
[Yann E. MORIN: split the original patch]
It happens from time to time that the server mis-behaves, and breaks the
connection right in the middle of nowhere, for no good reason, leaving us
with a partial file, on which the extract pass would choke.
Remove partial downloads, to fail early.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Even when // downloads are not enabled, aria2 can
fail on some servers (eg. uclibc.org).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To reduce filesizes of the toolchain and even improve build times
of projects to be build with this toolchain it is usefull to strip
the delivered toolchain executables. Since it is not likely that we
will debug the toolchain executables itself we do not need the
debug information inside the executables itself.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Replace the over-engineered and buggy test in CT_SanitizePath
with a straight forward string pattern match, and also
handle empty PATH elements which are qeuivalent to ".".
Thanks-To: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Add CT_SanitizePath function which removes entries referring to ., /tmp
and non-existing directories from $PATH, and call it early in the
build script.
If . is in PATH, gcc-4.4.4 build breaks:
[ALL ] checking what assembler to use...
/tmp/build/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as
...
[ALL ] config.status: creating as
i.e. "as" is supposed to be the arm-unknown-linux-uclibcgnueabi cross assembler,
but config.status creates a local "as" script which is calling the
host assembler.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[Yann E. MORIN: style fixes + explanations]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For some scenarii, libmudflap is not very usefull
or can break the build. Make in an optioon that
defaults to 'N' to be on the safe side.
For the core gcc-s, there is absolutely no need
to build libmidflap.
Idea from: Bernhard Pfund <bernhard@chapter7.ch>
Some time, someone updated the locale Makefile to use
newer pre-generated locales data, but did not upload
those.
So we just force using the existing, ageing archive,
dating back 20030818. Sigh...
It seems that using pre-generated locale data can be more problematic
than usefull in some circumstances.
Offer a config knob to enable/disable use of the pregen locale data.
Also, do not extract pregen locales data ourselves, it's broken.
I was unable to make the cross-ldd from uClibc to work, and
it is not possible to build it on non-POSIX system.
Besides, we have a generic script that is in the starting-blocks
to replace it, that will work for any C library, and also will
work on non-POSIX systems. Bonus!
When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
GDB requires PDcurses instead of ncurses while running on Windows.
So, do not always compile ncurses in case GDB needs to build.
PDcurses is provided by an earlier build step and is not described in
this file.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciense.nib.fr: we already have a way to detect ncurses usage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add several development libraries to the build of the mingw cross-compiler
to be used on target
Libraries:
PDCurses (port of the ncurses library)
GnuRX (the regex library)
DirectX
OpenGL
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: don't show DX and RX versions if disabled]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add the option to build a cross-compiler for kernel type 'mingw'.
The resulting cross-compiler can be used to build applications on a Linux host
that can be run on a Windows target.
Compiler is build using the mingwrt and w32-api packages aviable from the
MinGW project (http://sourceforge.net/projects/mingw).
The windows headers (w32-api package) are extracting with the kernel_headers
step The libraries and other headers from both packages are build and
installed in the various steps of libc
Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix kernel headers comment, don't "return 0"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc installs some bash-scripts, but uses the path to the buildtool
bash as interpreter (on the shebang line). This is only a symlink to
the real bash, and thus is not available at runtime.
Fix that by assuming that bash on the target *will* be /bin/bash.
In C, the proper syntax for a bit-wise OR is a single '|', not two.
It worked so far because all was well:
- X_OK == 1
- R_OK||X_OK == 1
- the file we searched for had the x-bit set
-> access( file, R_OK||X_OK ) worked
- inicidentally, the file we searched for also had the r-bit set,
but we were not testing that in fact.
Accept a local tarball name as the source of the Linux kernel headers,
rather than forcing the user to use either an upstream tarball, or a
local pre-installed headers tree.
Here, we implement a highly ugly hack. I'm not proud of that one...
To build the libstdc++ library, the compiler requires the C library. In
case we build for non-baremetal, this is normally handled by the final
step, later.
But in the case of bare-metal, we never go through the final step (because
it does not work, and it seems complex enough to make it work), so the
baremetal compilers are issued out of the core step.
A few facts:
- building the C library requires a proper core compiler
- core compiler is issued from one of the core passes
- the C library is required to build libstdc++
- newlib is only built for baremetal
- in bare metal, the final compiler is issued from one of the core passes
So we need to build the C library between core pass 1 and core pass 2.
The only place is eithe libc_headers() or libc_start_files(). The most
pertinent seems to be libc_start_files().
So we build newlib from libc_start_files(), and leave libc() empty.
static linking is not possible on MacOS, and unnessecary on other systems.
The old optimization and warning flags crash the gcc on MacOS
and (imho) are a bit overdone for this software.
This patch adds support for installing the gcc test suite. A helper
Makefile is provided for building and running the gcc tests.
The default configuration runs all gcc tests and requires automatic
ssh/scp login access to a networked target board. See README for
more details.
Note: Current feature is tested with the powerpc-unknown-linux-gnu
sample but it should work with others as well.
Signed-off-by: Martin Lund <mgl@doredevelopment.dk>
The shell wrapper script uses a nonportable call to readlink.
Thus, always use the binary wrapper under BSD/MacOS.
yann.morin.1998@anciens.enib.fr:
Use 'case' instead of 'if'.
On 64bit MacOS `gcc -dumpmachine` gives i686 for the host machine.
This conflicts with the expectations of some following configure scripts
that a 64bit x86 is given as x86_64; i686 is understood as a 32 bit machine.
config.guess sets the host machine in CT_BUILD correctly.
yann.morin.1998@anciens.enib.fr:
As suggested by Khem RAJ on the ML, always use config.guess.
Call to get the directory mode depending on $CT_SYS_OS
yann.morin.1998@anciens.enib.fr:
CT_SYS_OS has changed on Linuxsystem, it only gets the kernel name "Linux",
and not the system name, 'GNU/'.
The call to stat to find out if a file is a symlink works only on GNU systems,
and the replacing portable call to readlink is also shorter and more concise code.
yann.morin.1998@anciens.enib.fr:
Apply simpler test, after discussion with author and Arnaud LACOMBE on the ML.
On non-GNU systems (BSD/MacOS) there is no uname -o.
Suppress the failure message on these systems in the
call to set CT_SYS_OS (uname -s actually sets this variable).
yann.morin.1998@anciens.enib.fr: remove 'uname -o' altogether.
g++ is only needed when building additonal libs on the HOST,
so check wheter g++ is available for the HOST compiler only
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: fix space damage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
While compiling a canadian toolchain for host=mingw32, build=linux,
target=m68k-elf the build fails because in this step of the gcc build
the Host compiler is used in this stage with the build-flags for the
build system. This results in an error where the header <sys/wait.h>
cannot be found.
This problem happens at least in the GCC-4.3.x and GCC-4.4.x range.
This is solved by passing the proper compilers on the Make cmd-line
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Previous addition of the canadian cross compiler did not allow
to build a baremetal only variant, no reason why this is not
allowed
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
When building a cross-compiler for a host which depends
on file extensions the symlink for cc was not installed correctly
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: style fixes, enhancements, code prettying]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Insight seems to be very slow to follow up on mainstreram gdb.
Latest snapshots are more than 6 months old.
Moreover, I don't have time to maintain insight support in crosstool-NG;
and, because I don't use it, I am unable to find any breakage.
For uClibc, the name of the Blackfin architecture is 'bfin'. Actually,
the naming of the architecture is quite messy: for toolchain tuples
and uClibc, it's bfin, but for the kernel, it's blackfin. We've
arbitraly choosen to name it "blackfin" in Crosstool-NG.
Add Blackfin-related uClibc patch to fix a build failure related to
fork() being used in unistd/daemon.c.
Yann E. MORIN:
Apply the patch to the kernel/linux build script to use 'linux'
in the noMMU tuples. See:
http://sourceware.org/ml/crossgcc/2010-04/msg00010.html
Saving and restoring the steps requires saving/restoring multiple
directories. Depending on the configuration, some may not exist.
Add a wrapper that checks before creating/extracting the tarballs.
When building for bare-metal the core-gcc compiler is delivered
as final compiler, so the version info and bugurl is useful
in the core compiler as well.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Not all target tuples consist of an VENDOR, KERNEL and SYSTEM part, build up the
tuple in such a way to no extra or trailing dashes are added to CT_TARGET
Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
In some exotic case the autoreconf step of mpfr is not executed (correctly)
leaving an incorrect version number for libtool in the configure script.
After extracting the sources files, force autoreconf to be executed.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
If threads are disabled in libc, we don't want to enable them in the
final compiler. Doing so pass the configure stage, but fails latter on
a missing <pthread.h>.
Moreover, we don't want to build libgomp if threads are disabled; its
configure script would fails anyway.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
- don't list samples in the main help screen
- improve the samples listing in list-samples
- don't document the 'config' action, it's long dead
- document the 'V' environment variable
- improve on START, STOP and PREFIX environment variables
- add PREFIX and V to autocomplete
- advertise auto-complete at install time
Curently, populate will iterate over all ELF (shared objects|executables)
to look for missing NEEDED DSOs, adding to the list at every iterations
of the search loop.
Instead of looking again at previously handled ELF files, recursively
resolve every ELf files.
Also, in case there are a whole lot of files (more than the shell can
accept as arguments list, or creating a command line longer than the
shell can cope with), use a temporary file with the list of files
to search for missing dependencies.
- it's a POSIX compliant shell script: drop bash, use /bin/sh
- fix help text
- use an absolute path for sysroot
- replace "echo" with "printf"
- replace "stat -c '%i'" with "ls -1id"
- replace "pushd / popd" with "cd / cd -"
- remove superfluous break
- bail out if required lib not found, except if forced
If a list-file is used, then each library in the file will be handled
twice (not a real issue, as the second iteration will find the library
already present, just avoid doing the job twice).
This fixes two problems:
- the sysroot might be in a sub-directory (think SYSROOT_DIR_PREFIX)
- it is not needed to have the target tuple to properly detect the sysroot
and the required tools
As a side effect, this script is now no longer dependent on the target
tuple, and in the future, we might be able to share it across many
toolchains (when/if we can install all of them in the same place).
Add a new command line option, "-r", which allows the user to specify
an alternate sysroot location to copy libraries from. This is useful
when using the toolchain in combination with a separate root filesystem,
or when working with multiple different root filesystems.
Signed-off-by: Nate Case <ncase@xes-inc.com>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
The native 'tic' will _always_ be run on the build
machine, so no need to handle canadian/native/...
Reported by: Trevor Woerner
http://sourceware.org/ml/crossgcc/2010-03/msg00055.html
(transplanted from 26e89d367ea11660fd3a0bf0bcad8763e4fa21cf)
ltrace uses i386 and x86_64, whereas crosstool-NG use x86 for both cases.
Fix that by detecting what bitness we're building for, and pass appropriate
i386 or x86_64 to ltrace's configure.
The companion libraries on the target are required only for internal use by
binutils and gdb. The user should not have to know about this, so hide the
option.
On some systems (eg. *BSD and Darwin), date does not support nanoseconds
(%N) precision. Instead of printing '%N' in this case, it just prints 'N'.
Fix the sed expression to handle this case.
Add a git wrapper to retrieve components from their git tree.
Add a git wrapper to create a working copy (in our tarballs dir).
Recognise git trees when searching for local copies.
We can not rely on the user-provided version string (be it via the
choice, or manually entered), so fallback to reading version.h,
which is both reliable and always present.
It's now been a while that glibc switched to git from cvs.
Get rid of cvs to download glibc; this will make for a good
cleanup before we add git support! :-)
It's broken anyway. Eg.:
- user is already niced at 10
- user configures to renice at 5
- breaks because user is not allowed to 'boost' his/her nice value
Bette let the user handle the renice with:
nice -XX ct-ng 'action'
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciens.enib.fr: use defaults for CT_TARGET_ARCH]
Signed-off-by: "Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
We only build the static ncurses, to be used to build the native gdb,
and it needs not be available for anyone but us. So install it into
a temporary place, and get rid of it once gdb is built.
Initial version of adding autoconf as a companion tool.
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: use generic overide tools dir]
[yann.morin.1998@anciens.enib.fr: update menu entries]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Change the overide bin dir so it can be used by companion tools
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: more generic overide tools dir]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default curl doesn't folow redirects. This breaks sourceforge downloads.
Add the -L option to curl to fix this.
Curl also downloads the html as a file even when it gets a 404. This breaks
http downloads when using the failback system. Add the -f option to curl to fix
this.
Signed-off-by: Richard Strand <richard.strand@icomera.com>
If the selected ARCH is dual-bitness (eg. supports 32- and 64-bit),
then we need to know the correct place where to fetch some headers.
Currently, this applies only to x86 variants: i386 and x86_64.
Trying to download every extension in turn does not work.
The Debian server returns a friendly 404-page that is
saved as the orig.tar.bz2 file. Help the helper by giving
it the extension to retrieve.
From this version of ltrace the maintainer has removed support for
GNU Autotools, so the patch sets needed to be reworked.
Included is the latest Debian patch, by the Debian ltrace maintainer
Juan Cespedes <cespedes@debian.org>, the OpenEmbedded patches for cross
compiling, by Khem Raj <raj.khem@gmail.com> and a further set of patches
by Joachim Nilsson <jocke@vmlinux.org> for crosstool-NG.
Using this: tar cf - -C "/some/place" |tar xf - -C "/some/other/place"
to copy a directory to another place does not properly fail (when it does).
Using this instead: cp -av "/some/place" "/some/other/place"
makes it easy to see why and how it failed.
Impacted:
libc/uClibc
debug/ltrace
tools/sstrip
scripts/populate
In case the remote file does not exist (and probably for some
other reasons as well), aria2 nonetheless creates an empty file
(or not empty for some other reasons).
The solution is to delete the file whenever aria2 fails.
aria2 is a powerfull downloader that is capable of chunking and
parallel retrieval.
Due to li;itations in crosstool-NG retrieval facilities, it's not possible
to take fully advantage of aria2. It might happen that, in the future,
those limitations get lifted away, so we can take use features such as
parallel downloading from more than one server at the same time. For now,
it should still speed up downloads thanks to parallel downloading of chunks.
The user shall provide a directory to install the toolchain into.
If he/she does not, this is an error, and shall be detected properly,
rather than relying on failure down the road.
Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out
the issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html
Warn about a missing local tarball directory, only if it was configured.
Avoid the spurious message:
Directory '${CT_LOCAL_TARBALLS_DIR}' does not exist.
Will not save downloaded tarballs to local storage.
Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out the
issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html
Don't select unneeded config knobs. Don't select non-existing config knobs.
Use the "no patch" config knob, instead of pointing to an non-exiting local
patch dir. Simplify the tuple-related scripts. Update the samples.
When renumbering patches, the original patches get removed and replaced
with the new ones. This can be annoying to loose the original patches.
Fix this by putting the new patchs in a directory of their own.
Add config option to build wtarget code with THUMB interworking.
This is used to build the C library as well as all other code
that runs on the target.
The newlib "team" rolls new releases about once a year (december).
This is quite a long time between releases, in case code was fixed.
So, allow user to use a CVS snapshot to benefit early from fixes
and enhancements to newlib.
Some projects' module (eg. newlib) are checked-out into a sudirectory
rather than into their own directory. Handle this case in the CT_GetCVS
function.
newlib handles the build/host/target a bit differently as one would expect:
build : not used
host : the nachine that builds newlib
target : the machine on which newlib will run
Some patchsets have superfluous members in their names (eg. the ones coming
from Gentoo), so it can come in handy to pass a sed RE to strip them out of
the final patch name.
Also add a 'fake' mode, where the command will only be printed and not
executed, so we can check beforehand if the rename will be OK.
ncurses is built solely for the sake of building a native gdb.
The user should not rely on this library to build his/her userland,
but should rather build his/her own. So we remove it from the
sysroot after we successfully build the native gdb.
The option to retrieve snapshots is already handled by
the generic 'specific date' and 'use latest' entries.
No need for a special case, as there's no code for it.
For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
For any later versions, the driectory name does have the version, such as
cloog-ppl-0.15.4.
For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
For any later versions, the driectory name does have the version, such as
cloog-ppl-0.15.4.
Add the WRAPPER_NEEDED silent config option, that can be selected by
components that require it (companion libs so far).
Rely on this config option when deciding to install the wrapper,
instead of checking GMP/MPFR or PPL/CLoog/MPC.
Add an initial wrapper:
- find the realpath of the tool being called
- add the '.' in front of the tool name
- add the '/lib' dir to the base dir of the tool
- set and export LD_LIBRARY_PATH
- execve the real tool
Downoading a non-existing file from sourceforge gives you a "200 OK"
and an index.html. As we try to retrieve a .tar.bz2 first, and duma
is bundled in a .tar.gz, we won't get appropriate content, so
just force the extension to avoid the problem.
Thanks to Ingmar Schraub <is@eseco.de> for pointing out the issue.
During the conversion to using bash arrays, the glibc build script
was improperly converted, and contains an incorrect variable
assignment to the config_options array.
For every components where it makes sense, use bash arrays (instead
of a string with space-separated values) to store the options pased
to ./configure.
Rewrite part of the code to better match the rest.
Most notably, rewrite handling of:
if [ ... ] && [ ... ]
to:
if [ ... -a ... ]
This has the positive side effect of calling "[" only once, although
"[" is probably a shell built-in.
To test for existing files, use "[ -f blabla ]", not "[ -a blabla ]"
Checking for a file exsitence with "-a" is a bashism.
Althoug we _are_ using bash, it's disturbing as it can be misread as
the 'and' operator. Fix by using "-f".
The tmul test uses a compiled-in input file in $(srcdir).
The problem is that the Makefile passes it unquoted. The C code
tries to stringify it using clever macros, which may *usually* work.
In my case the source directory was named:
.../toolchain-powerpc-e500v2-linux-gnuspe-1.0-2.fc10/.../tests
And guess what? During testing I found out the program fails because
it tries to open:
.../toolchain-powerpc-e500v2-1-gnuspe-1.0-2.fc10/.../tests
Yes, CPP tokenized the macro before stringifying it and not surprisingly
the 'linux' part was converted to 1.
[on Fedora-10: cpp (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)]
So the attached patch simplify the macros and pass the path as string
from the Makefile.
In case the shell the user wants to use as CONFIG_SHELL is located in a
weird place (eg. /opt/bash/bin/bash), or is weirdly named (eg. bash-4),
let the user enter the patch to the shell.
The wrapper script placed around the target binaries when
using the companion libraries does not work for symbolic links
The wrapper scripts needs to follow the links before calling the
actual binary
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
---
- save the canadian smples in their own way, so as not to
mix non-canadian samples with canadian ones
- list canadian samples with the host information
Add implementation for a candadian build option already
present in crosstool in order to build a cross-compiler
where build != host != target
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
Prepare saving canadian samples by making the saveSample.sh script
a little bit more generic, using conditional code-paths (even if
there's currently a single code-path).
Collect the build tools in a seperate folder in order to prevent accidental
calling our newly build tools.
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
Once we have canadian in place, Mingw32 can be a legitimate host,
so we have to recognise that along with Cygwin.
Also fix recognising Cygwin hosts.
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
The symbol link that is created in the sysroot directory only needs
to be made when the cross compiler is build with the sysroot option
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
In the non-sysroot-ed case, the debuf-root directory would not be set;
debug tools would have been installed God-only-knows-where...
Spotted by Bart van der Meulen <bartvdrmeulen@gmail.com>.
Spaces are evil in paths. Print the path that contains a sapce.
Don't print computed paths, as they'rebased on provided paths,
and don't get space added into them.
The dynamic linker, ld.so, needs the execute bit to be set.
Detect tht the library being installed is in fact ld.so and
install it with 0755 instead of 0644.
Fix detecting src == dst.
Use a simpler command to copy src -> dst.
Also change echo to printf, get rid of 'echo -n', which is
highly non-portable.
-------- diffstat follows --------
/trunk/scripts/populate.in | 76 43 33 0 +++++++++++++++++++++++++++++-----------------------
1 file changed, 43 insertions(+), 33 deletions(-)
They have nothing to do in here, just let the user
configure his/her system appropriately.
-------- diffstat follows --------
/trunk/scripts/build/libc/eglibc.sh | 1 0 1 0 -
/trunk/scripts/functions | 100 0 100 0 -----------------------------
/trunk/config/global/download.in | 148 0 148 0 -------------------------------------------
3 files changed, 249 deletions(-)
- introduce the config dir, where components can store their config files
- move the munged uClibc config file to the config dir
- now, the state dir really is an indication that a build can be restarted
Thanks to Groleo Marius <groleo@gmail.com> for spotting the inconsistency
of the state dir usage, and suggesting this change.
/trunk/scripts/build/libc/uClibc.sh | 6 3 3 0 +++---
/trunk/scripts/crosstool-NG.sh.in | 9 7 2 0 +++++++--
/trunk/scripts/functions | 15 12 3 0 ++++++++++++---
3 files changed, 22 insertions(+), 8 deletions(-)
Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html
It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest
release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest
snapshot of GCC 4.4.0 (as of March 20, 2009).
We have successfully built linux kernel 2.6.29 and a lot of other stuff
with this toolchain.
Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to
download a 4.4.0 snapshot from ftp.
Patch was adpated by me, mostly to better fit the configuration layout.
/trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------
/trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 17 deletions(-)
- find the executables extension (needed under some OS, like Winblows)
- build tic in //
- simplify the make and install command lines
/trunk/scripts/build/debug/300-gdb.sh | 10 7 3 0 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Seems ncurses 5.7 need build host stage for tic step; if use host tic
(ubuntu) the build process hang in the below step.
So I guess need to build ncurses host stage to build new tic
and provided a patch to that efect.
And in fact, we do need "tic" to run on the _build_ system to properly
generate the terminfo database.
Note: this is fully functional, but still requires a litle bit of
tweaking so that ${CT_BUILD}-gcc gets used instead of plain gcc.
But that's a minor problem for now...
/trunk/scripts/build/debug/300-gdb.sh | 35 33 2 0 +++++++++++++++++++++++++++++++++--
/trunk/scripts/build/internals.sh | 1 1 0 0 +
2 files changed, 34 insertions(+), 2 deletions(-)
- recently, tarballs for glibc 2.8 and 2.9 have appeared on the GNU ftp site
- always use a dot in version strings (eg. 2.9, not 2_9)
/trunk/scripts/build/libc/glibc.sh | 135 76 59 0 +++++++++++++++++++++++++-------------------
/trunk/config/libc/glibc.in | 71 45 26 0 +++++++++++++++--------
2 files changed, 121 insertions(+), 85 deletions(-)
"chmod u+w" the full src tree: because of nochdir and cvs snapshots, we can't reliably know were we are...
/trunk/scripts/functions | 11 3 8 0 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
- look at the patch directory when using svnversion, not at current directory
- some code beautification.
/trunk/scripts/patch-renumber.sh | 9 7 2 0 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
It at least helps powerpc64 to build, and should innocuous to other archs.
/trunk/scripts/crosstool-NG.sh.in | 8 6 2 0 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
It now requires that "./configure && make" be run beforehand.
/trunk/scripts/patch-renumber.sh | 6 5 1 0 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
It now requires that "./configure && make" be run beforehand.
/trunk/scripts/addToolVersion.sh | 10 7 3 0 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
- fix Makefile to really, really not used built-in rules and variables
- have scripts/crosstool-NG.sh generated from scripts/crosstool-NG.sh.in
- create a bin-overide directory ( in ${CT_WORK_DIR}/bin ) that contains shell wrappers to the actual discovered tools
/trunk/scripts/crosstool-NG.sh.in | 27 23 4 0 +++++++++++++++++++++---
/trunk/Makefile.in | 50 48 2 0 +++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 71 insertions(+), 6 deletions(-)
The glibc.sh script doesn't handle the glibc versions with
an underscore very well (bash expected integer error). I
have attached a small patch for that. Instead of looking
for "not period" I changed the sense to look for numbers.
I initially tried to make it look for either a period or
an underscore, but that didn't work like I wanted (probably
because I did something wrong).
Original patch modified to be more robust.
/trunk/scripts/build/libc/glibc.sh | 8 4 4 0 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
... I added a step after
"debug" called "finish", and moved the code in crosstool.sh
after the loop that processes the steps from crosstool.sh
into a do_finish function in functions. Thus, it is now
possible to restart after the "debug" step to re-do the
final few things (clean and compress).
/trunk/scripts/crosstool-NG.sh | 38 0 38 0 --------------------------------------
/trunk/scripts/functions | 42 42 0 0 ++++++++++++++++++++++++++++++++++++++++++
/trunk/steps.mk | 3 2 1 0 ++-
3 files changed, 44 insertions(+), 39 deletions(-)
On 20090115.0012+0100, "Andy Johnson" <ajohnson@aecno.com> wrote:
ltrace wouldn't build on PowerPC because in the
sysdeps/linux-gnu directory in the ltrace source tree
the powerpc directory is called ppc. I added some code
in 400-ltrace.sh to create a symlink for it so it will
build now.
Patch slightly modified by me before applying.
/trunk/scripts/build/debug/400-ltrace.sh | 5 5 0 0 +++++
1 file changed, 5 insertions(+)
After all, this is not crosstool, but really crosstool-NG!
/trunk/steps.mk | 2 1 1 0 +-
/trunk/ct-ng.in | 2 1 1 0 +-
2 files changed, 2 insertions(+), 2 deletions(-)
- don't remove directories in the background:
- it is highly dangerous
- it can lead to data loss in case of frequent stop/restart with a slow disk
- log actions with CT_DoExecLog as much as possible, instead of using |CT_DoLog
/trunk/scripts/crosstool.sh | 100 43 57 0 ++++++++++++++++++++++-----------------------------
1 file changed, 43 insertions(+), 57 deletions(-)
Andy JOHNSON wrote:
The Java compiler for GCC versions 4.3.0 and up requires the
Eclipse compiler "ecj1" to be built as well. I added "gcj" to
the list of utilities to make the initial link.
/trunk/scripts/build/cc/gcc.sh | 12 12 0 0 ++++++++++++
/trunk/scripts/crosstool.sh | 2 1 1 0 +-
/trunk/config/cc/gcc.in | 6 6 0 0 ++++++
3 files changed, 19 insertions(+), 1 deletion(-)
- DUMA separates its name from its version with an underscore, not with a dash.
/trunk/scripts/build/debug/200-duma.sh | 3 2 1 0 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
- renaming the dircetory in CT_ExtratAndPatch is wrong:
- patches against the C library addons may be build against the short *or* long name... :-(
- symlink is more robust, even if less nice
- renaming the directory _after_ CT_ExtractAndPatch is too late:
- if patches are against the short name, and we renamed too the long name, patches don't apply
- so we'll never reach the point where we rename
/trunk/scripts/build/libc/glibc.sh | 1 0 1 0 -
/trunk/scripts/build/libc/eglibc.sh | 1 0 1 0 -
/trunk/scripts/functions | 2 1 1 0 +-
3 files changed, 1 insertion(+), 3 deletions(-)
CT_LIBC_FILE:
- that one was not easy, as it had sneaked into CT_ExtractAndPatch
- which in turn made CT_ExtractAndPatch have references to C library addons
- which in turn relieved the C library _extract functions from doing their own job
- which in turn imposed some nasty tricks in CT_ExtractAndPatch
- which in turn made life easier for the DUMA _get and _extract functions
- which unveiled some bizare behavior for pushd and popd:
- if using smthg ike: 'pushd foo |bar':
- the directory is *neither* changed
- *nor* is it pushed onto the stack
- which made popd fail
CT_MakeAbsolutePath:
- used only to make CT_LOCAL_TARBALLS_DIR canonical
- which is ((almost) useless:
- hopefully, the user entered a full path already
- if it's not the case, too bad...
/trunk/scripts/build/debug/200-duma.sh | 5 1 4 0 +--
/trunk/scripts/build/libc/glibc.sh | 61 32 29 0 +++++++++++++++++---------------
/trunk/scripts/build/libc/uClibc.sh | 16 10 6 0 +++++---
/trunk/scripts/build/libc/eglibc.sh | 48 26 22 0 ++++++++++++++-----------
/trunk/scripts/crosstool.sh | 8 0 8 0 ----
/trunk/scripts/functions | 77 15 62 0 ++++++++--------------------------------
6 files changed, 84 insertions(+), 131 deletions(-)
- retrieve from local storage (CT_GetLocal)
- save to local storage (CT_SaveLocal)
- retrieve from CVS (CT_GetCVS)
- make CT_GetFile and CT_GetCVS use CT_GetLocal and CT_SaveLocal
/trunk/scripts/functions | 126 91 35 0 +++++++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 91 insertions(+), 35 deletions(-)
- vendor and alias must not contain spaces
- vendor must not contain dashes '-'
- sed_expr must not generate an alias with a space in it
/trunk/scripts/functions | 17 16 1 0 ++++++++++++++++-
/trunk/config/toolchain.in | 1 1 0 0 +
2 files changed, 17 insertions(+), 1 deletion(-)
- Not only will it give us full-qualified tuples, but it will also ensure
that they are valid tuples (in case of typo with user-provided tuples)
That's way better than trying to rewrite config.sub ourselves...
- use CT_BUILD_PREFIX and CT_BUILD_SUFFIX to call "gcc -dumpmachine"
/trunk/scripts/crosstool.sh | 29 7 22 0 +++++++----------------------
1 file changed, 7 insertions(+), 22 deletions(-)
- this is not really used yet, as only the iberty and bfd libraries are built
- if we ever are to build the full binutils for the target, then it is already configured to use the target GMP and MPFR.
/trunk/scripts/build/binutils.sh | 7 7 0 0 +++++++
1 file changed, 7 insertions(+)
- Use shell wrappers to point to the build tools, rather than symlinks.
/trunk/scripts/crosstool.sh | 20 14 6 0 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
Original patch by Thomas PETAZZONI, with soe improvement by myself.
/trunk/scripts/build/libc/uClibc.sh | 10 9 1 0 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
We need GNU Awk? Then check for, and use 'gawk', not plain 'awk'.
Be a little mre verbose if a tool was not found.
/trunk/configure | 7 4 3 0 ++++---
/trunk/scripts/build/kernel/linux.sh | 2 1 1 0 +-
/trunk/scripts/functions | 16 8 8 0 ++++++++--------
/trunk/scripts/saveSample.sh | 4 2 2 0 ++--
4 files changed, 15 insertions(+), 14 deletions(-)
This helps those who want to relocate their toolchains later.
Reported by Nye Liu: http://sourceware.org/ml/crossgcc/2008-10/msg00093.html
/trunk/scripts/build/cc/gcc.sh | 2 1 1 0 +-
1 file changed, 1 insertion(+), 1 deletion(-)
- copy sources to build directory, as it does not build out-of-tree
- add a patch to make it build for non *-linux-gnu host tuples
- add a patch to make it cross-build correctly
/trunk/patches/ltrace/0.4/100-fix-build-with-exotic-linux-host-OS.patch | 26 26 0 0 +++
/trunk/patches/ltrace/0.4/110-allow-cross-compile.patch | 89 89 0 0 ++++++++++
/trunk/scripts/build/debug/400-ltrace.sh | 5 3 2 0 +
3 files changed, 118 insertions(+), 2 deletions(-)
- presence of the sample's reported.by file is now mandatory.
- when saving a sample, reporter name & URL are queried, to avoid operator forget about creating the reported.by file.
- when saving a sample, one can store a few-liner comment.
- when recalling a sample, the reporter name, URL and comment (if present) are printed.
- update the powerpc-e500v2-linux-gnuspe sample to include Nate's comment (from his original mail).
- update all samples that were missing the reported.by file.
/trunk/scripts/saveSample.sh | 46 35 11 0 ++++++++++++++++++------
/trunk/scripts/showSamples.sh | 12 6 6 0 +++---
/trunk/samples/powerpc-e500v2-linux-gnuspe/reported.by | 15 15 0 0 ++++++++
/trunk/samples/samples.mk | 22 17 5 0 +++++++++--
4 files changed, 73 insertions(+), 22 deletions(-)
On Tuesday 14 October 2008 16:48:07 Nate Case wrote:
> Keep CT_LOCAL_TARBALLS_DIR at the default setting of ${HOME}/src so that
> we don't save irrelevant paths in the samples.
/trunk/scripts/saveSample.sh | 1 1 0 0 +
1 file changed, 1 insertion(+)
On Tuesday 14 October 2008 16:27:37 Nate Case wrote:
> The saveSample.sh script is referring to the old architecture-specific
> script path. Point to the new one, just as done in crosstool.sh.
/trunk/scripts/saveSample.sh | 4 2 2 0 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
They are nonetheless in sync and need not be regenerated.
Fix that by touching the files to have 'make' believe they are up-to-date (which they are).
/trunk/scripts/build/libc/glibc.sh | 5 5 0 0 +++++
/trunk/scripts/build/libc/eglibc.sh | 7 6 1 0 ++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
It dates from dawn ages of the original crosstool code, and is not well explained. At that time, binutils might not understand the sysroot stuff, and it was necessary to remove absolute paths in that case.
/trunk/scripts/build/libc/glibc.sh | 14 2 12 0 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
- change the menu label from 'Target OS' to 'Operating System',
- bare-metal is a kind of kernel (OS), rename to 'bare-metal' from 'none',
- update the kconfig.mk to generate the kernel choice entries,
- update glibc&eglibc kernel version option accordingly.
Update the debug & tools confiog file generation to match with arch & kernel.
Print terse command lines when building in kconfig/ (a-la Linux kernel).
Fix the makefile rules in kconfig/kconfig.mk to be /simple/ rules.
/trunk/kconfig/kconfig.mk | 117 81 36 0 +++++++++++++++++++++----------
/trunk/config/kernel/linux.in | 4 4 0 0 +
/trunk/config/kernel/bare-metal.experimental.in | 15 15 0 0 ++++
/trunk/config/kernel.in | 33 5 28 0 +--------
/trunk/config/libc/glibc-eglibc-common.in | 4 2 2 0
5 files changed, 107 insertions(+), 66 deletions(-)
So, don't save the Linux kernel config file when saving a sample, there will never be such a file any longer.
/trunk/scripts/saveSample.sh | 13 0 13 0 -------------
1 file changed, 13 deletions(-)
Be a little less verbose when extracting (and patching) files.
/trunk/scripts/functions | 7 2 5 0 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
Use a little bit more of CT_DoExecLog.
/trunk/scripts/functions | 35 18 17 0 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
This is needed for some architectures to compile the Java frontend (eg. ARM with uClibc).
/trunk/config/cc/gcc.in | 41 39 2 0 +++++++++++++++++++++++++++++++++++++++--
/trunk/scripts/build/cc_gcc.sh | 8 5 3 0 +++++---
2 files changed, 44 insertions(+), 5 deletions(-)
PowerPC unveiled that you can't reliably build a target libgcc until you have C library headers.
In fact you can't build it at all. The fact that it did build for some architectures was purely coincidental, and a mistake.
This fix should still allow to build uClibc-based toolchains (some ARM uClibc toolchains were build-tested).
/trunk/scripts/build/cc_gcc.sh | 100 47 53 0 +++++++++++++++++++++++-------------------------
1 file changed, 47 insertions(+), 53 deletions(-)
Fix this by determining both the cross-readelf and the sys-root at runtime, not at build time.
/trunk/configure | 1 1 0 0 +
/trunk/scripts/crosstool.sh | 14 6 8 0 ++++++--------
/trunk/tools/populate.in | 6 4 2 0 ++++--
3 files changed, 11 insertions(+), 10 deletions(-)
On some distros (eg. Fedora), the native objdump can not interpret objects not for the native system, and thus fail.
This commit adds a new patch against glibc-2.7 that introduces OBJDUMP_FOR_HOST, wich, if set, overides the detected objdump.
Note: bizarely enough, glibc already has code to detect the cross-objdump, but that does not work for an unknown reason... :-(
/trunk/patches/glibc/2.7/220-objdump_for_host.patch | 13 13 0 0 +++++++++
/trunk/scripts/build/libc_glibc.sh | 37 21 16 0 +++++++++++++++------------
2 files changed, 34 insertions(+), 16 deletions(-)
- symlink all lib64/ dirs to the corresponding lib/ dir
Also, prevent gcc from installing some of its target libs outside of the sys-root, in the first place.
Thanks to Laurent DUFRECHOU for reporting the bug and testing the fix.
/trunk/scripts/build/cc_gcc.sh | 26 0 26 0 --------------------------
/trunk/scripts/crosstool.sh | 14 14 0 0 ++++++++++++++
2 files changed, 14 insertions(+), 26 deletions(-)
Thanks to both Ioannis E. VENETIS and Thomas JOURDAN for their help.
/trunk/scripts/build/cc_gcc.sh | 26 22 4 0 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
Move the check for 'lynx' to where it is needed (that is when sstrip from buildroot is selected).
/trunk/scripts/build/tools/200-sstrip.sh | 1 1 0 0 +
/trunk/scripts/crosstool.sh | 5 0 5 0 -----
2 files changed, 1 insertion(+), 5 deletions(-)
Simplify CT_DoExecLog: it does not support affectations prior to the command, anyway.
/trunk/scripts/functions | 5 1 4 0 +----
1 file changed, 1 insertion(+), 4 deletions(-)
Turned out that none could use GMP and MPFR as the config option changed its name, but the change was not propagated to all users.
/trunk/scripts/build/binutils.sh | 2 1 1 0 +-
/trunk/scripts/build/debug/300-gdb.sh | 2 1 1 0 +-
/trunk/scripts/build/cc_gcc.sh | 6 3 3 0 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
Get rid of this by using printf(1) with no trailing new-line (\n).
Again, thanks to Martin GUY, who pointed this issue.
/trunk/kconfig/kconfig.mk | 2 1 1 0
/trunk/scripts/build/libc_uClibc.sh | 4 3 1 0 ++
/trunk/scripts/showSamples.sh | 78 39 39 0 +++++++++++++++++++++---------------------
3 files changed, 43 insertions(+), 41 deletions(-)
add a config knob to configure the native gdb to use or not to use GMP and
MPFR; _this_config_knob_ will force building the target GMP and MPFR only if
turned on.
/trunk/scripts/build/debug/300-gdb.sh | 2 1 1 0 +-
/trunk/config/debug/gdb.in | 21 19 2 0 +++++++++++++++++++--
2 files changed, 20 insertions(+), 3 deletions(-)
Print the time at which at step was finished (along with the time it took to complete).
/trunk/scripts/functions | 7 5 2 0 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
- some (presumably 'old') versions have libduma.so.0.0, while others (presumably 'newer') have libduma.so.0.0.0
- don't build the libraries multiple times, do it in one pass
- install a custom LD_PRELOAD wrapper
/trunk/scripts/build/debug/200-duma.sh | 54 33 21 0 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 33 insertions(+), 21 deletions(-)
