* Re: Suggestion for --with-local-prefix configure option
@ 1999-03-17 14:53 Mike Stump
1999-03-17 19:41 ` David Starner
1999-03-31 23:46 ` Mike Stump
0 siblings, 2 replies; 16+ messages in thread
From: Mike Stump @ 1999-03-17 14:53 UTC (permalink / raw)
To: egcs, fheitka; +Cc: N8TM
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-17 14:53 Suggestion for --with-local-prefix configure option Mike Stump
@ 1999-03-17 19:41 ` David Starner
1999-03-31 23:46 ` David Starner
1999-03-31 23:46 ` Mike Stump
1 sibling, 1 reply; 16+ messages in thread
From: David Starner @ 1999-03-17 19:41 UTC (permalink / raw)
To: Mike Stump, egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-17 14:53 Suggestion for --with-local-prefix configure option Mike Stump
1999-03-17 19:41 ` David Starner
@ 1999-03-31 23:46 ` Mike Stump
1 sibling, 0 replies; 16+ messages in thread
From: Mike Stump @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs, fheitka; +Cc: N8TM
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-17 19:41 ` David Starner
@ 1999-03-31 23:46 ` David Starner
0 siblings, 0 replies; 16+ messages in thread
From: David Starner @ 1999-03-31 23:46 UTC (permalink / raw)
To: Mike Stump, egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-17 3:57 ` fheitka
@ 1999-03-31 23:46 ` fheitka
0 siblings, 0 replies; 16+ messages in thread
From: fheitka @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs; +Cc: N8TM
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-16 18:07 ` Jean-Pierre Radley
@ 1999-03-31 23:46 ` Jean-Pierre Radley
0 siblings, 0 replies; 16+ messages in thread
From: Jean-Pierre Radley @ 1999-03-31 23:46 UTC (permalink / raw)
To: EGCS Developers
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Suggestion for --with-local-prefix configure option
1999-03-16 10:14 David Mazieres
1999-03-16 16:14 ` Alexandre Oliva
1999-03-17 0:24 ` Bernd Eggink
@ 1999-03-31 23:46 ` David Mazieres
2 siblings, 0 replies; 16+ messages in thread
From: David Mazieres @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-17 0:24 ` Bernd Eggink
@ 1999-03-31 23:46 ` Bernd Eggink
0 siblings, 0 replies; 16+ messages in thread
From: Bernd Eggink @ 1999-03-31 23:46 UTC (permalink / raw)
To: David Mazieres; +Cc: egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-16 18:01 N8TM
[not found] ` < c37ea7d.36ef0bb1@aol.com >
@ 1999-03-31 23:46 ` N8TM
1 sibling, 0 replies; 16+ messages in thread
From: N8TM @ 1999-03-31 23:46 UTC (permalink / raw)
To: dm, egcs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-16 16:14 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Alexandre Oliva
0 siblings, 0 replies; 16+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: David Mazieres; +Cc: egcs
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
[not found] ` < c37ea7d.36ef0bb1@aol.com >
1999-03-16 18:07 ` Jean-Pierre Radley
@ 1999-03-17 3:57 ` fheitka
1999-03-31 23:46 ` fheitka
1 sibling, 1 reply; 16+ messages in thread
From: fheitka @ 1999-03-17 3:57 UTC (permalink / raw)
To: egcs; +Cc: N8TM
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-16 10:14 David Mazieres
1999-03-16 16:14 ` Alexandre Oliva
@ 1999-03-17 0:24 ` Bernd Eggink
1999-03-31 23:46 ` Bernd Eggink
1999-03-31 23:46 ` David Mazieres
2 siblings, 1 reply; 16+ messages in thread
From: Bernd Eggink @ 1999-03-17 0:24 UTC (permalink / raw)
To: David Mazieres; +Cc: egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
[not found] ` < c37ea7d.36ef0bb1@aol.com >
@ 1999-03-16 18:07 ` Jean-Pierre Radley
1999-03-31 23:46 ` Jean-Pierre Radley
1999-03-17 3:57 ` fheitka
1 sibling, 1 reply; 16+ messages in thread
From: Jean-Pierre Radley @ 1999-03-16 18:07 UTC (permalink / raw)
To: EGCS Developers
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
@ 1999-03-16 18:01 N8TM
[not found] ` < c37ea7d.36ef0bb1@aol.com >
1999-03-31 23:46 ` N8TM
0 siblings, 2 replies; 16+ messages in thread
From: N8TM @ 1999-03-16 18:01 UTC (permalink / raw)
To: dm, egcs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suggestion for --with-local-prefix configure option
1999-03-16 10:14 David Mazieres
@ 1999-03-16 16:14 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-17 0:24 ` Bernd Eggink
1999-03-31 23:46 ` David Mazieres
2 siblings, 1 reply; 16+ messages in thread
From: Alexandre Oliva @ 1999-03-16 16:14 UTC (permalink / raw)
To: David Mazieres; +Cc: egcs
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Suggestion for --with-local-prefix configure option
@ 1999-03-16 10:14 David Mazieres
1999-03-16 16:14 ` Alexandre Oliva
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: David Mazieres @ 1999-03-16 10:14 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-03-31 23:46 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-17 14:53 Suggestion for --with-local-prefix configure option Mike Stump
1999-03-17 19:41 ` David Starner
1999-03-31 23:46 ` David Starner
1999-03-31 23:46 ` Mike Stump
-- strict thread matches above, loose matches on Subject: below --
1999-03-16 18:01 N8TM
[not found] ` < c37ea7d.36ef0bb1@aol.com >
1999-03-16 18:07 ` Jean-Pierre Radley
1999-03-31 23:46 ` Jean-Pierre Radley
1999-03-17 3:57 ` fheitka
1999-03-31 23:46 ` fheitka
1999-03-31 23:46 ` N8TM
1999-03-16 10:14 David Mazieres
1999-03-16 16:14 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-17 0:24 ` Bernd Eggink
1999-03-31 23:46 ` Bernd Eggink
1999-03-31 23:46 ` David Mazieres
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).