On Fri, Dec 18, 2015 at 12:45:47PM -0800, Bob Wilson via cfe-commits wrote: > > > On Dec 17, 2015, at 10:59 AM, Bob Wilson via cfe-commits > > <cfe-commits@lists.llvm.org> wrote: > > > > > >> On Dec 17, 2015, at 10:16 AM, Joerg Sonnenberger via cfe-commits > >> <cfe-commits@lists.llvm.org> wrote: > >> > >> On Wed, Dec 16, 2015 at 11:59:10PM +0000, Bob Wilson via cfe-commits wrote: > >>> We can change this to be Darwin-specific if you prefer, but we should > >>> maintain compatibility with GCC and previous Clang releases in this > >>> behavior. > >> > >> Who is really affected by this? I don't care too much about obscure > >> Darwin hacks, but I really wonder why it isn't better to just explicitly > >> add -fno-PIC (e.g. when building a kernel module). It's not like that > >> will break on older versions of GCC or Clang. > > > > Apple has internal projects that are failing to build. This behavior has > > been in places for many years and I don’t even know how we could find all > > the people relying on this behavior. Yes, we could break them and force > > everyone to add -fno-PIC, but typically when we make disruptive and > > incompatible changes like that, we need to stage the changes and give > > people a transition plan. For example, we could keep the old behavior but > > add a warning about the change, something like “warning: -static may be > > changed in future versions of clang to stop implying -fno-PIC”. After a > > year or two, we could then go ahead with the change. That is all a lot of > > work and there needs to be some significant benefit to justify breaking > > compatibility with older compilers. I don’t see any significant benefit > > here. It’s a 2-line change to the driver. > > Joerg, I’m going to interpret your “I don’t care too much” comment as > an indication that you’re not opposed to moving forward with the > Darwin-specific change to restore the previous behavior. I went ahead > and committed the change in r256026.
Correct. > I can also add another data point on the impact. We just spent several > days tracking down a problem that turned out to be caused by this. The > code built successfully but crashed at run-time. It was extremely > difficult to figure out what was going wrong. OK, nasty. I'd like to see the warning suggested above at some point :) Joerg _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
