This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: mklibgcc fallout


"Joseph S. Myers" <joseph@codesourcery.com> writes:

> 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).

Hm, so is it the install rule that's incorrect, then?  Quoting from
IRC

<Rhyolite> The AIX "make install" is showing failures because
           libgcc_s_* does not exist in the directory
<Rhyolite> because libgcc.mk is placing it in the subdirectories
<Rhyolite> libgcc.mk install does
<Rhyolite> ../install-sh -c -m 644 libgcc_s_pthread.a $(DESTDIR)$(slibdir)/
<Rhyolite> which is expecting the file in the main build directory,
           where it used to be placed

zw


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