This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Shared library runpath trouble in Solaris.


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]