This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shared library runpath trouble in Solaris.
- To: Ian Lance Taylor <ian at cygnus dot com>
- Subject: Re: Shared library runpath trouble in Solaris.
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 11 Nov 1997 01:52:56 -0200
- Cc: tot at trema dot com, egcs at cygnus dot com
- References: <199711110319.WAA12589@subrogation.cygnus.com>
[I've just re-read this message, before posting, and found that some
parts of it may be interpreted as aggresive or such. Please consider
my lack of proficiency in English as the cause for that.]
Ian Lance Taylor writes:
> ld -R/path/to/libstdc++ -R/usr/lib -R/whatever/-R/flags/issued/by/the/user
> It seems to me that the user's -R options should go first.
So it seemed to me, but you said -R would add a directory to the
beginning of the search path... If this is not correct, the reverse
order should be used.
> Actually, it seems to me that if the user uses any -R options, g++
> should not insert any. Trust the user.
Although I usually agree with this, I'd rather disagree with this as
the default behavior of g++. A C++ compiler is required to provide a
certain standard library, and requiring a user to add special
arguments to find that library is no good, IMHO. Besides, removing
the standard library from the search path just because a -R option was
added would cause even more confusion. I'd agree about removing it if
-nostdlib were issued, though.
> Perhaps I misunderstand, but it seems to me that it would break for
> the same reason we've been discussing: the program would have a -R
> option it does not need.
So what? If it doesn't ever search that directory, there's no problem
at all. So, if it is the last directory in the search path, there's
no problem to solve: either the library will not be found at all, or
it will be found in this last directory. If the NFS-server for that
directory is down, the program wouldn't be able to run anyway.
> That's the bad situation I want to avoid:
> the compiler should never silently insert a unnecessary -R option.
I'd consider that a necessary -R option. Consider what kind of damage
it would cause to you if libgcc were shared, and try to understand my
position as a C++ programmer.
> It's portable to any SVR4, Solaris, or Linux system, and to any system
> which uses the GNU linker.
Are we talking about portability or what? I've got a hard time
figuring out exactly which variables I had to set to get g++/egcs++
*tests* running correctly on the *four* platforms I regularly test,
(Sparc Solaris 2.5, SunOS 4.1.3, IRIX 5.2 and pc Linux). And I
consider myself a rather experienced Unix hacker, now think about
users that try to run their C++ compilers and write to me saying it
doesn't work, or, even worse, post a message to bug-g++.
There are lots of questions like this in bug-g++, gnu.gcc.help.
Several people have had trouble with that recently. Wouldn't it be
much better to make it work in the general case, and let people with
special needs to fulfill them with extra switches?
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil