Re: Suggestion for --with-local-prefix configure option

Re: Suggestion for --with-local-prefix configure option

[Mike Stump]

> From: fheitka@ibm.net
> Date: Wed, 17 Mar 1999 06:55:12 -0500

> Lately, I've been inclined to put binutils and egcs binaries in their own
> directory like: --prefix=/usr/egcs-m68k-glibc2.1

> Is there any problems with this?

Yes, you forgot the egcs version number in the path name.  Include it,
even if you don't want to.

If you must have a non-version path name, sym link over to a versioned
one.

Re: Suggestion for --with-local-prefix configure option

[David Starner]

Mike Stump wrote:
> 
> > From: fheitka@ibm.net
> > Date: Wed, 17 Mar 1999 06:55:12 -0500
> 
> > Lately, I've been inclined to put binutils and egcs binaries in their own
> > directory like: --prefix=/usr/egcs-m68k-glibc2.1
> 
> > Is there any problems with this?
> 
> Yes, you forgot the egcs version number in the path name.  Include it,
> even if you don't want to.
> 
> If you must have a non-version path name, sym link over to a versioned
> one.

Why? I've always used --prefix=/usr/local/egcs and simlinked into
/usr/local/bin as gcc-ss. Is there really a problem with this, as long
as I only want the two versions?
-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Suggestion for --with-local-prefix configure option

[David Starner]

Mike Stump wrote:
> 
> > From: fheitka@ibm.net
> > Date: Wed, 17 Mar 1999 06:55:12 -0500
> 
> > Lately, I've been inclined to put binutils and egcs binaries in their own
> > directory like: --prefix=/usr/egcs-m68k-glibc2.1
> 
> > Is there any problems with this?
> 
> Yes, you forgot the egcs version number in the path name.  Include it,
> even if you don't want to.
> 
> If you must have a non-version path name, sym link over to a versioned
> one.

Why? I've always used --prefix=/usr/local/egcs and simlinked into
/usr/local/bin as gcc-ss. Is there really a problem with this, as long
as I only want the two versions?
-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Suggestion for --with-local-prefix configure option

[Mike Stump]

> From: fheitka@ibm.net
> Date: Wed, 17 Mar 1999 06:55:12 -0500

> Lately, I've been inclined to put binutils and egcs binaries in their own
> directory like: --prefix=/usr/egcs-m68k-glibc2.1

> Is there any problems with this?

Yes, you forgot the egcs version number in the path name.  Include it,
even if you don't want to.

If you must have a non-version path name, sym link over to a versioned
one.

Re: Suggestion for --with-local-prefix configure option

[N8TM]

In a message dated 3/16/99 10:16:13 AM Pacific Standard Time, dm@reeducation-
labor.lcs.mit.edu writes:

> Currently the option always defaults to /usr/local,
>  regardless of --prefix.  I argue that this default is wrong for most
>  cases.

I'll present an inexpert but biased opinion.  I have no problem with the
/usr/local default.  I let the snapshots go in /usr/local on all systems where
I have the privilege to do so, without having to worry about whether it is a
workable version.  I install the "stable" releases in the primary compiler
location for the target, if I have privileges there.  The only target I use
where /usr/local is accessible to me and is on the standard search path is
HPUX.  But there, I have to play symlink games because there isn't any disk
space in the real /usr/local, not even enough to run applications which need
significant space on /tmp.

Re: Suggestion for --with-local-prefix configure option

[Jean-Pierre Radley]

N8TM@aol.com averred (on Tue, Mar 16, 1999 at 08:56:01PM -0500):
| In a message dated 3/16/99 10:16:13 AM Pacific Standard Time, dm@reeducation-
| labor.lcs.mit.edu writes:
| 
| I'll present an inexpert but biased opinion. 
  |
  who is 'I' ?

Do us the courtesy of putting your name in the GECOS field of
/etc/passwd, or if not, concocting a .signature file.

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: Suggestion for --with-local-prefix configure option

[Jean-Pierre Radley]

N8TM@aol.com averred (on Tue, Mar 16, 1999 at 08:56:01PM -0500):
| In a message dated 3/16/99 10:16:13 AM Pacific Standard Time, dm@reeducation-
| labor.lcs.mit.edu writes:
| 
| I'll present an inexpert but biased opinion. 
  |
  who is 'I' ?

Do us the courtesy of putting your name in the GECOS field of
/etc/passwd, or if not, concocting a .signature file.

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: Suggestion for --with-local-prefix configure option

[fheitka]

In < c37ea7d.36ef0bb1@aol.com >, on 03/16/99 
   at 08:56 PM, N8TM@aol.com said:

>In a message dated 3/16/99 10:16:13 AM Pacific Standard Time,
>dm@reeducation-
>labor.lcs.mit.edu writes:

>> Currently the option always defaults to /usr/local,
>>  regardless of --prefix.  I argue that this default is wrong for most
>>  cases.

