Stefan Teleman wrote: > Ian Lance Taylor wrote: >> and dozens and dozens more wrote...
Rather than playing verbal games, is there anything productive we can do here? Ian seems to be saying that the GCC/G++ development team has indeed signed on to provide a stable-over-time ABI for their compilers. This is *great* news, although it seems that it really isn't new. Unfortunately, the G++ ABI is different than the SunStudio C++ one, which means developers still can't reuse libraries across the two compilers. What needs to be done going forward here? Should we try to get the two compilers to align with a future ABI (or ...?), does this allow us to recraft our compiler advice or rethink our stance on shared libs? I don't know (and I don't think we'd agree on a single set of answers, at least not at first), but it seems to me that it would be better to think proactively and positively than to complain about spilled milk. > Because: > A B C D E ... > f) i would like to keep everything as simple as possible. Myself, I think you are building unneeded complexity into "V4" on the uncertain presumption that the world will come to an end compatibility wise with "V5". "As simple as possible" doesn't seem to align well with "but I refuse to believe that the GNU developers value compatibility as much as I do"... Stefan Teleman wrote: > Since you seem convinced of the opposite, please explain to PSARC > exactly how is GCC going to find its assembler executable, at > run-time, after pkgadd, when the path to the assembler executable > was hardcoded at build time to: > > /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas Maybe explaining it to Stefan first might be better? :-) The answer seems obvious - either there is a flag day for the gatekeepers or you need to add a workaround to the compiler. Part of handling a flag day might require the installation of a new binutils, which seems to be the solution you found, though you seem to be making it harder than usual - have you actually *asked* one of the gatekeepers how they would recommend you handle this? Another approach might be to add a way to override the hardcoded path names via an envariable or command line flag, allowing you to deliver a compiler that #defines /bin/gas but (for the build process only) *uses* /builds2/steleman/.../bin/gas. (BTW, this all seems to me to be a natural and normal way to handle the bootstrapping of a new compiler - why is it coming across as being so hard?) -John
