This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 4:14 PM, David Miller <davem@davemloft.net> wrote:
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Sat, 17 Nov 2012 16:06:23 -0800
>
>> On Sat, Nov 17, 2012 at 4:04 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Eric Botcazou <ebotcazou@adacore.com>
>>> Date: Sun, 18 Nov 2012 00:18:15 +0100
>>>
>>>> error: '__NR_mmap2' was not declared in this scope
>>>> return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
>>>
>>> The people making libsanitizer changes are really going to have to
>>> stop making i386 specific changes to these generic files.
>>>
>>> Specifically, in this case, they are checking for whether mmap2 is
>>> available using __x86_64__ cpp tests. A more appropriate test is
>>> necessary.
>>>
>>> Oh nevermind, H.J. Liu added this build regression, I should have
>>> known.
>>>
>>> H.J., either fix or revert this code back to using __WORDSIZE if you
>>> cannot come up with an appropriate test.
>>
>> Please follow:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html
>
> The whole way this libsanitizer merge is being handled is
> beyond unreasonable.
>
> A build fix being held up for 4 days just proves that requiring things
> get merged into LLVM first is completely the wrong way for this stuff
> to work.
I am open to suggestions on how to avoid forking the two versions.
If we fork, the original asan team will not be able to cope with two
repositories.
--kcc
>
> The people who merged in this library should be responsible for
> keeping changes in sync, not the individual developers who fix bugs
> and make improvements to this code on the gcc side.
>
> It's lunacy that this build problem is in the tree for 4 days because
> of this.