On Mon, 23.06.14 11:59, Chase Rayfield (cusbr...@yahoo.com) wrote:
> I haven't inquired directly with the GCC mailing list. But it seems
> thier current stance is to implement the builtins for architectures
> that have the instructions to support them and require the
> architectures that do not to
I haven't inquired directly with the GCC mailing list. But it seems thier
current stance
is to implement the builtins for architectures that have the instructions to
support
them and require the architectures that do not to supply a library.
Yes libatomic_ops is ugly but necessary unless the G
On Mon, Jun 23, 2014 at 9:25 AM, Lennart Poettering
wrote:
> On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote:
>
>> > Thanks, but please work with the gcc developers to solve this
>> > generically for all gcc users, instead of work around this limitation in
>> > every individua
On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote:
> > Thanks, but please work with the gcc developers to solve this
> > generically for all gcc users, instead of work around this limitation in
> > every individual project independently. It's certainly time much better
> > spent
On 23/06/14 15:30, Lennart Poettering wrote:
> On Sat, 21.06.14 09:05, Chase Rayfield (cusbr...@yahoo.com) wrote:
>
>>> If I interpret that correctly, systemd would need to define
>>> _sync_sub_and_fetch_4 when building for 32-bit processors which do not
>>> support the __sync_sub_and_fetch operat
On Sat, 21.06.14 09:05, Chase Rayfield (cusbr...@yahoo.com) wrote:
> >If I interpret that correctly, systemd would need to define
> >_sync_sub_and_fetch_4 when building for 32-bit processors which do not
> >support the __sync_sub_and_fetch operation natively.
>
> Yes exactly... I think libatomic_
>If I interpret that correctly, systemd would need to define
>_sync_sub_and_fetch_4 when building for 32-bit processors which do not
>support the __sync_sub_and_fetch operation natively.
Yes exactly... I think libatomic_ops can help with that and I have built it
from git on Sparc v8 (This flag is
On Sat, Jun 21, 2014 at 11:31 AM, Mike Gilbert wrote:
> On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez
> wrote:
>> El 21/06/14 01:38, Chase Rayfield escribió:
>>
>>> udev up to version 208 builds correctly on Sparc v8. However 212 and
>>> greater does not.
>>>
>>> Complete build logs of 208
On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez
wrote:
> El 21/06/14 01:38, Chase Rayfield escribió:
>
>> udev up to version 208 builds correctly on Sparc v8. However 212 and
>> greater does not.
>>
>> Complete build logs of 208 and 214 can be found here:
>> https://bugs.gentoo.org/show_bug.c
El 21/06/14 01:38, Chase Rayfield escribió:
udev up to version 208 builds correctly on Sparc v8. However 212 and
greater does not.
Complete build logs of 208 and 214 can be found here:
https://bugs.gentoo.org/show_bug.cgi?id=514016
Any suggestions or alternatives to how we can fix this would be
I have attached the output of export CFLAGS="-mcpu=v8" ; ./configure && make
for systemd-214
Hopefully that will be more helpful.
Chase Rayfield
On Saturday, June 21, 2014 1:57 AM, Samuli Suominen
wrote:
On 21/06/14 08:38, Chase Rayfield wrote:
> udev up to version 208 builds correct
On 21/06/14 08:38, Chase Rayfield wrote:
> udev up to version 208 builds correctly on Sparc v8. However 212 and
> greater does not.
>
> Complete build logs of 208 and 214 can be found here:
> https://bugs.gentoo.org/show_bug.cgi?id=514016
>
> Any suggestions or alternatives to how we can fix this
12 matches
Mail list logo
