| Message ID | 20101002202018.GA16460@bromo.med.uc.edu |
|---|---|
| State | New |
| Headers | show |
On 02/10/2010 21:20, Jack Howarth wrote: > Regarding part (b), I am unclear if this lto-plugin will require the use > of binuils on darwin. Well, yes, unless you can add it to cctools! > If so, it will definitely be a niche change for darwin > as the vast majority of users will want to build with FSF gcc using the standard > darwin cctools from Xcode. IMHO, binutils is not likely to be well supported on > darwin for use beyond cross-platform builds of the darwin target. I definitely > would not want to see lto require binutils for standard usage. OK, but bear in mind that whether we build/install it is separate from whether we actually invoke it at runtime in the installed compiler, which is controlled by whether we have -fuse-linker-plugin or not. I haven't yet figured out where exactly -fuse-linker-plugin comes from yet, but in general top-level configure can only decide what to build or not, while gcc/ subconfigure is responsible for knowing the details of how to invoke target native tools at runtime. So would you be OK with it getting built but unused, or would you like me to make it depend (in the darwin case only) on being configured --with-gnu-ld? cheers, DaveK
On Sat, Oct 02, 2010 at 10:17:14PM +0100, Dave Korn wrote: > On 02/10/2010 21:20, Jack Howarth wrote: > > > Regarding part (b), I am unclear if this lto-plugin will require the use > > of binuils on darwin. > > Well, yes, unless you can add it to cctools! > > > If so, it will definitely be a niche change for darwin > > as the vast majority of users will want to build with FSF gcc using the standard > > darwin cctools from Xcode. IMHO, binutils is not likely to be well supported on > > darwin for use beyond cross-platform builds of the darwin target. I definitely > > would not want to see lto require binutils for standard usage. > > OK, but bear in mind that whether we build/install it is separate from > whether we actually invoke it at runtime in the installed compiler, which is > controlled by whether we have -fuse-linker-plugin or not. I haven't yet > figured out where exactly -fuse-linker-plugin comes from yet, but in general > top-level configure can only decide what to build or not, while gcc/ > subconfigure is responsible for knowing the details of how to invoke target > native tools at runtime. So would you be OK with it getting built but unused, > or would you like me to make it depend (in the darwin case only) on being > configured --with-gnu-ld? Dave, I would lean towards tethering it --with-gnu-ld. Iain should be able to test this option since he appears to do regular builds against binutils for the darwin targets. Jack > > cheers, > DaveK
On 2 Oct 2010, at 22:59, Jack Howarth wrote: > On Sat, Oct 02, 2010 at 10:17:14PM +0100, Dave Korn wrote: >> On 02/10/2010 21:20, Jack Howarth wrote: >> >>> Regarding part (b), I am unclear if this lto-plugin will require >>> the use >>> of binuils on darwin. >> >> Well, yes, unless you can add it to cctools! it's worth a look - it's likely to be a lot closer target than binutils. >>> If so, it will definitely be a niche change for darwin >>> as the vast majority of users will want to build with FSF gcc >>> using the standard >>> darwin cctools from Xcode. IMHO, binutils is not likely to be well >>> supported on >>> darwin for use beyond cross-platform builds of the darwin target. >>> I definitely >>> would not want to see lto require binutils for standard usage. >> >> OK, but bear in mind that whether we build/install it is separate >> from >> whether we actually invoke it at runtime in the installed compiler, >> which is >> controlled by whether we have -fuse-linker-plugin or not. I >> haven't yet >> figured out where exactly -fuse-linker-plugin comes from yet, but >> in general >> top-level configure can only decide what to build or not, while gcc/ >> subconfigure is responsible for knowing the details of how to >> invoke target >> native tools at runtime. So would you be OK with it getting built >> but unused, >> or would you like me to make it depend (in the darwin case only) on >> being >> configured --with-gnu-ld? > > Dave, > I would lean towards tethering it --with-gnu-ld. Iain should be > able to test > this option since he appears to do regular builds against binutils > for the darwin > targets. As of now, bfd supports mach-o pretty well - (and therefore tools like objdump are functional). However, there is only partial support for mach-o/darwin in gas, and none (AFAIK) in ld. So, if we are to make use of this facility (in the near term) it will have to be in conjunction with darwin's own ld or a cctools merge. (and I have no idea what the magnitude of the integration task is there). Therefore, right now, we should stick with ensuring that the build machinery works (and anchor that to something safe, that won't scupper ordinary users) .. Then someone can work on filling in the gaps when we have some dev effort spare ;) also I have in mind (prob in 4.7 now) investigating splitting machopic out of darwin.c & config/{rs6000,i386} so that we can create darwin objects in other containers (read elf)... ... although the motivations for this stem from removing conditionals in the target sources ... ... that might open up some other opportunities... (Mike's suggestion to dispense with the asm between the compiler & collect is probably a neater solution all round). thanks for doing this Dave, Iain
On 02/10/2010 23:55, IainS wrote: > On 2 Oct 2010, at 22:59, Jack Howarth wrote: >> Dave, >> I would lean towards tethering it --with-gnu-ld. > However, there is only partial support for mach-o/darwin in gas, and > none (AFAIK) in ld. Well, that's the deal-breaker right there, I'm pretty sure. > Therefore, right now, we should stick with ensuring that the build > machinery works (and anchor that to something safe, that won't scupper > ordinary users) .. > Then someone can work on filling in the gaps when we have some dev > effort spare ;) Although it wouldn't kill anyone to build a dummy library that gets installed and never used, I'll tie it to gnu ld on darwin. cheers, DaveK
On 03/10/2010 02:05, Dave Korn wrote: >> However, there is only partial support for mach-o/darwin in gas, and >> none (AFAIK) in ld. > > Well, that's the deal-breaker right there, I'm pretty sure. > Although it wouldn't kill anyone to build a dummy library that gets > installed and never used, I'll tie it to gnu ld on darwin. Sorry, thinko. I mean "disable it altogether" on darwin. No point if neither cctools nor binutils support it. cheers, DaveK
Index: configure.ac =================================================================== --- configure.ac (revision 164904) +++ configure.ac (working copy) @@ -1788,7 +1788,7 @@ AC_SUBST(libelfinc) fi],[if test x"$default_enable_lto" = x"yes" ; then case $target in - *-apple-darwin*) ;; + *-cygwin*|*-mingw* | *-apple-darwin*) ;; # On other non-ELF platforms, LTO must be explicitly enabled. *) enable_lto=no ;; esac