- 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(-)
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(-)
Work this around with a wrapper that always succeeds, and leave incomplete files in place.
/trunk/scripts/crosstool.sh | 7 7 0 0 +++++++
1 file changed, 7 insertions(+)
Consider the proxy has to be in a 'local' network. It means it is directly
reachable by the local machine, even if the local machine has to hop through
one or more gates to reach the proxy (often the case in enterprise networks
where class A 10.0.0.0/8 is in fact sub-divided into smaller networks, each
one of them in a different location, eg. 10.1.0.0/16 in a place, while
10.2.0.0/16 would be on the other side of the world). Not being in the same
subnet does not mean the proxy is not available.
So we will build a mask with at most high bits set, which defines a network
that has both the local machine and the proxy. Because a machine may have
more than one interface, build a mask for each of them, removing 127.0.0.1
which is added automagically by tsocks, and removing duplicate masks.
If all of this does not work, then it means the local machine can NOT in fact
reach the proxy, which in turn means the user mis-configured something (most
probably a typo...).
/trunk/scripts/crosstool.sh | 61 52 9 0 +++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 52 insertions(+), 9 deletions(-)
- a machine may well be able to reach the proxy, even if it is not on the same sub-net(s) as the machine itself (absolutely legitimate)
- tsocks.conf needs a list of so-called 'local' networks that can be reached without the need for a SOCKS connection
- SOCKS proxies are expected to be in 'local' networks
- there is absolutely NO way to tell what networks are local, besides the sub-net(s) the machine is in
Therefore, appropriate configuration of SOCKS 4/5 configuration is really complex, and attempts to correctly overcome this issue are doomed.
/trunk/scripts/crosstool.sh | 52 46 6 0 ++++++++++++++++++++++++++++++++++----
/trunk/config/global/download_extract.in | 39 31 8 0 +++++++++++++++++++++++------
2 files changed, 77 insertions(+), 14 deletions(-)
As for the HTTP proxy, this is completetly untested, as I have no such proxy at home.
scripts/crosstool.sh | 45 31 14 0 +++++++++++++++++--------
config/global.in | 95 81 14 0 +++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 112 insertions(+), 28 deletions(-)
Rationale:
Most of the time, soft-float problems are caused by this sucker of gcc:
it has support for soft float for all of the targets I've tried so far,
but does not activate this code until you dwelve into half a dozen of
files to make it accept to build and link the support code...
So, yes: gcc has soft-float support. And again, yes: gcc is a sucker.
Homogenise the references to crosstool-NG:
- the project is named "crosstool-NG"
- the front-end is named "ct-ng"
- don't use shortcuts (such as "ct-ng" to stand for "crosstool-NG")
Default action is to print help.
Don't speak of make rules when dumping help, just speak of actions.
