Here's a couple of patches to get strace 4.5.19 to configure and build
properly with the latest kernel headers. Not pretty, but hopefully
enough while we wait for 4.5.20 to be released.
With the current strace-4.5.19 patches I failed to get the configure
script running even on my host environment. Also, when cross building
the configure script needs to look for the proper system headers to be
able to properly set HAVE_LINUX_NETLINK_H. Otherwise you get:
[EXTRA] Building strace
[ERROR] /home/jocke/x-tools/targets/src/strace-4.5.19/net.c:976:
error: field 'nl' has incomplete type
[ERROR] make[2]: *** [net.o] Error 1
[ERROR] make[1]: *** [all] Error 2
The fix was simple, backport a change set from the git[1] tree and run
autoreconf to update the configure script.
[1] - http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commit;h=f0df31e71a58c6e79ba77c1a9d84b2f38d44bec7
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.
grep is used when generating some .in files (in config.gen). If GREP_OPTIONS
contains --color=always, then the generated files will contains some escape
sequences setting the color, and mconf would choke on those escape sequences.
Always set and export an empty GREP_OPTIONS to avoid that.
Issue reported by Kevin Kirkup <kevin dot kirkup at gmail dot com> :
http://sourceware.org/ml/crossgcc/2009-12/msg00026.html
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
In case the user specifies the LIBDIR with --libdir , or DOCDIR with
--docdir, install our support files in a sub-dir, so as not to mangle
existing (potentially system) files/dirs.
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.
Woo... It seems the glibc guys finally decided that tarballs
were not deprecated, in fact.
The patchset was vampirised from Gentoo (kudos, guys!), and
applies to glibc+ports, so that's why it's been added as a
patchset against ports, not against glibc.
Fix filenames in patch files for binutils-2.20.
Some patch files were only usable with patch argument '-p0'.
Fix the diff context to match 2.20 release.
Signed-off-by: Frederic Roussel <fr.frasc@gmail.com>
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.
While trying to build a toolchain with ct-ng 1.5.0,
arm-unknown-linux-uclibcgnueabi target,
I get the following error:
[INFO ] Installing C library headers
[EXTRA] Copying sources to build dir
[EXTRA] Applying configuration
[EXTRA] Building headers
[EXTRA] Installing headers
[ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
[ERROR] make[2]: *** [extra/scripts/unifdef] Error 1
[ERROR] Build failed in step 'Installing C library headers'
The following patch solves the problem.
(It's a backport of this uClibc commit:
http://git.uclibc.org/uClibc/commit/?id=49e81cada73616864b9b31df0aeb6961c30f5a6e
)
[--SNIP from another mail--]
AFAIK this is a problem since glibc 2.10.
