public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Manfred Hollstein <manfred@s-direktnet.de>
To: hjl@lucon.org
Cc: law@cygnus.com, jbuck@synopsys.com, drepper@cygnus.com, egcs@cygnus.com
Subject: New installation defaults (was: Re: once we have cpplib...)
Date: Sat, 18 Apr 1998 08:18:00 -0000	[thread overview]
Message-ID: <13624.39452.811565.52754@saturn.s-direktnet.de> (raw)
In-Reply-To: <m0yPwoR-00058vC@ocean.lucon.org>

On Thu, 16 April 1998, 15:07:18, hjl@lucon.org wrote:

 [snip]
 > > If we'll be going to change installation rules, where should
 > > _G_config.h be installed? Currently it goes into
 > > ${prefix}/${target}/include, but I think it should be installed in
 > > ${libsubdir}/include (or ${gxx_include_dir}), right?!
 > 
 > We have to be very careful on it.
 > 
 > > 
 > > Anyway, if nobody  else has a patch already  I'll preparing  one which
 > > will provide this:
 > > 
 > >   1. Change the default for g++ header installation from
 > >      ${prefix}/include/g++ to ${libsubdir}/include/g++
 > >   2. Install _G_config.h in ${libsubdir}/include.
 > >   3. Install runtime libs (libstdc++.*) in ${libsubdir}
 > >      resp. subdirectories for multilib configurations.
 > > 
 > > Once  3. is active,  I'm afraid we'll be  receiving lots of complaints
 > > from Linux users  about   ld.so no  longer   finding libstdc++.so.2.8,
 > > though :-(
 > > 
 > 
 > I have warned it many months ago.

Agreed, I think if we'll be going to change installation defaults, we
should agree which way to go!

So, the questions look to me like:

1. Shall we change the installation defaults?

If yes:

 2. Where shall _G_config.h be installed?

    a) in ${libsubdir}/include
    b) in ${gxx_include_dir}

 3. How do we manage locating a shared libstdc++ at runtime if their
    location changes from a directory covered by /etc/ld.so.conf to a
    new absolutely non-standard one?

If not:

 4. How do we achieve to help people protect their `standard'
    installation from being clobbered by an `experimental' one and
    without introducing too many --prefix=.../package/... related
    directories?

I'm sorry if you feel bothered by this, but I agree with H.J.:

  the current situation isn't very pleasant with having two worlds
  competing: most Linux users able to get root access allowing them to
  add any possible directory to ld.so's cache, and the rest of the world
  (I really hate to always type something like the following on
   Solaris: "g++ ... -Wl,-rpath,`gcc --print-file-name=`"!).

So, what's your vote?

manfred

  reply	other threads:[~1998-04-18  8:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-08 21:20 once we have cpplib Ulrich Drepper
1998-04-08 23:35 ` Per Bothner
1998-04-09  2:06 ` Andreas Schwab
1998-04-09  8:27   ` Ulrich Drepper
     [not found] ` <199804090635.XAA26672.cygnus.egcs@cygnus.com>
1998-04-09 14:17   ` Ulrich Drepper
1998-04-09 17:44     ` Joe Buck
1998-04-09 21:23       ` Jeffrey A Law
1998-04-11  9:32         ` John Polstra
1998-04-16 10:51         ` Manfred Hollstein
1998-04-16 22:46           ` H.J. Lu
1998-04-18  8:18             ` Manfred Hollstein [this message]
1998-04-18 18:48               ` New installation defaults (was: Re: once we have cpplib...) H.J. Lu
1998-04-10  3:43       ` once we have cpplib Martin von Loewis
1998-04-09 22:03     ` Jeffrey A Law
1998-04-10  7:27       ` Per Bothner
1998-04-21 19:10         ` Joern Rennecke
     [not found]         ` <199804220100.CAA28717.cygnus.egcs@phal.cygnus.co.uk>
1998-04-22  9:05           ` Ulrich Drepper
1998-04-09 18:29 ` Jeffrey A Law
1998-04-09 17:44   ` Ulrich Drepper
1998-04-10  0:39     ` Per Bothner
1998-04-13  9:43       ` Dave Brolley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13624.39452.811565.52754@saturn.s-direktnet.de \
    --to=manfred@s-direktnet.de \
    --cc=drepper@cygnus.com \
    --cc=egcs@cygnus.com \
    --cc=hjl@lucon.org \
    --cc=jbuck@synopsys.com \
    --cc=law@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).