This is the mail archive of the 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" <> 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,
>> > -> 32/
>> > which should be
>> > ->
>> >
>> > 	* 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/, it
>> should just be in the parent directory.
> My understanding from Mark 
> <> 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

<Rhyolite> The AIX "make install" is showing failures because
           libgcc_s_* does not exist in the directory
<Rhyolite> because is placing it in the subdirectories
<Rhyolite> 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


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