[GitHub] [incubator-nuttx] gustavonihei edited a comment on pull request #3900: Revert "Make: use gcc as LD"

[GitBox <gi...@apache.org>]

gustavonihei edited a comment on pull request #3900:
URL: https://github.com/apache/incubator-nuttx/pull/3900#issuecomment-860710201


   > 
   > * iirc, linux supports LTO with ld. can you explain why it doesn't work for us?
   
   Linux Kernel support LTO with Clang-only so far, and using the LLD, which is the LLVM linker.
   
   > also, it seems gcc folks are thinking ld should work.
   > http://gcc.gnu.org/wiki/whopr/driver
   
   I believe that wiki page might not be up-to-date, since it is already a bit old. Is there a specific detail from this guide you'd like to bring to the discussion?
   If you look at the documentation for the '-flto' flag, it is clearly stated that:
   
   > _The important thing to keep in mind is that to enable link-time optimizations you need to use the GCC driver to perform the link step_
   
   https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#:~:text=the%20important%20thing%20to%20keep%20in%20mind%20is%20that%20to%20enable%20link-time%20optimizations%20you%20need%20to%20use%20the%20gcc%20driver%20to%20perform%20the%20link%20step.
   
   > * anyway, LTO thing is a bit off-topic. the change in question was to fix #3826 and my point is that it doesn't seem like an appropriate fix.
   
   I understand that a future support for LTO should not be the sole reason for that decision, and I agree that removing `-nostarfiles` and `-nodefaultlibs` is also a solution for the issue #3826.
   But I don't see why the implemented solution is not appropriate. It indeed fixes the issue and it has the advantage of setting up the build system for a future improvement.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org