Re: --without-local-prefix Does Not Work

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

Jeffrey A Law wrote:

> You can do four things with local_prefix:
>
>   a. --with-local-prefix=yes  which generates an error.
>
>   b. --with-local-prefix=no   which gives you the default value.
>
>   c. --with-local-prefix=somepath which will set local_prefix to
>      whatever path you select.
>
>   d. Do nothing and you end up with the default value.  Effectively
>   the same as "b" above.
>
> Specifying "no" does not disable the use of local_prefix, nor should
> it.  The fact that it did so in earlier snapshots/releases was a bug.
>

Why? Could you please be a bit more specific?

>
>
>
> One could argue that =no should give an error.  I don't remember the
> rationale behind not generating an error for that.
>

So the default is to silently set it to /usr/local, isn't it?

This produces trouble for me in two cases:

1. Our  amd-based network, machines don't have /usr/local (intentionally removed
by the sysadmin). With egcs silently adding /usr/local/include to the include
path, each invocation of gcc and friends contacts amd to resolve
/usr/local/include. - A secure way to produce heavy traffic on a network.

2. On one linux/libc1 box, I have glibc2 as secondary libc and a glibc2-based egcs
installed under an arbitrary path. Now this glibc2 based egcs contains
/usr/local/include/ in its include path, which contains include files of glibc1
libraries, not being installed for glibc2.

One alternative I see to circumvent these problems is to manually redirect
local_prefix to an arbitrary directory ($prefix/local/include or $prefix/include,
but who knows which kind of trouble will result from this).

Perhaps I didn't read the docs carefully enough, but I think there should be way
to disable it.

Additional question: What is the default for local_prefix or how is it treated for
cross-compilers? AFAIS, it gets disabled. I.e. disabling local_prefix seems to be
legal for cross-compilers.


Ralf