>I'll present an inexpert but biased opinion.  I have no problem with the
>/usr/local default.  I let the snapshots go in /usr/local on all systems
>where I have the privilege to do so, without having to worry about
>whether it is a workable version.  I install the "stable" releases in the
>primary compiler location for the target, if I have privileges there. 
>The only target I use where /usr/local is accessible to me and is on the
>standard search path is HPUX.  But there, I have to play symlink games
>because there isn't any disk space in the real /usr/local, not even
>enough to run applications which need significant space on /tmp.

Lately, I've been inclined to put binutils and egcs binaries in their own
directory like: --prefix=/usr/egcs-m68k-glibc2.1 and make links to the
/usr/bin or /usr/local/bin directory.  This makes it much easier to keep
track of different versions.  Also if your are trying a new version, you
can just change the links.  I think this is a good way to install egcs. Is
there any problems with this?

Fred

Re: Suggestion for --with-local-prefix configure option

[fheitka]

In < c37ea7d.36ef0bb1@aol.com >, on 03/16/99 
   at 08:56 PM, N8TM@aol.com said:

>In a message dated 3/16/99 10:16:13 AM Pacific Standard Time,
>dm@reeducation-
>labor.lcs.mit.edu writes:

>> Currently the option always defaults to /usr/local,
>>  regardless of --prefix.  I argue that this default is wrong for most
>>  cases.

>I'll present an inexpert but biased opinion.  I have no problem with the
>/usr/local default.  I let the snapshots go in /usr/local on all systems
>where I have the privilege to do so, without having to worry about
>whether it is a workable version.  I install the "stable" releases in the
>primary compiler location for the target, if I have privileges there. 
>The only target I use where /usr/local is accessible to me and is on the
>standard search path is HPUX.  But there, I have to play symlink games
>because there isn't any disk space in the real /usr/local, not even
>enough to run applications which need significant space on /tmp.

Lately, I've been inclined to put binutils and egcs binaries in their own
directory like: --prefix=/usr/egcs-m68k-glibc2.1 and make links to the
/usr/bin or /usr/local/bin directory.  This makes it much easier to keep
track of different versions.  Also if your are trying a new version, you
can just change the links.  I think this is a good way to install egcs. Is
there any problems with this?

Fred

Re: Suggestion for --with-local-prefix configure option

[N8TM]

In a message dated 3/16/99 10:16:13 AM Pacific Standard Time, dm@reeducation-
labor.lcs.mit.edu writes:

> Currently the option always defaults to /usr/local,
>  regardless of --prefix.  I argue that this default is wrong for most
>  cases.

I'll present an inexpert but biased opinion.  I have no problem with the
/usr/local default.  I let the snapshots go in /usr/local on all systems where
I have the privilege to do so, without having to worry about whether it is a
workable version.  I install the "stable" releases in the primary compiler
location for the target, if I have privileges there.  The only target I use
where /usr/local is accessible to me and is on the standard search path is
HPUX.  But there, I have to play symlink games because there isn't any disk
space in the real /usr/local, not even enough to run applications which need
significant space on /tmp.

Suggestion for --with-local-prefix configure option

[David Mazieres]

The gcc/egcs --with-local-prefix configure argument seems to confuse a
lot of people, and the default generally seems wrong if --prefix is
something other than /usr/local.  --with-local-prefix specifies a
directory to search before the gcc-specific include files in
.../gcc-lib/...  Currently the option always defaults to /usr/local,
regardless of --prefix.  I argue that this default is wrong for most
cases.


Case 1:  The compiler is configured with --prefix=/usr.  In this case,
the compiler is being configured to be bundled with an operating
system or replace the bundled compiler.  In this case, the default for
--with-local-prefix should be NONE.

Having /usr/bin/cc search for include files in /usr/local/include by
default has a number of disadvantages.  First of all, having
/usr/local/include in the default include path isn't even all that
useful anyway if /usr/local/lib isn't in the default library search
path.  I've seen autoconf'ed packages search for a package just by
checking for headers.  These programs fail to link because configure
doesn't realize that -L/usr/local/lib was needed.  If local header
files are in fact available by default, then at lesat libraries should
be too.

Second of all, having /usr/local/include in the default include path
can potentially complicate life for anyone actually doing development
work on the operating system.  If I am working on parts of the
operating system (e.g. tools in /usr/bin) and they compile and work
with /usr/bin/cc, it would be nice to know I can commit the changes.
If /usr/local/include is always searched however, I never know if my
code only works because I happen to have a file /usr/local/include
that wasn't bundled with the operating system.


Case 2:  The compiler is being configured with a prefix other than
/usr or /usr/local.  For example, --prefix=/usr/local/egcs.  Here
again, searching /usr/local/include can be harmful.

I've seen sites where for example, someone installed one version of
gcc in /usr/local and one in /usr/local/gcc-2.8.1, without specifying
a local prefix.  These compilers worked for C code and so people
believed the installation was correct.  However,
/usr/local/gcc-2.8.1/c++ ended up getting the wrong g++ include files.
Any C++ code that included header files like <typeinfo> failed to
compile.


