This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: mklibgcc fallout
David Edelsohn wrote:
Is Sun concerned about the directory search path for libraries at
link-edit time or the directory search path for shared libraries at
runtime?
The former.
Richard Henderson's design for libgcc_s shared libraries places
them all in the same directory, both during the build and at installation.
It's a little more complex than that; there seem to be symlinks from (or
to?) the multilib directories. That was certainly the behavior that we
were seeing on Solaris. I don't see any particular virtue in not doing
the usual multilib thing for libgcc, but I agree with your comment below
that we shouldn't be changing the design now -- just fixing problems.
I would appreciate if mklibgcc could be corrected so that it
returns to the original behavior. I do not believe that libgcc_s exhibits
the directory search problem raised by Sun. If we need to change the GCC
directory search behavior, I would like to discuss that separately from
fixing the current and continuing breakage.
I agree that we need to fix the breakage, and that we should do that
before making design changes.
I'm not 100% clear if the compiler is presently broken after
installation, of if it's just the case that the layout before
installation is not as you desire. The former is of course a more
severe situation than the latter.
This situation is frustruating; Andrew checked in a patch that broke
Darwin, and Zack spent a couple of weeks of time fixing that, and now
there's fallout elsewhere. I'm not suggesting that it's not Zack's
responsibility to fix the problems, but it would also be nice if Andrew
and/or folks at Apple could step in to help out.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304