Configure tsocks with a simple heuristic.
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(-)
1 # Target definition: architecture, optimisations, etc...
5 comment "General target options"
9 default "arm" if ARCH_ARM
10 default "ia64" if ARCH_IA64
11 default "mips" if ARCH_MIPS
12 default "sh" if ARCH_SH
13 default "x86" if ARCH_x86
14 default "x86_64" if ARCH_x86_64
18 prompt "Target architecture:"
24 select ARCH_SUPPORTS_BOTH_ENDIAN
25 select ARCH_DEFAULT_LE
29 prompt "ia64 (EXPERIMENTAL)"
30 depends on EXPERIMENTAL
31 select ARCH_SUPPORTS_BOTH_ENDIAN
36 select ARCH_SUPPORTS_BOTH_ENDIAN
37 select ARCH_DEFAULT_BE
41 prompt "sh (EXPERIMENTAL)"
42 depends on EXPERIMENTAL
43 select ARCH_SUPPORTS_BOTH_ENDIAN
44 select ARCH_DEFAULT_LE
56 config ARCH_SUPPORTS_BOTH_ENDIAN
60 config ARCH_DEFAULT_BE
64 config ARCH_DEFAULT_LE
71 depends on ARCH_SUPPORTS_BOTH_ENDIAN
72 default ARCH_BE if ARCH_DEFAULT_BE
73 default ARCH_LE if ARCH_DEFAULT_LE
81 prompt "Little endian"
85 # Include architecture-specific configuration
87 source config/arch/arm/config.in
90 source config/arch/ia64/config.in
93 source config/arch/mips/config.in
96 source config/arch/sh/config.in
99 source config/arch/x86/config.in
102 source config/arch/x86_64/config.in
105 comment "Target optimisations"
109 prompt "Architecture level"
112 GCC uses this name to determine what kind of instructions it can emit
113 when generating assembly code. This option can be used in conjunction
114 with or instead of the ARCH_CPU option (above), or a (command-line)
117 This is the configuration flag --with-arch=XXXX, and the runtime flag
120 Pick a value from the gcc manual for your choosen gcc version and your
123 Leave blank if you don't know, or if your target architecture does not
128 prompt "Generate code for the specific ABI"
131 Generate code for the given ABI.
133 This is the configuration flag --with-abi=XXXX, and the runtime flag
136 Pick a value from the gcc manual for your choosen gcc version and your
139 Leave blank if you don't know, or if your target architecutre does not
144 prompt "Emit assembly for CPU"
147 This specifies the name of the target processor. GCC uses this name
148 to determine what kind of instructions it can emit when generating
151 This is the configuration flag --with-cpu=XXXX, and the runtime flag
154 Pick a value from the gcc manual for your choosen gcc version and your
157 Leave blank if you don't know, or if your target architecture does not
162 prompt "Tune for CPU"
165 This option is very similar to the ARCH_CPU option (above), except
166 that instead of specifying the actual target processor type, and hence
167 restricting which instructions can be used, it specifies that GCC should
168 tune the performance of the code as if the target were of the type
169 specified in this option, but still choosing the instructions that it
170 will generate based on the cpu specified by the ARCH_CPU option
171 (above), or a (command-line) -mcpu= option.
173 This is the configuration flag --with-tune=XXXX, and the runtime flag
176 Pick a value from the gcc manual for your choosen gcc version and your
179 Leave blank if you don't know, or if your target architecture does not
184 prompt "Use specific FPU"
187 On some targets (eg. ARM), you can specify the kind of FPU to emit
190 This is the configuration flag --with-fpu=XXX, and the runtime flag
193 See below wether to actually emit FP opcodes, or to emulate them.
195 Pick a value from the gcc manual for your choosen gcc version and your
198 Leave blank if you don't know, or if your target architecture does not
203 prompt "Floating point:"
207 prompt "hardware (FPU)"
209 Emit hardware floating point opcodes.
211 If you've got a processor with a FPU, then you want that.
212 If your hardware has no FPU, you still can use HW floating point, but
213 need to compile support for FPU emulation in your kernel. Needless to
214 say that emulating the FPU is /slooowwwww/...
216 One situation you'd want HW floating point without a FPU is if you get
217 binary blobs from different vendors that are compiling this way and
218 can't (don't wan't to) change.
224 Do not emit any hardware floating point opcode.
226 If your processor has no FPU, then you most probably want this, as it
227 is faster than emulating the FPU in the kernel.
233 prompt "Target CFLAGS"
236 Used to add specific options when compiling libraries of the toolchain,
237 that will run on the target (eg. libc.so).
239 Note that the options above for CPU, tune, arch and FPU will be
240 automaticaly used. You don't need to specify them here.
242 Leave blank if you don't know better.