This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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