[Buildroot] [autobuild.buildroot.net] Your build results for 2016-09-05

Sat Nov 5 17:12:16 UTC 2016

Hi Waldemar,

Le 13/09/2016 à 08:56, Romain Naour a écrit :
> Hi Waldemar,
> 
> Le 11 sept. 2016 15:34, "Waldemar Brodkorb" <wbx at openadk.org
> <mailto:wbx at openadk.org>> a écrit :
>>
>> Hi ROmain,
>> Romain Naour wrote,
>>
>> > Hi Waldemar,
>> >
>> > I'm not sure you get this email, I had a "Delivery Status Notification
> (Failure)"
>>
>> I have the mail.
>>
>> > Hi Waldemar,
>> >
>> > Le 10/09/2016 à 15:56, Waldemar Brodkorb a écrit :
>> > > Hi Romain,
>> > > Romain Naour wrote,
>> > >
>> > >> Hi Thomas, Waldemar,
>> > >>
>> > >> Le 06/09/2016 à 08:30, Thomas Petazzoni a écrit :
>> > >>> Hello,
>> > >>>
>> > >>> This is the list of Buildroot build failures that occured on
>> > >>> 2016-09-05, and for which you are a registered architecture developer
>> > >>> or package developer. Please help us improving the quality of
>> > >>> Buildroot by investigating those build failures and sending patches to
>> > >>> fix them. Thanks!
>> > >>>
>> > >>> Build failures related to your packages:
>> > >>>
>> > >>>         bfin |                  xenomai-2.6.4 |
> http://autobuild.buildroot.net/results/fcae0611ac87204ab68d6828276b635d1a31a178
>> > >>>
>> > >>
>> > >> I think it's an issue between uClibc-ng and Xenomai on Blackfin due to
>> > >> pthread_atfork(), shm_open() and shm_unlink() local definition in Xenomai.
>> > >>
>> > >> Error:
>> > >> bind.c:(.text+0x20): multiple definition of `pthread_atfork'
>> > >> .libs/libxenomai_la-assert_context.o:assert_context.c:(.text+0x54): first
>> > >> defined here
>> > >>
>> > >> sem_heap.c:(.text+0xc): multiple definition of `shm_open'
>> > >> .libs/libxenomai_la-bind.o:bind.c:(.text+0x2c): first defined here
>> > >>
>> > >> sem_heap.c:(.text+0x24): multiple definition of `shm_unlink'
>> > >> .libs/libxenomai_la-bind.o:bind.c:(.text+0x44): first defined here
>> > >>
>> > >> It's because the Xenomai definition use declare these function as
> "inline" and
>> > >> not uClibc-ng
>> > >>
>> > >> Xenomai [1]:
>> > >> /* uClibc does not provide pthread_atfork() for this arch; provide it
>> > >>    here. Note: let the compiler decides whether it wants to actually
>> > >>    inline this routine, i.e. do not force always_inline. */
>> > >> inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
>> > >>                                            void (*parent)(void),
>> > >>                                            void (*child)(void))
>> > >>
>> > >> uClibc-ng:
>> > >> extern int pthread_atfork (void (*__prepare) (void),
>> > >>                       void (*__parent) (void),
>> > >>                       void (*__child) (void)) __THROW;
>> > >>
>> > >> I guess those "inline" should be removed?
>> > >> Weldemar what do you think?
>> > >
>> > > I am in the middle of reworking libpthread/librt support in
>> > > uClibc-ng and found some problems in the way pthread_atfork is
>> > > declared.
>> > > I think the problems exist because of some backward compat support
>> > > in Gnu libc, see here for a nice summary:
>> > > http://ryanarn.blogspot.de/2011/07/curious-case-of-pthreadatfork-on.html
>> >
>> > Is the same issue for shm_open() and shm_unlink() ?
>>
>> Unsure, what is the thingie about shm_open().
>> I was just curious seeing pthread_atfork() problems while hacking on
>> the function :)
> 
> Ok, some investigation are needed but it seems the same issue... remove inline
> to fix the build...
> 
>>
>> > >
>> > > I think uClibc-ng should simply provide a usable pthread_atfork.
>> > > pthread_atfork is internally used by librt right now.
>> >
>> > Actually, it seems a bit weird to speak about pthread_atfork() for Blackfin
>> > which doesn't have a MMU so fork() is not available.
>> > I think that is why Xenomai try to define it on Blackfin, it doesn't expect
>> > pthread_atfork() to be provided by the libc.
>> >
>> > >
>> > > I hope I get some patch out for review in the next days.
>> >
>> > ok great :)
>> >
>> > >
>> > > I think uClibc-ng for NPTL and Linuxthreads should provide a usable
>> > > pthread_atfork(). So Xenomai does not need to provide their own.
>> >
>> > So even on Blackfin ?
>>
>> You are right, I should stop smoking bad things ;)
>> What should we do for noMMU targets? Provide a dummy or just do not
>> export any pthread_atfork() function?
> 
> I'm far to be an expert on no-MMU platform but yes, it seems we not need to
> export pthread_atfork function.
> 
> I'm not sure if we also need to do the same for shm_* functions...

I'm looking at this failure again and I'm wondering how Xenomai can even work on
bflin with the pthread_atfork() from uClibc-ng.

The uClibc-ng functions pthread_atfork() return an error (-1) when
__ARCH_USE_MMU__ is not defined. So all Xenomai skins will fail during their
initialization.

/* We can't support pthread_atfork without MMU, since we don't have
   fork(), and we can't offer the correct semantics for vfork().  */
int pthread_atfork(void (*prepare)(void),
		   void (*parent)(void),
		   void (*child)(void))
{
  /* ENOMEM is probably pushing it a little bit.
     Take it as `no *virtual* memory' :-)  */
  errno = ENOMEM;
  return -1;
}

Xenomai pthread_atfork() silently return success.

/* uClibc does not provide pthread_atfork() for this arch; provide it
   here. Note: let the compiler decides whether it wants to actually
   inline this routine, i.e. do not force always_inline. */
inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
						void (*parent)(void),
						void (*child)(void))
{
	return 0;
}

I would say that uClibc-ng shouldn't export a dummy pthread_atfork() on noMMU
platform.

Concerning shm_* functions, it seems that the weak attribute is discarded for
inline functions. See handle_weak_attribute() in gcc code, especially the
no_add_attrs argument.

That's why we have the following warning and then a symbol redefinition while
linking:

warning: inline function 'shm_open' declared weak [-Wattributes]
[...]
.libs/libxenomai_la-bind.o: In function `pthread_atfork':
bind.c:(.text+0x20): multiple definition of `pthread_atfork'
.libs/libxenomai_la-assert_context.o:assert_context.c:(.text+0x54): first
defined here

For the next Buildroot release it would be safer to disable Xenomai userspace
package for noMMU build.

Thoughts?

Best regards,
Romain

> 
> Best regards,
> Romain
> 
>>
>> best regards
>>  Waldemar
> 