[lttng-dev] urcu AC_FUNC_MALLOC fails for cross-compile

[D'Alessandro, Luke K]

> On Jun 14, 2016, at 12:33 PM, Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> 
> ----- On Jun 14, 2016, at 12:26 PM, Luke K D'Alessandro ldalessa at indiana.edu <mailto:ldalessa at indiana.edu> wrote:
> 
>>> On Jun 14, 2016, at 12:21 PM, Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
>>> wrote:
>>> 
>>> ----- On Jun 14, 2016, at 12:12 PM, Luke K D'Alessandro ldalessa at indiana.edu
>>> wrote:
>>> 
>>>> The AC_FUNC_MALLOC depends on some runtime results which doesn't work when cross
>>>> compiling. Google has a bit to say about this and basically the fix is to stop
>>>> using the macro. Is there a specific purpose for this check, or could it just
>>>> be eliminated from configure.ac?
>>> 
>>> If we remove this check, we need to ensure that URCU does not depend
>>> on malloc(0) returning non-NULL anywhere.
>> 
>> Okay, I’m not sure what the implications are this for you. We have a test
>> infrastructure that tries to download, build, and link liburcu using a cross
>> compiler for 32-bit arm platforms, but it fails because of this check. I will
>> try and figure out how to get a binary version of liburcu installed permanently
>> somewhere that the cross compiler toolchain can find.
> 
> Can you give us some details on how it fails ?
> 
> configure output and config.log

Sure.

git version 5002434419b458f1de889b3ed1110b440d3bf5b0

Config log, configure output, and make output attached. I meant to reference this issue (https://github.com/LLNL/ior/issues/4 <https://github.com/LLNL/ior/issues/4>) which has the same symptoms I see here.

Thanks,
Luke


> 
> Thanks,
> 
> Mathieu
> 
> 
>> 
>> Thanks,
>> Luke
>> 
>>> 
>>> Thanks,
>>> 
>>> Mathieu
>>> 
>>>> 
>>>> Thanks,
>>>> Luke
>>>> 
>>>> _______________________________________________
>>>> lttng-dev mailing list
>>>> lttng-dev at lists.lttng.org
>>>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>> 
>>> --
>>> Mathieu Desnoyers
>>> EfficiOS Inc.
>>> http://www.efficios.com
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com <http://www.efficios.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 79563 bytes
Desc: not available
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0003.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.out
Type: application/octet-stream
Size: 9267 bytes
Desc: not available
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0004.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.out
Type: application/octet-stream
Size: 33538 bytes
Desc: not available
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0005.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160614/d565ac50/attachment-0001.sig>