mklibgcc fallout

[Joseph S. Myers]

On Thu, 2 Dec 2004, Zack Weinberg wrote:

> > when building multilibs.  This turned out to be due to a bad symlink in
> > gcc/32,
> >   libgcc_s_32.so -> 32/libgcc_s.so.1
> > which should be
> >   libgcc_s_32.so -> libgcc_s.so.1.
> >
> > 	* mklibgcc.in: Trim directory when substituting shlib_base_name.
> 
> I'm not sure this is right.  David Edelsohn was saying yesterday on
> IRC that all the shared libgcc variants are supposed to wind up in the
> toplevel, in which case the symlink *should* be 32/libgcc_s.so.1, it
> should just be in the parent directory.

My understanding from Mark 
<http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01170.html> was that the 
link should go in the same directory as the linked-to file (although the 
driver patch to pass a -L path only for the correct multilib variant, so 
links at toplevel wouldn't be seen at all, has been postponed until 4.1).

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)