Conclusion:  I propose that the defaults for --with-local-prefix be
changed.  In the case that --prefix is /usr, the local-prefix should
be NONE.  In other cases it should be the same as prefix.

Reactions?  Please CC me on any replies, as I am not on the mailing
list.

Thanks,
David

Re: Suggestion for --with-local-prefix configure option

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On Mar 16, 1999, David Mazieres <dm@reeducation-labor.lcs.mit.edu> wrote:

> I've seen sites where for example, someone installed one version of
> gcc in /usr/local and one in /usr/local/gcc-2.8.1, without specifying
> a local prefix.  
[snip]
> /usr/local/gcc-2.8.1/c++ ended up getting the wrong g++ include files.

Wouldn't it search the local prefix only *after* its own prefix?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
*** E-mail about software projects will be forwarded to mailing lists

Re: Suggestion for --with-local-prefix configure option

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Mar 16, 1999, David Mazieres <dm@reeducation-labor.lcs.mit.edu> wrote:

> I've seen sites where for example, someone installed one version of
> gcc in /usr/local and one in /usr/local/gcc-2.8.1, without specifying
> a local prefix.  
[snip]
> /usr/local/gcc-2.8.1/c++ ended up getting the wrong g++ include files.

Wouldn't it search the local prefix only *after* its own prefix?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
*** E-mail about software projects will be forwarded to mailing lists

Re: Suggestion for --with-local-prefix configure option

[Bernd Eggink]

David Mazieres wrote:
> 
> The gcc/egcs --with-local-prefix configure argument seems to confuse a
> lot of people, and the default generally seems wrong if --prefix is
> something other than /usr/local. 

I confess I belong to the confused lot, and yes, I had trouble with the
include files. Specifically, I'd appreciate an advice how to set up the
prefixes when egcs is installed on a server. Clients only mount the base
directory and I don't always know what's in their /usr/local
directories, so I'd rather not have the client's directories searched at
all.

Will --with-local-prefix == --prefix be OK in that case?

Regards,
Bernd

--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html

Re: Suggestion for --with-local-prefix configure option

[Bernd Eggink]

David Mazieres wrote:
> 
> The gcc/egcs --with-local-prefix configure argument seems to confuse a
> lot of people, and the default generally seems wrong if --prefix is
> something other than /usr/local. 

I confess I belong to the confused lot, and yes, I had trouble with the
include files. Specifically, I'd appreciate an advice how to set up the
prefixes when egcs is installed on a server. Clients only mount the base
directory and I don't always know what's in their /usr/local
directories, so I'd rather not have the client's directories searched at
all.

Will --with-local-prefix == --prefix be OK in that case?

Regards,
Bernd

--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html

Suggestion for --with-local-prefix configure option

[David Mazieres]

The gcc/egcs --with-local-prefix configure argument seems to confuse a
lot of people, and the default generally seems wrong if --prefix is
something other than /usr/local.  --with-local-prefix specifies a
directory to search before the gcc-specific include files in
.../gcc-lib/...  Currently the option always defaults to /usr/local,
regardless of --prefix.  I argue that this default is wrong for most
cases.


Case 1:  The compiler is configured with --prefix=/usr.  In this case,
the compiler is being configured to be bundled with an operating
system or replace the bundled compiler.  In this case, the default for
--with-local-prefix should be NONE.

Having /usr/bin/cc search for include files in /usr/local/include by
default has a number of disadvantages.  First of all, having
/usr/local/include in the default include path isn't even all that
useful anyway if /usr/local/lib isn't in the default library search
path.  I've seen autoconf'ed packages search for a package just by
checking for headers.  These programs fail to link because configure
doesn't realize that -L/usr/local/lib was needed.  If local header
files are in fact available by default, then at lesat libraries should
be too.

Second of all, having /usr/local/include in the default include path
can potentially complicate life for anyone actually doing development
work on the operating system.  If I am working on parts of the
operating system (e.g. tools in /usr/bin) and they compile and work
with /usr/bin/cc, it would be nice to know I can commit the changes.
If /usr/local/include is always searched however, I never know if my
code only works because I happen to have a file /usr/local/include
that wasn't bundled with the operating system.


Case 2:  The compiler is being configured with a prefix other than
/usr or /usr/local.  For example, --prefix=/usr/local/egcs.  Here
again, searching /usr/local/include can be harmful.

I've seen sites where for example, someone installed one version of
gcc in /usr/local and one in /usr/local/gcc-2.8.1, without specifying
a local prefix.  These compilers worked for C code and so people
believed the installation was correct.  However,
/usr/local/gcc-2.8.1/c++ ended up getting the wrong g++ include files.
Any C++ code that included header files like <typeinfo> failed to
compile.


Conclusion:  I propose that the defaults for --with-local-prefix be
changed.  In the case that --prefix is /usr, the local-prefix should
be NONE.  In other cases it should be the same as prefix.

Reactions?  Please CC me on any replies, as I am not on the mailing
list.

Thanks,
David