Patchwork PATCH RFA: PR go/55201: Create libatomic convenience library

login
register
mail settings
Submitter Matthias Klose
Date Dec. 19, 2012, 3:38 p.m.
Message ID <50D1DF6F.5060109@ubuntu.com>
Download mbox | patch
Permalink /patch/207408/
State New
Headers show

Comments

Matthias Klose - Dec. 19, 2012, 3:38 p.m.
Am 19.12.2012 01:28, schrieb Ian Lance Taylor:
> On Tue, Dec 18, 2012 at 3:15 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
>>> Argh.  But why?  Wouldn't that only apply to cases where the lock was
>>> sometimes locked by one library and sometimes locked by a different
>>> one?
>>
>> Or did you really mean
>>
>>   "... only apply to cases where the memory protected by the lock
>>    was visible to more than one library."
>>
>> Yes, if libgo is attempting atomic accesses to its own data structures,
>> which themselves are not exported from libgo, then a copy of libatomic
>> ought to work.
>>
>> It would probably be better for the shared libgo to depend on the
>> shared libatomic though.  That's simply more pedantically correct.
> 
> But according to Matthias's comment upthread, it would require
> addressing some issue in libtool in order to get multilib working
> correctly.
> 
> I'm not going to try to solve this today, but if somebody else wants
> to that would be great.

you cannot reproduce this, if you already have libatomic.so.1 installed into
your destination/installation path. You should be able to reproduce this by
installing into an empty destination (maybe using DESTDIR). Then libgo can't
find the libatomic. calling make install-target-libatomic and then re-running
lets make install succeed.

Makefile.def doesn't define any dependencies on the installation targets,
however seldom people run make install with -j, and then the order the
target_modules are listed matters. libatomic comes behind the libgo target, otoh
libquadmath comes before libgfortran and installs without issues.

The following patch fixes this for me, maybe other target library dependencies
should be added too.

that would be for
  libgfortran on libquadmath, libgcc
  libsanitizer on libstdc++
  libstdc++ on libgomp, libgcc
  libjava on libstdc++, libgcc
  libasan on libgcc
  libobjc on libgcc
  libitm on libgcc

Matthias
Ian Taylor - Dec. 19, 2012, 3:47 p.m.
On Wed, Dec 19, 2012 at 7:38 AM, Matthias Klose <doko@ubuntu.com> wrote:
>
> The following patch fixes this for me, maybe other target library dependencies
> should be added too.
>
> that would be for
>   libgfortran on libquadmath, libgcc
>   libsanitizer on libstdc++
>   libstdc++ on libgomp, libgcc
>   libjava on libstdc++, libgcc
>   libasan on libgcc
>   libobjc on libgcc
>   libitm on libgcc
>
> Matthias
>
> Index: Makefile.def
> ===================================================================
> --- Makefile.def        (Revision 194604)
> +++ Makefile.def        (Arbeitskopie)
> @@ -514,6 +514,8 @@
>  //  recursive make, we can't be that specific.
>  dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp; };
>
> +dependencies = { module=install-target-libgo; on=install-target-libatomic; };
> +
>  // Target modules in the 'src' repository.
>  lang_env_dependencies = { module=libtermcap; };
>  lang_env_dependencies = { module=rda; };
>

Thanks for looking into it.

This patch is OK with a ChangeLog entry.

Ian

Patch

Index: Makefile.def
===================================================================
--- Makefile.def	(Revision 194604)
+++ Makefile.def	(Arbeitskopie)
@@ -514,6 +514,8 @@ 
 //  recursive make, we can't be that specific.
 dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp; };

+dependencies = { module=install-target-libgo; on=install-target-libatomic; };
+
 // Target modules in the 'src' repository.
 lang_env_dependencies = { module=libtermcap; };
 lang_env_dependencies = { module=rda; };