... and then use the right option. See the note in scripts/functions
on where we should use ${foo} and where just 'foo'; this boils down to
whether we can expect the build tools override to be in effect (e.g. in
the actual build scripts) or not (i.e. outside of scripts/build).
While running in scripts/functions, or in scripts/crosstool-NG.sh the
build tools override directory (.build/tools/bin) may have not been
set up (yet, or at all).
Also, modify the installed scripts (populate, xldd) accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
We check for apps:
* make
* sed
* grep
* awk
* libtool/libtoolize
* install
* patch
* and more
...during configure. Our scripts should be consistent about using the
variables that define where the found tool was found.
Of course, we do hard-link these tools in buildtools, but that should be
a backup for the components we are building. Our scripts should always
use the tools we find.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The gconv modules are present in the (e)glibc toolchains, and some
applications directly link with one or more of those modules (even
though the classic way of using them is by dlopen()ing them).
So, also look in /usr/lib/gconv when searching for libraries.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The output format of the file(1) command have changed since (at least)
the version 5.14. We need to to take care of an extra space.
Signed-off-by: Jean-Marie Lemetayer <jeanmarie.lemetayer@gmail.com>
[yann.morin.1998@free.fr: do not right-shift trailing back-slashes]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Autoconf can determine that the correct install command includes flags,
e.g., "/usr/bin/install -c". When using this as a command, we can't
enclose the value in double-quotes, as that makes some shells use the
whole expression as a filename:
# this is the value returned by autoconf and stored in CT_install
$ ins="/usr/bin/install -c"
# if we call it with quotes, the command is not found
$ "${ins}"
bash: /usr/bin/install -c: No such file or directory
# removing the quotes lets it work as expected
$ ${ins}
/usr/bin/install: missing file operand
Try `/usr/bin/install --help' for more information.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
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>
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>
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
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(-)
