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: How to get top-level library installed in lib/gcc-lib/...?


On Wed, 17 June 1998, 21:17:36, law@cygnus.com wrote:

 > 
 >   In message <rzqhg1jvnya.fsf@djlvig.dl.ac.uk>you write:
 >   > I don't understand why it is this way, though I haven't had time to
 >   > look closely.  Why are libf2c and libstdc++ different?  [Answer
 >   > presumably to await mail.gnu.org getting sorted out...]
 > There have been discussions about moving libstdc++ into libsubdir,
 > but no real decision was ever made.  There's pros and cons to moving
 > it into libsubdir.

Agreed, but for me the pros outweigh the cons. Do you remember the
problems people were reporting which were caused by old include/g++
include files which have been deleted from the snapshots at a random
point in time? If we continue to install into ${prefix}/include/g++,
I guess we will probably end up with lots of "garbage" which was
useful somewhere in the past, but right now is causing problems
only. This will become an even more serious problem with Uli's
rewrite of libstdc++ (at least when it'll be introduced the first
time; looks as if we really actually need to make sure to wipe out
everything, what could be existing due to installations of older
versions of libg++-2.7.x, libstdc++-2.8.x, libg++-2.8.x and even
egcs-x.y.z!).

 > 
 > Consider what happens if you move it into libsubdir and it's built
 > as a shared library.
 > 
 > You've just made programs which use libstdc++ (any C++ program) rely
 > on being able to find libsubdir/libstdc++.so at runtime.  ANd if your
 > sysadmin updates compilers and wipes out the old version, then your
 > programs will be unable to find the right libstdc++.so and will not
 > run.

I even agree with this. But, imagine the other way round: You've just
installed a new snapshot, which simply overwrites any existing egcs
release's or other snapshot's libs; unfortunately, the new lib's
interfaces have changed :-( What gives? The programs won't start,
either, or even worse, they'll start but won't work as they should.

 > 
 > This is the same argument against libgcc.sl.

No, I guess the argument against a shared libgcc is mainly that we
expect to have more changes in it than in a shared libstdc++ or
libg++.

Perhaps, this issue is mostly relevant to us gcc/g++/libstdc++ hackers 
only. What do you think about this:

  In a release tree shared libraries continue to be installed where
  they are right now. The change I've proposed with my patch in a
  separate e-mail concerning $(libsubdir) and $(gxx_include_dir) will
  only be applied to the snapshots.

 > 
 > Hmmm, right now we don't built libf2c as a shared library, presumably
 > we might one day?!?  In which case we've got the same problem.
 > 
 > jeff

manfred


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