On 10/16/2015 04:46 PM, Joya Cruz, Alejandro wrote: > I noticed that in several places it may be the need to add the CFLAGS > like on makefile to generated/instlist and others does it makes sense > use the same CFLAGS on these?
I have a couple pending email from Jose Bollo explaining how to set up a smack cross compile toolchain for tizen, because he hit an issue where the host build was sucking in smack stuff that requires target flags to build. (Header include paths in the cflags, I think.) It's on the todo list. (Fairly near the top, but... largeish.) The fix is to keep target dependencies like that _out_ of the host binaries, because $CFLAGS is realy _target_ cflags, not host CFLAGS. (You really, really, really shouldn't need host cflags. If you do, your compiler is probably broken.) > P.D. I made some patches related with this but I sent a pull request on > the github, I reviewed the documantion of the web but didn't find how is > the process to provided patches.how should I stage this? I normally just take patches to the mailing list. I did merge a commit from you that came in as a github pull request, though: https://github.com/landley/toybox/commit/76ddf7a3c55efa456af2c488b4be4fb9997fdbd2 (I tend to download the patch and "git am" it locally to avoid a gratuitous merge commit. Not sure how to tell github I did this. I'm hosting (mirroring?) the repository on github, but not really part of the github ecosystem.) Although looking back on that... you added target $CFLAGS to building a host binary, so if somebody feeds a "build this big endian" flag into CFLAGS and then tries to build toybox, it will now break building config2help for x86 and either build breaking or being unable to run the result. Do you _need_ a host CFLAGS? (Is this the tizen thing again?) > Regards, > > AJ Thanks, Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
