11461 should use a native link-editor during the build

Review Request #2182 — Created July 14, 2019 and updated

richlowe
illumos-gate
build/tools-ld
11461, 11463, 11464, 11465
4069af0...
general

11461 should use a native link-editor during the build
11463 SUNWonld has passed its use-by date
11464 cmd/sgs/tools should contain tools, not common code
11465 sgsmsg should be built with the rest of the build tools



  • 0
  • 0
  • 2
  • 2
  • 4
Description From Last Updated
hans
  1. Ship It!
  2. 
      
yuri.pankov
  1. Ship It!
  2. 
      
tsoome
  1. Ship It!
  2. 
      
citrus
  1. Ship It!
  2. 
      
richlowe
rm
  1. 
      
  2. usr/src/cmd/sgs/include/conv.h (Diff revision 1)
     
     
    The theory behind all these is that we basically should be in a new enough env that we have these right?
    1. With the exception of those ELF headers of our own we explicitly use, we're still using regular system headers on the build machine when doing a native build (on purpose), so it's still possible we could miss bits. Though admittedly not these bits any longer.

      I can remove the NATIVE_BUILD conditions we currently use, I believe, but I don't think we can stop passing the condition.

    2. I wasn't suggesting we stop passing the condition. I hadn't realized that this was because of the system headers. So I think it's actually all fine.

  3. usr/src/tools/sgs/ld/Makefile (Diff revision 1)
     
     

    Minor thing, but it seems like some vars are spaced out and others are tabbed out. Should we make it consistent? This seems true of most of the Makefiles that are showing up under usr/src/tools/sgs.

    1. It's all a stew. I think I tried to be consistent with the file I was in, but I can do a second pass.

  4. usr/src/cmd/sgs/tools/Makefile.com (Diff revision 1)
     
     
    It seems weird to mention chkmsg here when I don't see it listed at all in the Makefile.
    1. You're right. I'd moved chckmsg too at one point, and forgot to undo this bit of that change

  5. usr/src/tools/cw/cw.c (Diff revision 1)
     
     
     
    Should we maybe allow an LD_ALTEXEC that was already set to override the one here?
    1. That's a good point, how do you envision that working? Do we do it in cw, or do we have make pass it --linker, or?

    2. I think I would probably have that bit there basically say something like:

      if (getenv("LD_ALTEXEC") == NULL || == "") {
              set LD_ALTXEC from --linker
      }
      
    3. It seems weird for cw to ignore --linker, but it seems weird for Makefile.master to interpret LD_ALTEXEC, too.
      Ugh.

    4. Is expecting people who wish to use a different link-editor to override the variable to make a bad answer?
      That is, to set LD in their build.

      (I will check that this works properly, if it's an acceptible answer)

    5. I don't like the surprise of LD_ALTEXEC being ignored, but I think that comes up rarely in testing this kind of thing and that one'd be able to just set the --linker argument in the makefile. So I guess that's fine.
    6. Makes sense, and I guess what you describe is pretty much equivalent to what's expected.

  6. usr/src/tools/sgs/include/Makefile (Diff revision 1)
     
     
    This is an interesting approach. Probably better than using -include.
    1. You've marked this as an issue, is that "an interesting approach" in the same sense as "interesting times" and you'd prefer -include?

    2. Sorry, that was erroneously marked as an issue. I think what's there now is reasonable.

  7. 
      
richlowe
Review request changed
rm
  1. Ship It!
  2. 
      
tsoome
  1. Ship It!
  2. 
      
yuripv
  1. Ship It!
  2. 
      
citrus
  1. Ship It!
  2. 
      
Loading...