public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr>
To: Robert Lipe <robertl@dgii.com>
Cc: egcs@cygnus.com
Subject: Re: Success...
Date: Fri, 05 Dec 1997 16:52:00 -0000	[thread overview]
Message-ID: <199712052318.AAA24414@mururoa.inria.fr> (raw)
In-Reply-To: <19971205152811.44442@dgii.com>

>>     - Have everyone to specify a LD_LIBRARY_PATH (I hate that solution).
>
>If you just set it in /etc/profile, it's not too horrible.

	Nope, not better. I do not want to have to modify it on many machines.
If I had to do such a thing the ldconfig solution would be better. For both
I need root access.

May be, I have not been precise enough. I'm in an environment where I cannot
change anything in root partitions (because I'm not a system manager).
However, we have a group of users and some common disk space in which I can
install egcs. The solution that I adopted last time (with gcc-2.7.2.1) was to
modify the spec file and this is transparent for the users as long as the
executables are not exchanged to other sites or as long as I do not remove
the libraries. If I had to ask all the users to change their LD_LIBRARY_PATH
variable, then I'm sure:

	- That most of them will not do it when I say it.
	- A lot of them will ask at random times later why it is not working.
	- Some other will make strange things with their LD_LIBRARY_PATH and
	  at some point will come to ask for help. And of course I want to minimize
	  my work. Actually, the common wisdom around here is to never set the
	  LD_LIBRARY_PATH variable because then you override the environment that
	  the installer has set up for you and this can fail miserably (I can at
	  least think of one or two example with various Motif1.2 librairies
	  originating from different vendors!!).

I do not think my situation is that un-common. The solution with the -R flag
in the spec file works and is not that bad. The only problem I had with
gcc-2.7.2.1 is that when static linking was selected the static versions
of the g++ libraries where not taken so that we had to specify the .a
libraries manually to link with them. Should this mis-feature is corrected
I do not see specifying the appropriate -R flag just for libstdc++.so as
a major problem since anyhow when we want to export binaries we always
compile them static in order to avoid any trouble with non-existing
libraries at the other sites.

	Now, that's only my 2p. Maybe I have not figured out yet what is the
big trouble in doing so. Anyhow my point was just to leave the installer
the choice without having to go and change the spec file by hand.

	Thank's a lot anyhow for your remark, I forgot that solution.

		Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
 Email:  papadop@sophia.inria.fr               Tel: (33) 93 65 76 01
 --------------------------------------------------------------------

       reply	other threads:[~1997-12-05 16:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19971205152811.44442@dgii.com>
1997-12-05 16:52 ` Theodore Papadopoulo [this message]
2000-11-16 10:25 success Italo Antonio
  -- strict thread matches above, loose matches on Subject: below --
1999-10-07 14:54 success Dave Carter
1999-10-31 23:35 ` success Dave Carter
1999-08-30  6:45 success Mike Williams
1999-08-31 23:20 ` success Mike Williams
1999-05-25  6:35 success Jens Racky
1999-05-31 21:36 ` success Jens Racky
1998-11-10 21:26 success chris
1998-09-09 12:19 success Paul J. Tackley
1998-01-19  2:30 Success dcanazz
1997-12-05 12:11 Success Theodore Papadopoulo

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=199712052318.AAA24414@mururoa.inria.fr \
    --to=theodore.papadopoulo@sophia.inria.fr \
    --cc=egcs@cygnus.com \
    --cc=robertl@dgii.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).