Cross compilation issue #31
Comments
|
Looks like this is caused by autoconf's AC_FUNC_MALLOC. I think that |
|
Hello guys, For now I've solved changing (as suggested here Link): I wil test it better as soon as I can. |
|
ikoes notifications@github.com writes:
Please note that the proposed patch is not yet applied to the code in |
|
ikoes notifications@github.com writes:
This will fix the compilation issue. The question I had raised was |
|
The error that happen while cross compiling is quite logical if you know what the check AC_FUNC_MALLOC is made for. The behavior isn't really wrong (for me) because autoconf can't really test the created code due it's for another platform. Some nice explanation about the whole problem can be found here: But as long as libcoap uses malloc from the libc we need a check for the proper implementation for this cases. So removing AC_FUNC_MALLOC isn't solving the problem. We need at least a check for a malloc functionality which can be done by AC_CHECK_FUNC(S) like suggested above. So would change the autoconf check to something like this: After this you will get cross compiled binaries like native non cross builds. |
obgm
pushed a commit
that referenced
this issue
Apr 25, 2016
The error that happen while cross compiling is quite logical if you know what the check AC_FUNC_MALLOC is made for. The behavior isn't really wrong (for me) because autoconf can't really test the created code due it's for another platform. Some nice explanation about the whole problem can be found here: http://wiki.buici.com/xwiki/bin/view/Programing+C+and+C%2B%2B/Autoconf+and+RPL_MALLOC As long as libcoap uses malloc from the libc we need a check for the proper implementation for this cases. So removing AC_FUNC_MALLOC isn't solving the problem. We need at least a check for a malloc functionality which can be done by AC_CHECK_FUNC(S).
|
Fair enough. Although AC_FUNC_MALLOC obviously has its value here, I have dropped it in favor of tijuca's patch. All uses of coap_malloc() that invoke the system's malloc() function should already pass a value greater than zero but I did not review the entire code to ensure this. |
obgm
pushed a commit
that referenced
this issue
Apr 18, 2017
The error that happen while cross compiling is quite logical if you know what the check AC_FUNC_MALLOC is made for. The behavior isn't really wrong (for me) because autoconf can't really test the created code due it's for another platform. Some nice explanation about the whole problem can be found here: http://wiki.buici.com/xwiki/bin/view/Programing+C+and+C%2B%2B/Autoconf+and+RPL_MALLOC As long as libcoap uses malloc from the libc we need a check for the proper implementation for this cases. So removing AC_FUNC_MALLOC isn't solving the problem. We need at least a check for a malloc functionality which can be done by AC_CHECK_FUNC(S). (cherry picked from commit 04d806f)
Closed
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello guys,
Trying to cross compile the examples of the develop repository I got stucked with a rpl_malloc issue.
Basically I've done the following:
Then the command exit with this error
undefined reference to "rpl_malloc"I found that setting the following env variable solved the problem:
$ export ac_cv_func_malloc_0_nonnull=yesI don't know if that is an issue or not but it wasn't straightforward how to get it solved.
Thank you for your work.
FedBerg.
The text was updated successfully, but these errors were encountered: