From johnf@sac.sfbay.sun.com Thu Oct 23 14:09:00 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NL90CB019275 for ; Thu, 23 Oct 2008 14:09:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NL8xAS021615; Thu, 23 Oct 2008 14:09:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700D01MQYXV00@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 15:08:58 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700KCNMQX2QC0@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 15:08:57 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9NL8puq047512; Thu, 23 Oct 2008 14:08:51 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NL8n0U019270; Thu, 23 Oct 2008 14:08:49 -0700 (PDT) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9NL8nFs019266; Thu, 23 Oct 2008 14:08:49 -0700 (PDT) Date: Thu, 23 Oct 2008 14:08:49 -0700 (PDT) From: John Fischer Subject: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] To: PSARC-ext@sun.com Cc: stefan.teleman@sun.com Message-id: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8345 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GNU binutils version 4.3.x 1.2. Name of Document Author/Supplier: Author: Stefan Teleman 1.3 Date of This Document: 23 October, 2008 4. Technical Description Including the GNU Binary Utilities [ GNU binutils ] 2.17 with Solaris Stefan Teleman October 23, 2008 1. Summary and motivation The GNU binutils [ version 2.15 ] [0] have already been included in the SFW Consolidation, in Solaris 10 FCS. [1] This FastTrack proposes the Integration of a more recent version of GNU binutils, which is compatible with Versions 4.3.x of the GNU Compiler Collection [ GCC ]. [2] This Case seeks Micro/Patch release binding. 2. Technical issues 2.1. Key objects /usr/gnu/gcc4/bin/addr2line /usr/gnu/gcc4/bin/c++filt /usr/gnu/gcc4/bin/gas /usr/gnu/gcc4/bin/gld /usr/gnu/gcc4/bin/gnm /usr/gnu/gcc4/bin/gobjcopy /usr/gnu/gcc4/bin/gobjdump /usr/gnu/gcc4/bin/gprof /usr/gnu/gcc4/bin/greadelf /usr/gnu/gcc4/bin/gsize /usr/gnu/gcc4/bin/gstrings /usr/gnu/gcc4/bin/gstrip /usr/gnu/gcc4/include/ansidecl.h /usr/gnu/gcc4/include/bfd.h /usr/gnu/gcc4/include/bfdlink.h /usr/gnu/gcc4/include/dis-asm.h /usr/gnu/gcc4/include/symcat.h /usr/gnu/gcc4/info/gas.info /usr/gnu/gcc4/info/bfd.info /usr/gnu/gcc4/info/binutils.info /usr/gnu/gcc4/info/configure.info /usr/gnu/gcc4/info/gprof.info /usr/gnu/gcc4/info/gld.info /usr/gnu/gcc4/info/standards.info /usr/gnu/gcc4/lib/libbfd-2.17.so /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so /usr/gnu/gcc4/lib/libopcodes-2.17.so /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so /usr/gnu/gcc4/man/man1/addr2line.1 /usr/gnu/gcc4/man/man1/gas.1 /usr/gnu/gcc4/man/man1/c++filt.1 /usr/gnu/gcc4/man/man1/gprof.1 /usr/gnu/gcc4/man/man1/gld.1 /usr/gnu/gcc4/man/man1/gnm.1 /usr/gnu/gcc4/man/man1/gobjcopy.1 /usr/gnu/gcc4/man/man1/gobjdump.1 /usr/gnu/gcc4/man/man1/greadelf.1 /usr/gnu/gcc4/man/man1/gsize.1 /usr/gnu/gcc4/man/man1/gstrings.1 /usr/gnu/gcc4/man/man1/gstrip.1 The following symbolic links will be provided under /usr/gnu, following the precedent set by PSARC/2007/047. [3] /usr/gnu/bin/addr2line -> /usr/gnu/gcc4/bin/addr2line /usr/gnu/bin/c++filt -> /usr/gnu/gcc4/bin/c++filt /usr/gnu/bin/gas -> /usr/gnu/gcc4/bin/gas /usr/gnu/bin/gld -> /usr/gnu/gcc4/bin/gld /usr/gnu/bin/gnm -> /usr/gnu/gcc4/bin/gnm /usr/gnu/bin/gobjcopy -> /usr/gnu/gcc4/bin/gobjcopy /usr/gnu/bin/gobjdump -> /usr/gnu/gcc4/bin/gobjdump /usr/gnu/bin/gprof -> /usr/gnu/gcc4/bin/gprof /usr/gnu/bin/greadelf -> /usr/gnu/gcc4/bin/greadelf /usr/gnu/bin/gsize -> /usr/gnu/gcc4/bin/gsize /usr/gnu/bin/gstrings -> /usr/gnu/gcc4/bin/gstrings /usr/gnu/bin/gstrip -> /usr/gnu/gcc4/bin/gstrip /usr/gnu/share/man/man1/addr2line.1 -> /usr/gnu/gcc4/man/man1/addr2line.1 /usr/gnu/share/man/man1/gas.1 -> /usr/gnu/gcc4/man/man1/gas.1 /usr/gnu/share/man/man1/c++filt.1 -> /usr/gnu/gcc4/man/man1/c++filt.1 /usr/gnu/share/man/man1/gprof.1 -> /usr/gnu/gcc4/man/man1/gprof.1 /usr/gnu/share/man/man1/gld.1 -> /usr/gnu/gcc4/man/man1/gld.1 /usr/gnu/share/man/man1/gnm.1 -> /usr/gnu/gcc4/man/man1/gnm.1 /usr/gnu/share/man/man1/gobjcopy.1 -> /usr/gnu/gcc4/man/man1/gobjcopy.1 /usr/gnu/share/man/man1/gobjdump.1 -> /usr/gnu/gcc4/man/man1/gobjdump.1 /usr/gnu/share/man/man1/greadelf.1 -> /usr/gnu/gcc4/man/man1/greadelf.1 /usr/gnu/share/man/man1/gsize.1 -> /usr/gnu/gcc4/man/man1/gsize.1 /usr/gnu/share/man/man1/gstrings.1 -> /usr/gnu/gcc4/man/man1/gstrings.1 /usr/gnu/share/man/man1/gstrip.1 -> /usr/gnu/gcc4/man/man1/gstrip.1 2.2. Documentation GNU binutils provide documentation in GNU texinfo, and in UNIX man page formats. Both documentation sets will be included in this Integration. 3. Interfaces 3.1. Interface Stability GNU binutils only provides executables. Although two shared libraries will be included in this Integration [ libbfd.so and libopcodes.so ], the interfaces exposed by these shared objects are classified as Project Private, and should no be relied upon, or used, by any other userland software application. The Interfaces exposed by GNU binutils' executables provide some level of consistency across releases. However, the binutils project is controlled by a group of developers external to SMI. It is to be expected that incompatible changes in Interfaces may occur in the future. 3.2. Imported Interfaces GNU binutils imports interfaces from the Standard C Library, the Standard Math Library, and the GCC-Dependent libgcc_s library. The latter creates a circular dependency between the compiler collection, and the binutils collection the compiler relies upon. This circular dependency will be intentionally broken at software construction time, by building GNU binutils twice: once with the existing GCC installed on the build system, and linked against the system available dynamic libgcc_s.so, and again with the newly built GCC, linking against the new GCC's static libgcc_s.a. This awkward software construction mechanism will eliminate binutils' run-time dynamic dependency on libgcc_s.so. 3.3. Exported Interfaces As a general principle, the command-line interfaces exposed by GNU binutils' executables, and ancillary documentation materials, will be formally assigned an Uncommmitted classification level. All other interfaces expsed by GNU binutils are classified as Project Private. NAME STABILITY NOTES SUNWgnu-binutils217 Uncommitted Package Name /usr/gnu/gcc4/bin/addr2line Uncommitted Executable /usr/gnu/gcc4/bin/c++filt Uncommitted Executable /usr/gnu/gcc4/bin/gas Uncommitted Executable /usr/gnu/gcc4/bin/gld Uncommitted Executable /usr/gnu/gcc4/bin/gnm Uncommitted Executable /usr/gnu/gcc4/bin/gobjcopy Uncommitted Executable /usr/gnu/gcc4/bin/gobjdump Uncommitted Executable /usr/gnu/gcc4/bin/gprof Uncommitted Executable /usr/gnu/gcc4/bin/greadelf Uncommitted Executable /usr/gnu/gcc4/bin/gsize Uncommitted Executable /usr/gnu/gcc4/bin/gstrings Uncommitted Executable /usr/gnu/gcc4/bin/gstrip Uncommitted Executable /usr/gnu/gcc4/info/gas.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/bfd.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/binutils.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/configure.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/gprof.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/gld.info Uncommitted GNU texinfo /usr/gnu/gcc4/info/standards.info Uncommitted GNU texinfo /usr/gnu/gcc4/man/man1/addr2line.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gas.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/c++filt.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gprof.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gld.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gnm.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gobjcopy.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gobjdump.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/greadelf.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gsize.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gstrings.1 Uncommitted UNIX man page /usr/gnu/gcc4/man/man1/gstrip.1 Uncommitted UNIX man page Identical Interface Stability Classification levels apply to the corresponding symbolic links in /usr/gnu/bin and /usr/gnu/share/man. /usr/gnu/gcc4/include/ansidecl.h Project Private Header file /usr/gnu/gcc4/include/bfd.h Project Private Header file /usr/gnu/gcc4/include/bfdlink.h Project Private Header file /usr/gnu/gcc4/include/dis-asm.h Project Private Header file /usr/gnu/gcc4/include/symcat.h Project Private Header file /usr/gnu/gcc4/lib/libbfd-2.17.so Project Private Shared Library /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so Project Private Symbolic link /usr/gnu/gcc4/lib/libopcodes-2.17.so Project Private Shared Library /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so Project Private Symbolic link 4. References [0] http://www.gnu.org/software/binutils/ [1] PSARC/2004/742 [2] http://gcc.gnu.org/ [3] PSARC/2007/047 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@sun.com Thu Oct 23 14:36:12 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NLaCw2019815 for ; Thu, 23 Oct 2008 14:36:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NLa9l2011980; Thu, 23 Oct 2008 15:36:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700903O0BFT00@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Oct 2008 14:36:11 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K97004O9O0AP580@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Oct 2008 14:36:10 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9NLZimM021464; Thu, 23 Oct 2008 16:35:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9NLZiZv021463; Thu, 23 Oct 2008 16:35:44 -0500 (CDT) Date: Thu, 23 Oct 2008 16:35:44 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> To: John Fischer Cc: PSARC-ext@sun.com, Stefan.Teleman@sun.com Message-id: <20081023213543.GX21103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 573 On Thu, Oct 23, 2008 at 02:08:49PM -0700, John Fischer wrote: > /usr/gnu/gcc4/bin/addr2line > /usr/gnu/gcc4/bin/c++filt > /usr/gnu/gcc4/bin/gas > /usr/gnu/gcc4/bin/gld > ... > > The following symbolic links will be provided under /usr/gnu, > following the precedent set by PSARC/2007/047. [3] > > /usr/gnu/bin/addr2line -> /usr/gnu/gcc4/bin/addr2line > /usr/gnu/bin/c++filt -> /usr/gnu/gcc4/bin/c++filt > /usr/gnu/bin/gas -> /usr/gnu/gcc4/bin/gas > /usr/gnu/bin/gld -> /usr/gnu/gcc4/bin/gld Can't non-conflicting names be installed in /usr/bin too? Nico -- From carlsonj@phorcys.east.sun.com Thu Oct 23 14:40:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NLerot020003 for ; Thu, 23 Oct 2008 14:40:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9NLemWV028399; Thu, 23 Oct 2008 22:40:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700901O82NO00@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Oct 2008 14:40:50 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K97004XPO81P390@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Oct 2008 14:40:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NLemAI007271; Thu, 23 Oct 2008 17:40:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9NLemJc007268; Thu, 23 Oct 2008 17:40:48 -0400 (EDT) Date: Thu, 23 Oct 2008 17:40:48 -0400 From: James Carlson Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> To: John Fischer Cc: PSARC-ext@sun.com, Stefan.Teleman@sun.com Message-id: <18688.61280.741889.940523@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> Status: RO Content-Length: 891 John Fischer writes: > This FastTrack proposes the Integration of a more recent version > of GNU binutils, which is compatible with Versions 4.3.x of the > GNU Compiler Collection [ GCC ]. [2] Will this stuff eventually be moving to /usr/bin? It doesn't seem to need to be in /usr/gnu, as it's all g-prefixed already, and having those functions work without path trouble would be nice. > /usr/gnu/bin/gobjcopy -> /usr/gnu/gcc4/bin/gobjcopy > /usr/gnu/bin/gobjdump -> /usr/gnu/gcc4/bin/gobjdump > /usr/gnu/bin/gprof -> /usr/gnu/gcc4/bin/gprof That's odd, and doesn't seem to follow PSARC 2007/047. Why would the /usr/gnu/bin links have g-prefixes as well? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Stefan.Teleman@sun.com Thu Oct 23 15:10:55 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NMAtuZ020890 for ; Thu, 23 Oct 2008 15:10:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9NMAqbE022398; Thu, 23 Oct 2008 16:10:54 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700I03PM5NE00@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 16:10:53 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700I5MPM4D300@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 16:10:52 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9NMA2lT600314; Thu, 23 Oct 2008 15:10:09 -0700 (PDT) Date: Thu, 23 Oct 2008 18:10:02 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18688.61280.741889.940523@gargle.gargle.HOWL> To: James Carlson Cc: John Fischer , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <4900F63A.3070109@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1968 James Carlson wrote: > John Fischer writes: >> This FastTrack proposes the Integration of a more recent version >> of GNU binutils, which is compatible with Versions 4.3.x of the >> GNU Compiler Collection [ GCC ]. [2] > > Will this stuff eventually be moving to /usr/bin? Yes. The idea is to add add symlinks to /usr/bin for GCC 4.3.2. This implies that we favor this particular version of GCC over a future one. This also implies that we need some plan for GCC4 upgrade paths, and what happens with the existing /usr/bin symlinks: do they always follow the latest version, or do they stay immutable ? There are valid arguments for either approach. Future versions of GCC might generate binaries incompatible with existing binaries generated with existing versions of GCC. On the other hand, changing symlinks every single time GCC revs up can be confusing for the developers. > It doesn't seem to need to be in /usr/gnu, as it's all g-prefixed > already, and having those functions work without path trouble would be > nice. The symlinks in /usr/bin will take care of easy discovery. They do need to be in /usr/gnu/gcc4, because these binutils are specific to/for GCC4. We don't know what happens when we integrate GCC5. "Things" might not be backwards compatible with GCC4, and we most likely want to keep the older GCC4 version around for a while. > >> /usr/gnu/bin/gobjcopy -> /usr/gnu/gcc4/bin/gobjcopy >> /usr/gnu/bin/gobjdump -> /usr/gnu/gcc4/bin/gobjdump >> /usr/gnu/bin/gprof -> /usr/gnu/gcc4/bin/gprof > > That's odd, and doesn't seem to follow PSARC 2007/047. Why would the > /usr/gnu/bin links have g-prefixes as well? Because by default some of the binaries in binutils are already prefixed with 'g', and some others aren't. I find this confusing and inconsistent, therefore i am making a ruling on the naming convention for all the executables. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From danek.duvall@sun.com Thu Oct 23 15:48:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9NMmtCg021278 for ; Thu, 23 Oct 2008 15:48:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9NMmkfg002262 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 06:48:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K970040HRDGBZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 15:48:52 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K97004WKRDF2B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 15:48:51 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9NMmjhX044164; Thu, 23 Oct 2008 15:48:45 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9NMo4bi017375; Thu, 23 Oct 2008 15:50:04 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9NMo43g017374; Thu, 23 Oct 2008 15:50:04 -0700 (PDT) Date: Thu, 23 Oct 2008 15:50:04 -0700 From: Danek Duvall Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4900F63A.3070109@Sun.COM> To: Stefan Teleman Cc: James Carlson , John Fischer , PSARC-ext@sun.com Message-id: <20081023225004.GR7489@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 608 On Thu, Oct 23, 2008 at 06:10:02PM -0400, Stefan Teleman wrote: > They do need to be in /usr/gnu/gcc4, because these binutils are specific > to/for GCC4. We don't know what happens when we integrate GCC5. "Things" > might not be backwards compatible with GCC4, and we most likely want to > keep the older GCC4 version around for a while. I thought binutils was generally pretty good about backwards compatibility -- that you could always have the latest version on your system and have it work with the old compilers. Is that not actually the case, or is known not to be the case in the future? Danek From Stefan.Teleman@sun.com Thu Oct 23 18:37:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9O1bZRw026268 for ; Thu, 23 Oct 2008 18:37:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9O1bTcB013666; Fri, 24 Oct 2008 02:37:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700005Z6KEP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Oct 2008 18:37:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K97008VDZ6KKL80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 23 Oct 2008 18:37:32 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9O1an8Z663079; Thu, 23 Oct 2008 18:36:56 -0700 (PDT) Date: Thu, 23 Oct 2008 21:36:49 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081023225004.GR7489@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <490126B1.5000407@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <20081023225004.GR7489@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 968 Danek Duvall wrote: > On Thu, Oct 23, 2008 at 06:10:02PM -0400, Stefan Teleman wrote: > >> They do need to be in /usr/gnu/gcc4, because these binutils are specific >> to/for GCC4. We don't know what happens when we integrate GCC5. "Things" >> might not be backwards compatible with GCC4, and we most likely want to >> keep the older GCC4 version around for a while. > > I thought binutils was generally pretty good about backwards compatibility > -- that you could always have the latest version on your system and have it > work with the old compilers. Is that not actually the case, or is known > not to be the case in the future? We don't know what will happen in the future. I am much less concerned about the binary utilities like objdump or objcopy, but I am concerned about future compatibility of the GNU assembler, which is currently required to build any bits on i386. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From danek.duvall@sun.com Thu Oct 23 18:54:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9O1sEjj026610 for ; Thu, 23 Oct 2008 18:54:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9O1s8mf017916 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 02:54:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9700L0NZYBTA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 18:54:11 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9700GFYZYAJA30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 18:54:10 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9O1s1gB004379; Thu, 23 Oct 2008 18:54:01 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9O1tJ5t019775; Thu, 23 Oct 2008 18:55:19 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9O1tJ71019774; Thu, 23 Oct 2008 18:55:19 -0700 (PDT) Date: Thu, 23 Oct 2008 18:55:19 -0700 From: Danek Duvall Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <490126B1.5000407@Sun.COM> To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Message-id: <20081024015519.GL23882@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <20081023225004.GR7489@mumak.SFBay.Sun.COM> <490126B1.5000407@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 924 On Thu, Oct 23, 2008 at 09:36:49PM -0400, Stefan Teleman wrote: >> I thought binutils was generally pretty good about backwards >> compatibility -- that you could always have the latest version on your >> system and have it work with the old compilers. Is that not actually >> the case, or is known not to be the case in the future? > > We don't know what will happen in the future. I am much less concerned > about the binary utilities like objdump or objcopy, but I am concerned > about future compatibility of the GNU assembler, which is currently > required to build any bits on i386. So a) why put all this stuff under gcc4, making it look like you're worried about compatibility across gcc versions b) why not single out gas, and/or c) why not just make sure that before pulling in a new version of binutils, the new gas is capable of being the assembler for the portions of the OS build that require it? Danek From johnlev@barman.uk.sun.com Thu Oct 23 18:56:55 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9O1uspx026637 for ; Thu, 23 Oct 2008 18:56:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9O1uhdp029002 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 09:56:53 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800D0D02RGD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 19:56:51 -0600 (MDT) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9800IP702QCXB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 23 Oct 2008 19:56:51 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9O1uc4o005532; Fri, 24 Oct 2008 02:56:39 +0100 (BST) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1KtBxz-0007Eu-MC; Fri, 24 Oct 2008 02:59:55 +0100 X-URL: http://jurassic.eng/~johnlev/ Date: Fri, 24 Oct 2008 02:59:55 +0100 From: John Levon Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081023225004.GR7489@mumak.SFBay.Sun.COM> Sender: John Levon To: Danek Duvall Cc: Stefan Teleman , James Carlson , John Fischer , PSARC-ext@sun.com Message-id: <20081024015955.GE27110@barman.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <20081023225004.GR7489@mumak.SFBay.Sun.COM> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 712 On Thu, Oct 23, 2008 at 03:50:04PM -0700, Danek Duvall wrote: > > They do need to be in /usr/gnu/gcc4, because these binutils are specific > > to/for GCC4. We don't know what happens when we integrate GCC5. "Things" > > might not be backwards compatible with GCC4, and we most likely want to > > keep the older GCC4 version around for a while. > > I thought binutils was generally pretty good about backwards compatibility > -- that you could always have the latest version on your system and have it > work with the old compilers. Is that not actually the case, or is known > not to be the case in the future? I've seen gas complain about old gcc assembly before. It was a while ago, mind. regards john From Stefan.Teleman@sun.com Thu Oct 23 19:10:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9O2A37I026756 for ; Thu, 23 Oct 2008 19:10:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9O2A2RV020847; Thu, 23 Oct 2008 19:10:03 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800E010OQJW00@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 20:10:02 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9800I4O0OQD8C0@brm-avmta-1.central.sun.com>; Thu, 23 Oct 2008 20:10:02 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9O29Dw2667074; Thu, 23 Oct 2008 19:09:19 -0700 (PDT) Date: Thu, 23 Oct 2008 22:09:09 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081024015519.GL23882@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <49012E45.7080407@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <20081023225004.GR7489@mumak.SFBay.Sun.COM> <490126B1.5000407@Sun.COM> <20081024015519.GL23882@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2123 Danek Duvall wrote: > On Thu, Oct 23, 2008 at 09:36:49PM -0400, Stefan Teleman wrote: > >>> I thought binutils was generally pretty good about backwards >>> compatibility -- that you could always have the latest version on your >>> system and have it work with the old compilers. Is that not actually >>> the case, or is known not to be the case in the future? >> We don't know what will happen in the future. I am much less concerned >> about the binary utilities like objdump or objcopy, but I am concerned >> about future compatibility of the GNU assembler, which is currently >> required to build any bits on i386. > > So a) why put all this stuff under gcc4, making it look like you're worried > about compatibility across gcc versions Because i am concerned about binutils compatibility across gcc versions. b) why not single out gas, and/or > c) why not just make sure that before pulling in a new version of binutils, > the new gas is capable of being the assembler for the portions of the OS > build that require it? Because: d) GCC5 might require a new and as-of-yet unwritten version of gas which is not compatible with GCC4 e) i am not concerned about maintaining compatibility of binutils within a GCC4 release. i am, however, concerned about compatibility when we introduce GCC5, and we have to maintain both GCC4 and GCC5, at least for a while. Hence the implication for a /usr/gnu/gcc5 directory tree, when that becomes necessary. f) i would like to keep everything as simple as possible. Creating build time dependencies of the "objdump and objcopy come from binutils 2.17 but gas comes from binutils 2.21 and readelf from binutils 2.23 because these are the only versions which works with two different GCC's" kind, is not, in my mind, simple. The approach currently proposed here is for every Major Version of GCC to have its own set of binutils, known to work with that particular major version. Retirement of one Major Version of GCC also implies retirement of its corresponding binutils collection. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From ro@techfak.uni-bielefeld.de Fri Oct 24 03:37:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OAbBCN007849 for ; Fri, 24 Oct 2008 03:37:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OAb9oa003872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 11:37:11 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800903O5YGY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 04:37:10 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98000P3O5X6C40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 04:37:10 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OAUn4m029894 for ; Fri, 24 Oct 2008 10:37:09 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-2021611 for PSARC-ext@sun.com; Fri, 24 Oct 2008 10:37:08 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-88636 for PSARC-ext@sun.com; Fri, 24 Oct 2008 10:37:07 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1ib.sun.com with ESMTP id BT-MMP-28506696 for PSARC-ext@sun.com; Fri, 24 Oct 2008 10:37:06 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 47F8148358; Fri, 24 Oct 2008 12:37:06 +0200 (CEST) Date: Fri, 24 Oct 2008 12:37:00 +0200 From: Rainer Orth Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: John Fischer's message of "Thu, 23 Oct 2008 14:08:49 -0700 (PDT)" Sender: ro@techfak.uni-bielefeld.de To: John Fischer Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.062sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 70 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> Status: RO Content-Length: 2445 John Fischer writes: > 4. Technical Description > Including the GNU Binary Utilities [ GNU binutils ] 2.17 with Solaris Why include binutils 2.17 when 2.18 is already released? > 1. Summary and motivation > > The GNU binutils [ version 2.15 ] [0] have already been included > in the SFW Consolidation, in Solaris 10 FCS. [1] > > This FastTrack proposes the Integration of a more recent version > of GNU binutils, which is compatible with Versions 4.3.x of the > GNU Compiler Collection [ GCC ]. [2] This is not true: all recent versions up to and including GCC mainline (to become 4.4) happily build and run with binutils 2.15 (gas 2.15, to be exact). I regularly test that (at least on x86, on SPARC I generally prefer Sun as). > 2. Technical issues > > 2.1. Key objects > > /usr/gnu/gcc4/bin/addr2line > /usr/gnu/gcc4/bin/c++filt > /usr/gnu/gcc4/bin/gas > /usr/gnu/gcc4/bin/gld > /usr/gnu/gcc4/bin/gnm > /usr/gnu/gcc4/bin/gobjcopy > /usr/gnu/gcc4/bin/gobjdump > /usr/gnu/gcc4/bin/gprof > /usr/gnu/gcc4/bin/greadelf > /usr/gnu/gcc4/bin/gsize > /usr/gnu/gcc4/bin/gstrings > /usr/gnu/gcc4/bin/gstrip I've always found it easily possible to drop in a more recent version of gas with an existing gcc. Others have already commented on the g-prefixing: it's completely contrary to the spirit of /usr/gnu. > /usr/gnu/gcc4/lib/libbfd-2.17.so > /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so > /usr/gnu/gcc4/lib/libopcodes-2.17.so > /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so [...] > 3. Interfaces > > 3.1. Interface Stability > > GNU binutils only provides executables. Although two shared libraries > will be included in this Integration [ libbfd.so and libopcodes.so ], > the interfaces exposed by these shared objects are classified as > Project Private, and should no be relied upon, or used, by any other > userland software application. In that case, there should be *no* compilation symlinks like libbfd.so anywhere, just the specific versions used. Btw., the list above doesn't list those specific versions (like libbfd.so.) at all. Beyond that, a default build of binutils doesn't build a shared libbfd, but links it statically exactly because the interface isn't stable and rapidly changes between releases. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Joerg.Schilling@fokus.fraunhofer.de Fri Oct 24 05:17:53 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OCHqfB010017 for ; Fri, 24 Oct 2008 05:17:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OCHZCb012248; Fri, 24 Oct 2008 13:17:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K980040BSTMZI00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 05:17:46 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K980012ASTL9OE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 05:17:45 -0700 (PDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9OCFfs4017021; Fri, 24 Oct 2008 12:17:45 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay17i.sun.com with ESMTP id BT-MMP-1047528; Fri, 24 Oct 2008 12:17:44 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-219998; Fri, 24 Oct 2008 12:17:44 +0000 (Z) Received: from iron02.fraunhofer.de ([153.96.1.56] [153.96.1.56]) by relay1ib.sun.com with ESMTP id BT-MMP-28604799; Fri, 24 Oct 2008 12:17:44 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Fri, 24 Oct 2008 14:17:44 +0200 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m9OCHgYL017574; Fri, 24 Oct 2008 14:17:42 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 14:17:43 +0200 Date: Fri, 24 Oct 2008 14:17:42 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18688.61280.741889.940523@gargle.gargle.HOWL> To: johnf@sac.sfbay.sun.com, james.d.carlson@sun.com Cc: Stefan.Teleman@sun.com, PSARC-ext@sun.com Message-id: <4901bce6.3mu9Z9yRV13wQD8J%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.258sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 24 Oct 2008 12:17:43.0001 (UTC) FILETIME=[83F47490:01C935D2] Status: RO Content-Length: 1110 James Carlson wrote: > John Fischer writes: > > This FastTrack proposes the Integration of a more recent version > > of GNU binutils, which is compatible with Versions 4.3.x of the > > GNU Compiler Collection [ GCC ]. [2] > > Will this stuff eventually be moving to /usr/bin? > > It doesn't seem to need to be in /usr/gnu, as it's all g-prefixed > already, and having those functions work without path trouble would be > nice. > > > /usr/gnu/bin/gobjcopy -> /usr/gnu/gcc4/bin/gobjcopy > > /usr/gnu/bin/gobjdump -> /usr/gnu/gcc4/bin/gobjdump > > /usr/gnu/bin/gprof -> /usr/gnu/gcc4/bin/gprof > > That's odd, and doesn't seem to follow PSARC 2007/047. Why would the > /usr/gnu/bin links have g-prefixes as well? "gprof" is a _BSD_ invented program that has been on SunOS for ever. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From carlsonj@phorcys.east.sun.com Fri Oct 24 05:34:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OCYB36010395 for ; Fri, 24 Oct 2008 05:34:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OCXs4e019308; Fri, 24 Oct 2008 13:34:09 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800I01TKV5I00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 06:34:07 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98000MMTKU6S90@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 06:34:06 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OCY5mY008743; Fri, 24 Oct 2008 08:34:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9OCY5Bh008740; Fri, 24 Oct 2008 08:34:05 -0400 (EDT) Date: Fri, 24 Oct 2008 08:34:05 -0400 From: James Carlson Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4900F63A.3070109@Sun.COM> To: Stefan Teleman Cc: John Fischer , PSARC-ext@sun.com Message-id: <18689.49341.355047.257091@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> Status: RO Content-Length: 1816 Stefan Teleman writes: > > Will this stuff eventually be moving to /usr/bin? > > Yes. The idea is to add add symlinks to /usr/bin for GCC 4.3.2. Are those symlinks part of this project or part of some other project? I'm a bit confused about what's going on here. On a Nevada 101 system, I see no /usr/bin/gas on the system at all, though it does have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from SUNWbinutils that points over to /usr/sfw. What the ... ? > This implies > that we favor this particular version of GCC over a future one. This also > implies that we need some plan for GCC4 upgrade paths, and what happens with the > existing /usr/bin symlinks: do they always follow the latest version, or do they > stay immutable ? Following newest installed makes the most sense to me. > Because by default some of the binaries in binutils are already prefixed with > 'g', and some others aren't. I find this confusing and inconsistent, therefore i > am making a ruling on the naming convention for all the executables. When we create the /usr/bin symlinks (and it's unclear to me whether we have done this yet or not!), I think we should try to be as consistent with other platforms as possible, even if the historical name used in /usr/sfw/bin (and thus the symlink left behind there) may have been different. That's all I'm asking. I can understand 'gar' and 'gas' because of the obvious conflicts. 'gobjcopy' is a little less obvious, at least to me ... but if that's expected, then ok. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Fri Oct 24 05:36:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OCa2gE010502 for ; Fri, 24 Oct 2008 05:36:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OCZiOr021347 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 20:36:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800709TNZ0J00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 05:35:59 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98005MSTNYFJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 05:35:59 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OCZwCT003549 for ; Fri, 24 Oct 2008 12:35:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9800501RV06400@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 13:35:58 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9800FE2TNOE180@fe-emea-10.sun.com>; Fri, 24 Oct 2008 13:35:50 +0100 (BST) Date: Fri, 24 Oct 2008 13:35:48 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: John Fischer Cc: PSARC-ext@sun.com, Stefan Teleman Message-id: <4901C124.2050601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1570 I don't see the point of having /usr/gnu/gcc4/bin/* and then having symlinks to /usr/gnu/bin/*. Why not just put them directly in /usr/gnu/bin/* ? We don't have gcc 4.x at this time anyway so it seems really strange to have a gcc4 subdir introduced by something that isn'g gcc 4.x. As others have pointed out the 'g' prefix should NOT be used in /usr/gnu/bin/ that is only appropriate for /usr/bin & /usr/sbin and ONLY when there is an already existing thing that exists by that basename that can not be fully replaced without introducing a compatibility problem. /usr/bin/tar vs /usr/bin/gtar vs /usr/gnu/bin/tar is classic example of this. For this case /usr/gnu/bin/gstrings is wrong it should be /usr/gnu/bin/strings. The whole point of /usr/gnu/bin is that things appear under their "native" names. The same applies to some of the other commands that this case delivers. As specified I do NOT approve of this case, I would like to see the following: /usr/gnu/bin/* with the "native" names /usr/bin/g* for ONLY those that clash /usr/bin/* for those with no clash elimination of /usr/gnu/gcc4/ This is on the assumption that GNU binutils 4.3.x is NOT incompatible with the gcc we currently ship. If GNU binutils *is* incompatible with the gcc we currently ship then IMO this case needs to wait and be part of a future case that upgrade gcc as well, otherwise I don't see the point in shipping the newer binutils if we ship the older compiler (unless the newer binutils are compatible with the compiler we ship). -- Darren J Moffat From Stefan.Teleman@Sun.COM Fri Oct 24 06:57:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9ODvAXI012273 for ; Fri, 24 Oct 2008 06:57:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9ODv3Rr001152 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 24 Oct 2008 07:57:09 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800F1BXF78900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 24 Oct 2008 06:57:07 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98005LMXF6FI40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 24 Oct 2008 06:57:06 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9ODuwCC728439; Fri, 24 Oct 2008 06:56:58 -0700 (PDT) Date: Fri, 24 Oct 2008 09:56:57 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: To: Rainer Orth Cc: John Fischer , PSARC-ext@Sun.COM Reply-to: Stefan Teleman Message-id: <4901D429.1060603@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 3530 Rainer Orth wrote: > John Fischer writes: > >> 4. Technical Description >> Including the GNU Binary Utilities [ GNU binutils ] 2.17 with Solaris > > Why include binutils 2.17 when 2.18 is already released? Because binutils 2.18's gas generates a bogus .eh_frame section in crtend.o (incomplete CIE + FDE subsequent frames with invalid offsets), and also generates invalid instructions, and this results in non-functional bits on Solaris. binutils 2.17 does not exhibit this problem. This problem has already been widely reported. I am not relying on reports, I am relying on binutils 2.18's bits. This is binutils built with the existing gcc 3.2.3, and not with Studio. This problem has already been widely reported. >> This FastTrack proposes the Integration of a more recent version >> of GNU binutils, which is compatible with Versions 4.3.x of the >> GNU Compiler Collection [ GCC ]. [2] > > This is not true: all recent versions up to and including GCC mainline (to > become 4.4) happily build and run with binutils 2.15 (gas 2.15, to be exact). > I regularly test that (at least on x86, on SPARC I generally prefer Sun as). Please see my comment above. In addition, there were Solaris specific patches for binutils 2.15 which have been accepted into 2.17. Therefore, no more patch maintenance for 2.17. > >> 2. Technical issues >> >> 2.1. Key objects >> >> /usr/gnu/gcc4/bin/addr2line >> /usr/gnu/gcc4/bin/c++filt >> /usr/gnu/gcc4/bin/gas >> /usr/gnu/gcc4/bin/gld >> /usr/gnu/gcc4/bin/gnm >> /usr/gnu/gcc4/bin/gobjcopy >> /usr/gnu/gcc4/bin/gobjdump >> /usr/gnu/gcc4/bin/gprof >> /usr/gnu/gcc4/bin/greadelf >> /usr/gnu/gcc4/bin/gsize >> /usr/gnu/gcc4/bin/gstrings >> /usr/gnu/gcc4/bin/gstrip > > I've always found it easily possible to drop in a more recent version of > gas with an existing gcc. Again, please see my comment above about binutils 2.18. > Others have already commented on the g-prefixing: it's completely contrary > to the spirit of /usr/gnu. > >> /usr/gnu/gcc4/lib/libbfd-2.17.so >> /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so >> /usr/gnu/gcc4/lib/libopcodes-2.17.so >> /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so > [...] >> 3. Interfaces >> >> 3.1. Interface Stability >> >> GNU binutils only provides executables. Although two shared libraries >> will be included in this Integration [ libbfd.so and libopcodes.so ], >> the interfaces exposed by these shared objects are classified as >> Project Private, and should no be relied upon, or used, by any other >> userland software application. > > In that case, there should be *no* compilation symlinks like libbfd.so > anywhere, just the specific versions used. Why ? > Btw., the list above doesn't list those specific versions (like libbfd.so.) at all. /usr/gnu/gcc4/lib/libbfd-2.17.so /usr/gnu/gcc4/lib/libopcodes-2.17.so These are the names of the objects generated by binutils. I have no intention to change the default generated object names by introducing unnecessary patches to binutils' build system, just for the sake of changing the default generated object names. > Beyond that, a > default build of binutils doesn't build a shared libbfd, but links it > statically exactly because the interface isn't stable and rapidly changes > between releases. Binutils builds what it is being told to build. In this particular case, I am telling it to build shared libraries. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Darren.Moffat@sun.com Fri Oct 24 07:04:25 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OE4O8A012443 for ; Fri, 24 Oct 2008 07:04:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OE4JQG025696 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 15:04:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800111XRAGR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 08:04:22 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98000MTXR56DC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 08:04:21 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OE4H9I007939 for ; Fri, 24 Oct 2008 14:04:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9800K01VPXE000@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 15:04:17 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K98007W2XQX9SA0@fe-emea-09.sun.com>; Fri, 24 Oct 2008 15:04:10 +0100 (BST) Date: Fri, 24 Oct 2008 15:04:09 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901D429.1060603@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: Rainer Orth , John Fischer , PSARC-ext@sun.com Message-id: <4901D5D9.60900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 2588 Stefan Teleman wrote: > > > Rainer Orth wrote: >> John Fischer writes: >> >>> 4. Technical Description >>> Including the GNU Binary Utilities [ GNU binutils ] 2.17 with Solaris >> >> Why include binutils 2.17 when 2.18 is already released? > > Because binutils 2.18's gas generates a bogus .eh_frame section in crtend.o > (incomplete CIE + FDE subsequent frames with invalid offsets), and also > generates invalid instructions, and this results in non-functional bits > on Solaris. binutils 2.17 does not exhibit this problem. > > This problem has already been widely reported. I am not relying on > reports, I am relying on binutils 2.18's bits. > > This is binutils built with the existing gcc 3.2.3, and not with Studio. > > This problem has already been widely reported. > > >>> This FastTrack proposes the Integration of a more recent version >>> of GNU binutils, which is compatible with Versions 4.3.x of the >>> GNU Compiler Collection [ GCC ]. [2] >> >> This is not true: all recent versions up to and including GCC mainline >> (to >> become 4.4) happily build and run with binutils 2.15 (gas 2.15, to be >> exact). >> I regularly test that (at least on x86, on SPARC I generally prefer >> Sun as). > > Please see my comment above. > > In addition, there were Solaris specific patches for binutils 2.15 which > have been accepted into 2.17. Therefore, no more patch maintenance for > 2.17. > >> >>> 2. Technical issues >>> >>> 2.1. Key objects >>> >>> /usr/gnu/gcc4/bin/addr2line >>> /usr/gnu/gcc4/bin/c++filt >>> /usr/gnu/gcc4/bin/gas >>> /usr/gnu/gcc4/bin/gld >>> /usr/gnu/gcc4/bin/gnm >>> /usr/gnu/gcc4/bin/gobjcopy >>> /usr/gnu/gcc4/bin/gobjdump >>> /usr/gnu/gcc4/bin/gprof >>> /usr/gnu/gcc4/bin/greadelf >>> /usr/gnu/gcc4/bin/gsize >>> /usr/gnu/gcc4/bin/gstrings >>> /usr/gnu/gcc4/bin/gstrip >> >> I've always found it easily possible to drop in a more recent version of >> gas with an existing gcc. > > Again, please see my comment above about binutils 2.18. Your justification supports using binutils 2.17 over 2.18 because of a 2.18 but but it doesn't follow that you create this gcc4 subdir, because your rationale has nothing to do with gcc4 but to do with a bug in binutils 2.18. If the idea is to support multiple copies of binutils then IMO the dir structure should be more like /usr/gnu/binutils/2.17/bin/. However I still don't see the point in that, since 2.18 isn't incompatible it is just plain broken on Solaris. -- Darren J Moffat From Stefan.Teleman@sun.com Fri Oct 24 07:06:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OE6Fku012464 for ; Fri, 24 Oct 2008 07:06:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OE6BxE022082; Fri, 24 Oct 2008 22:06:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800A0VXUBAF00@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 07:06:11 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98008HEXUBR530@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 07:06:11 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OE69fS729846; Fri, 24 Oct 2008 07:06:10 -0700 (PDT) Date: Fri, 24 Oct 2008 10:06:08 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18689.49341.355047.257091@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901D650.3080205@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1529 James Carlson wrote: > Stefan Teleman writes: >>> Will this stuff eventually be moving to /usr/bin? >> Yes. The idea is to add add symlinks to /usr/bin for GCC 4.3.2. > > Are those symlinks part of this project or part of some other project? > > I'm a bit confused about what's going on here. On a Nevada 101 > system, I see no /usr/bin/gas on the system at all, though it does > have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an > OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from > SUNWbinutils that points over to /usr/sfw. > > What the ... ? That was my implied point. There does not seem to be a consistent approach here, with the existing SUNWbinutils. > When we create the /usr/bin symlinks (and it's unclear to me whether > we have done this yet or not!), I think we should try to be as > consistent with other platforms as possible, even if the historical > name used in /usr/sfw/bin (and thus the symlink left behind there) may > have been different. > > That's all I'm asking. I can understand 'gar' and 'gas' because of > the obvious conflicts. 'gobjcopy' is a little less obvious, at least > to me ... but if that's expected, then ok. I am just as confused as you are. I was under the very distinct impression that the existing SUNWbinutils will deliver symlinks in /usr/bin. But then, that did not appear to be the case. I therefore concluded that the symlinks were removed for a reason. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From carlsonj@phorcys.east.sun.com Fri Oct 24 07:14:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OEEDrm012669 for ; Fri, 24 Oct 2008 07:14:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OEEACF025032; Fri, 24 Oct 2008 22:14:10 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800201Y7L3G00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 08:14:09 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98000O3Y7K6PE0@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 08:14:08 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OEE7BG009116; Fri, 24 Oct 2008 10:14:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9OEE7gN009113; Fri, 24 Oct 2008 10:14:07 -0400 (EDT) Date: Fri, 24 Oct 2008 10:14:07 -0400 From: James Carlson Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901D650.3080205@Sun.COM> To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Message-id: <18689.55343.405671.972998@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> Status: RO Content-Length: 2145 Stefan Teleman writes: > James Carlson wrote: > > I'm a bit confused about what's going on here. On a Nevada 101 > > system, I see no /usr/bin/gas on the system at all, though it does > > have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an > > OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from > > SUNWbinutils that points over to /usr/sfw. > > > > What the ... ? > > That was my implied point. There does not seem to be a consistent approach here, > with the existing SUNWbinutils. Yep. I have no idea how the OpenSolaris distribution became inconsistent in this way, but perhaps it doesn't matter for ARC purposes: OpenSolaris is still just an unintegrated project, which means that they needn't conform necessarily with any particular architecture. So I would assert that the real issue (at least for the ARC) is the intended architecture of SUNWbinutils, and not how it happens to appear on one or another (locally modified?) distribution. To conform with the /usr/gnu cases you're citing, that should mean that non-conflicting bits belong in /usr/bin, and only things with conflicts go in /usr/gnu/bin. In other words, /usr/bin/gar makes sense, as does /usr/gnu/bin/ar, but /usr/gnu/bin/gar doesn't make sense. > > That's all I'm asking. I can understand 'gar' and 'gas' because of > > the obvious conflicts. 'gobjcopy' is a little less obvious, at least > > to me ... but if that's expected, then ok. > > I am just as confused as you are. I was under the very distinct impression that > the existing SUNWbinutils will deliver symlinks in /usr/bin. But then, that did > not appear to be the case. I therefore concluded that the symlinks were removed > for a reason. It'd be good to get to the bottom of it, but my primary concern is the intended architecture of SUNWbinutils, as the package is constructed. If others modify and redistribute it, that's their problem. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Stefan.Teleman@sun.com Fri Oct 24 07:30:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OEU2uO012864 for ; Fri, 24 Oct 2008 07:30:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OEU0Sf006168; Fri, 24 Oct 2008 15:30:01 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800B1LYY05800@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 07:30:00 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K98008YQYY0RF40@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 07:30:00 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OETwnj734421; Fri, 24 Oct 2008 07:29:59 -0700 (PDT) Date: Fri, 24 Oct 2008 10:29:57 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901C124.2050601@Sun.COM> To: Darren J Moffat Cc: John Fischer , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <4901DBE5.9020608@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2296 Darren J Moffat wrote: > This is on the assumption that GNU binutils 4.3.x is NOT incompatible > with the gcc we currently ship. If GNU binutils *is* incompatible with > the gcc we currently ship then IMO this case needs to wait and be part > of a future case that upgrade gcc as well, otherwise I don't see the > point in shipping the newer binutils if we ship the older compiler > (unless the newer binutils are compatible with the compiler we ship). For the record: I am *purposely* introducing binutils _first_. When building GCC, its ./configure needs to be told (amongst other things): --with-as= --with-gnu-as=[yes|no] --with-ld= --with-gnu-ld=[yes|no] The values passed in to these two ./configure arguments will be written to a dynamically generated header file named auto-host.h: #define DEFAULT_ASSEMBLER "/usr/ccs/bin/as" #define DEFAULT_LINKER "/usr/ccs/bin/ld" /* etc etc etc */ This file is re-generated every time gcc is being rebuilt (which amounts to 3 times). If you require that binutils and gcc be introduced at the same time, you have implicitly and explicitly created an assembler location problem: the new GNU as is not yet installed on the system, it only exists in the proto area. Therefore the path to the new GNU assembler will look something like this: /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas This is the path of the gnu assembler the newly built GCC will look for, when installed. Needless to say, this path won't exist on a Solaris system. Therefore, GCC won't work, because the assembler it is looking for isn't there. This problem doesn't exist on SPARC (because on SPARC, GCC is configured to use /usr/ccs/bin/as, which is already there), but it does exist on x86. One could argue that this path should be replaced with the path to an existing assembler. My answer to that is no, the new GCC must build itself with the assembler it will use after it is installed, and not with some other random assembler. This is simply a sanity check. Therefore, binutils *must* be integrated, and must be installed on the target system before GCC can be built. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stefan.Teleman@sun.com Fri Oct 24 07:37:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OEbTam012967 for ; Fri, 24 Oct 2008 07:37:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OEbQxp010268; Fri, 24 Oct 2008 15:37:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9800J1PZAEAN00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 07:37:26 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K980050EZADG370@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 07:37:25 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OEbJ3I735322; Fri, 24 Oct 2008 07:37:23 -0700 (PDT) Date: Fri, 24 Oct 2008 10:37:18 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901D5D9.60900@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901DD9E.6030101@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <4901D5D9.60900@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1311 Darren J Moffat wrote: > Your justification supports using binutils 2.17 over 2.18 because of a > 2.18 but but it doesn't follow that you create this gcc4 subdir, because > your rationale has nothing to do with gcc4 but to do with a bug in > binutils 2.18. If the idea is to support multiple copies of binutils > then IMO the dir structure should be more like > /usr/gnu/binutils/2.17/bin/. However I still don't see the point in > that, since 2.18 isn't incompatible it is just plain broken on Solaris. Actually, no. The idea behind this directory structure (which appears to get drowned in static) is the following: /usr/gnu/gcc4/{bin,lib,include,man,share} will deliver the binutils for GCC4 -- whatever version these are. Right now, it's version 2.17. This could be upgraded in the future. /usr/gnu/gcc4/../{bin,lib,libexec,include,share,etc} can deliver several (more than one) versions of GCC4: 4.3.2, 4.4.3, etc, like so: /usr/gnu/gcc4/4.3.2/{bin,lib,libexec,include,share,etc} /usr/gnu/gcc4/4.4.3/{bin,lib,libexec,include,share,etc} etc etc etc This way we can deliver several different versions of GCC4, depending on needs, or requests, and have all of them use the same binutils. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Darren.Moffat@sun.com Fri Oct 24 07:58:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OEwOH9013348 for ; Fri, 24 Oct 2008 07:58:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OEwMaa010276 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 22:58:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900L1J099RN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 07:58:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005UQ097FP80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 07:58:20 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OEwIXT024557 for ; Fri, 24 Oct 2008 14:58:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K990030105TI200@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 15:58:18 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K99007NC0909SD0@fe-emea-09.sun.com>; Fri, 24 Oct 2008 15:58:15 +0100 (BST) Date: Fri, 24 Oct 2008 15:58:12 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901DBE5.9020608@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: John Fischer , PSARC-ext@sun.com Message-id: <4901E284.2010203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 791 Stefan Teleman wrote: > > > Darren J Moffat wrote: > >> This is on the assumption that GNU binutils 4.3.x is NOT incompatible >> with the gcc we currently ship. If GNU binutils *is* incompatible >> with the gcc we currently ship then IMO this case needs to wait and be >> part of a future case that upgrade gcc as well, otherwise I don't see >> the point in shipping the newer binutils if we ship the older compiler >> (unless the newer binutils are compatible with the compiler we ship). > > For the record: I am *purposely* introducing binutils _first_. Then this case is incomplete as I can't see the bigger picture with how this fits with GCC4, hence the questions about the gcc4 directory. Please either roll them into one case or provide an overview. -- Darren J Moffat From danek.duvall@sun.com Fri Oct 24 08:55:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OFtUoo014153 for ; Fri, 24 Oct 2008 08:55:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OFtTjs027599 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 23:55:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900E072WHWC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 08:55:29 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99008022WGRAB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 08:55:28 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OFtRPt063549; Fri, 24 Oct 2008 08:55:27 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9OFukN8021881; Fri, 24 Oct 2008 08:56:46 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9OFukIw021880; Fri, 24 Oct 2008 08:56:46 -0700 (PDT) Date: Fri, 24 Oct 2008 08:56:45 -0700 From: Danek Duvall Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18689.49341.355047.257091@gargle.gargle.HOWL> To: James Carlson Cc: Stefan Teleman , John Fischer , PSARC-ext@sun.com Message-id: <20081024155645.GZ7489@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 642 On Fri, Oct 24, 2008 at 08:34:05AM -0400, James Carlson wrote: > I'm a bit confused about what's going on here. On a Nevada 101 > system, I see no /usr/bin/gas on the system at all, though it does > have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an > OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from > SUNWbinutils that points over to /usr/sfw. > > What the ... ? This is due to modifications the OpenSolaris distribution team is making to a couple dozen packages as they're converted into pkg(5) format, in an attempt to make many of these utilities, header files, and libraries more available. Danek From Stefan.Teleman@sun.com Fri Oct 24 09:01:55 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OG1trq014326 for ; Fri, 24 Oct 2008 09:01:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OG1q3R003832; Fri, 24 Oct 2008 09:01:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900F0H3754100@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:01:53 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99008H5375R9B0@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:01:53 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OG1q5V749225; Fri, 24 Oct 2008 09:01:52 -0700 (PDT) Date: Fri, 24 Oct 2008 12:01:52 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18689.55343.405671.972998@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901F170.8050301@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2014 James Carlson wrote: > Stefan Teleman writes: >> James Carlson wrote: >>> I'm a bit confused about what's going on here. On a Nevada 101 >>> system, I see no /usr/bin/gas on the system at all, though it does >>> have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an >>> OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from >>> SUNWbinutils that points over to /usr/sfw. >>> >>> What the ... ? >> That was my implied point. There does not seem to be a consistent approach here, >> with the existing SUNWbinutils. > > Yep. > > I have no idea how the OpenSolaris distribution became inconsistent in > this way, but perhaps it doesn't matter for ARC purposes: OpenSolaris > is still just an unintegrated project, which means that they needn't > conform necessarily with any particular architecture. The other problem with having symlinks in /usr/bin is that we implicitly assert a preference for one version of binutils, or GCC, over another. Meaning: as long as there is only one version of binutils, or GCC, available, everything is fine: the symlinks in /usr/bin point to the sole instance. This no longer holds when there is more than one version of either component available: we are making an implicit value judgement ("the latest version is the one we like best"). This can create binary compatibility problems. > So I would assert that the real issue (at least for the ARC) is the > intended architecture of SUNWbinutils, and not how it happens to > appear on one or another (locally modified?) distribution. > > To conform with the /usr/gnu cases you're citing, that should mean > that non-conflicting bits belong in /usr/bin, and only things with > conflicts go in /usr/gnu/bin. > > In other words, /usr/bin/gar makes sense, as does /usr/gnu/bin/ar, but > /usr/gnu/bin/gar doesn't make sense. I can then change the bits in /usr/gnu/bin to remove the 'g', with the exception of gprof. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Darren.Moffat@sun.com Fri Oct 24 09:06:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OG601Z014638 for ; Fri, 24 Oct 2008 09:06:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OG5DNb017020 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 17:05:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900F0X3DX9L00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:05:57 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99008AL3DVR6D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:05:56 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OG5tmd001851 for ; Fri, 24 Oct 2008 16:05:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K99004013DNXJ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 17:05:55 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9900F0R3DUF630@fe-emea-10.sun.com>; Fri, 24 Oct 2008 17:05:55 +0100 (BST) Date: Fri, 24 Oct 2008 17:05:54 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F170.8050301@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: James Carlson , PSARC-ext@sun.com, John Fischer Message-id: <4901F262.209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1796 Stefan Teleman wrote: > > > James Carlson wrote: >> Stefan Teleman writes: >>> James Carlson wrote: >>>> I'm a bit confused about what's going on here. On a Nevada 101 >>>> system, I see no /usr/bin/gas on the system at all, though it does >>>> have SUNWbinutils installed, and I can see /usr/sfw/bin/gas. On an >>>> OpenSolaris 0.99 system, I see a /usr/bin/gas symlink coming from >>>> SUNWbinutils that points over to /usr/sfw. >>>> >>>> What the ... ? >>> That was my implied point. There does not seem to be a consistent >>> approach here, with the existing SUNWbinutils. >> >> Yep. >> >> I have no idea how the OpenSolaris distribution became inconsistent in >> this way, but perhaps it doesn't matter for ARC purposes: OpenSolaris >> is still just an unintegrated project, which means that they needn't >> conform necessarily with any particular architecture. > > The other problem with having symlinks in /usr/bin is that we implicitly > assert a preference for one version of binutils, or GCC, over another. > Meaning: as long as there is only one version of binutils, or GCC, > available, everything is fine: the symlinks in /usr/bin point to the > sole instance. This no longer holds when there is more than one version > of either component available: we are making an implicit value judgement > ("the latest version is the one we like best"). This can create binary > compatibility problems. I believe that value judgement is still made with a non version numbered symlink in /usr/gnu/bin/. The only way not to make the value judgement is to "hide" them all in versioned subdirs and that isn't a good thing for users. I think we *should* make a preference on which is the canonical version or we should only ever ship one version at a time. -- Darren J Moffat From Stefan.Teleman@Sun.COM Fri Oct 24 09:06:11 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OG6Bd5014681 for ; Fri, 24 Oct 2008 09:06:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OG69KA050774; Fri, 24 Oct 2008 10:06:09 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900A073E9MS00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:06:09 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005WA3E6SM40@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:06:06 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OG65r9750264; Fri, 24 Oct 2008 09:06:05 -0700 (PDT) Date: Fri, 24 Oct 2008 12:06:05 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901E284.2010203@Sun.COM> To: Darren J Moffat Cc: John Fischer , PSARC-ext@Sun.COM Reply-to: Stefan Teleman Message-id: <4901F26D.7000607@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901E284.2010203@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2828 Darren J Moffat wrote: > Stefan Teleman wrote: >> >> >> Darren J Moffat wrote: >> >>> This is on the assumption that GNU binutils 4.3.x is NOT incompatible >>> with the gcc we currently ship. If GNU binutils *is* incompatible >>> with the gcc we currently ship then IMO this case needs to wait and >>> be part of a future case that upgrade gcc as well, otherwise I don't >>> see the point in shipping the newer binutils if we ship the older >>> compiler (unless the newer binutils are compatible with the compiler >>> we ship). >> >> For the record: I am *purposely* introducing binutils _first_. > > Then this case is incomplete as I can't see the bigger picture with how > this fits with GCC4, hence the questions about the gcc4 directory. > Please either roll them into one case or provide an overview. This case is not incomplete. I have already explained why binutils is independent of GCC, why it must be introduced independently of GCC, and why binutils must already be installed on the system before configuring and installing GCC. Independently of this, binutils has a completely different release schedule and versioning scheme than GCC. Combining this (binutils) ARC Case with future GCC ARC Cases would be akin to combining GNU MP Bignum with MPFR in the same ARC Case, simply because MPFR depends on GNU MP bits, or combining Python and LCMS in the same ARC Case, for the same reasons. This is the binutils ARC Case. Any future GCC4 ARC Cases are purposely designed to be independent from it. We must be able to update binutils in the future, without having to touch existing GCC4 ARC Cases, and vice-versa. My expectation is that GCC will ARC more often than binutils. Compatibility constraints between any future version of binutils, and any existing installed GCC4 bits must be ascertained prior to filing such future binutils ARC Cases. If a future version of binutils is incompatible with any existing GCC4's, thereby breaking them, then that future version of binutils simply cannot be used. The GCC4 ARC Case [ GCC 4.3.2 ] will be filed shortly. The new GCC 4.3.2 ARC Case will reference the binutils 2.17 ARC Case (_this_ one). Future GCC4 ARC Cases will reference this same binutils ARC Case. Not the other way around. GCC depends on binutils, binutils couldn't care less which versions of GCC use its bits, or how many GCC versions are already installed, or where they are installed. The architectural Big Picture as to why a certain directory structure has been chosen will become obvious once the first GCC4 ARC Case is submitted. It is already known that different GCC versions cannot coexist within the same directory structure, and must be delivered under separate directory paths. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Darren.Moffat@sun.com Fri Oct 24 09:11:18 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGBHA4014910 for ; Fri, 24 Oct 2008 09:11:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGB2AJ052427 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 10:11:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K990060B3MRQI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:11:15 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005MU3MQG1D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:11:14 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OGBDbI021667 for ; Fri, 24 Oct 2008 16:11:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K99004013DNXJ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 17:11:13 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9900F5M3MOF630@fe-emea-10.sun.com>; Fri, 24 Oct 2008 17:11:13 +0100 (BST) Date: Fri, 24 Oct 2008 17:11:12 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F26D.7000607@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: John Fischer , PSARC-ext@sun.com Message-id: <4901F3A0.5030109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901E284.2010203@Sun.COM> <4901F26D.7000607@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 806 You response is self contradicting, because it first says they are independent cases for binutils and gcc4 then in the last paragraph you say "The architectural Big Picture as to why a certain directory structure has been chosen will become obvious once the first GCC4 ARC Case is submitted." I want to see that case submitted (and maybe even approved) before this case is approved. Note I'm talking about the architecture here, I understand the delivery dependency. I'm not at this stage even saying that there is an ARC case dependency just that I can't see the big picture until the gcc4 case is submitted and I'm not prepared to allow this case to complete until I've seen it. I would like this case to be put in 'waiting need spec' until the gcc4 case is submitted. -- Darren J Moffat From Garrett.Damore@sun.com Fri Oct 24 09:11:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGBQdE014929 for ; Fri, 24 Oct 2008 09:11:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OGBOAv019777 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 17:11:25 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900A0X3N0Z200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 24 Oct 2008 10:11:24 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005Z23MYST30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 24 Oct 2008 10:11:22 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OGBMbt025944 for ; Fri, 24 Oct 2008 09:11:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9900M012WDBH00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 24 Oct 2008 09:11:22 -0700 (PDT) Received: from [129.153.2.8] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K99001W03MWAP40@fe-sfbay-09.sun.com>; Fri, 24 Oct 2008 09:11:21 -0700 (PDT) Date: Fri, 24 Oct 2008 09:11:20 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901DBE5.9020608@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: Darren J Moffat , John Fischer , PSARC-ext@sun.com Message-id: <4901F3A8.90906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 2804 On 10/24/08 07:29, Stefan Teleman wrote: > > > Darren J Moffat wrote: > >> This is on the assumption that GNU binutils 4.3.x is NOT incompatible >> with the gcc we currently ship. If GNU binutils *is* incompatible >> with the gcc we currently ship then IMO this case needs to wait and >> be part of a future case that upgrade gcc as well, otherwise I don't >> see the point in shipping the newer binutils if we ship the older >> compiler (unless the newer binutils are compatible with the compiler >> we ship). > > For the record: I am *purposely* introducing binutils _first_. > > When building GCC, its ./configure needs to be told (amongst other > things): > > --with-as= > --with-gnu-as=[yes|no] > --with-ld= > --with-gnu-ld=[yes|no] > > The values passed in to these two ./configure arguments will be > written to a dynamically generated header file named auto-host.h: > > #define DEFAULT_ASSEMBLER "/usr/ccs/bin/as" > > #define DEFAULT_LINKER "/usr/ccs/bin/ld" > > /* etc etc etc */ > > This file is re-generated every time gcc is being rebuilt (which > amounts to 3 times). > > If you require that binutils and gcc be introduced at the same time, > you have implicitly and explicitly created an assembler location > problem: the new GNU as is not yet installed on the system, it only > exists in the proto area. Therefore the path to the new GNU assembler > will look something like this: > > /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas > > This is the path of the gnu assembler the newly built GCC will look > for, when installed. Needless to say, this path won't exist on a > Solaris system. Therefore, GCC won't work, because the assembler it is > looking for isn't there. > > This problem doesn't exist on SPARC (because on SPARC, GCC is > configured to use /usr/ccs/bin/as, which is already there), but it > does exist on x86. > > One could argue that this path should be replaced with the path to an > existing assembler. My answer to that is no, the new GCC must build > itself with the assembler it will use after it is installed, and not > with some other random assembler. This is simply a sanity check. > > Therefore, binutils *must* be integrated, and must be installed on the > target system before GCC can be built. Your confusing "build dependencies" with "delivery". How you build the bits doesn't matter, but IMO, if these bits are required for a certain GCC version, then you should probably *deliver* both the GCC version and the binutils at the same time. How you arrange to build the bits to make this happen is not architecturally relevant, as long as the final delivered bits don't have any unresolved dependencies. -- Garrett > > --Stefan > From Stefan.Teleman@sun.com Fri Oct 24 09:16:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGGVRU015108 for ; Fri, 24 Oct 2008 09:16:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OGGSL7022012; Fri, 24 Oct 2008 17:16:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900F0R3VGMZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:16:28 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K990084I3VGRFD0@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:16:28 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OGGR5K752117; Fri, 24 Oct 2008 09:16:27 -0700 (PDT) Date: Fri, 24 Oct 2008 12:16:27 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F3A8.90906@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901F4DB.3090801@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 262 Garrett D'Amore wrote: > Your confusing "build dependencies" with "delivery". No, i am not. Please read my explanation again. I believe it was pretty clear the first time around. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@sun.com Fri Oct 24 09:20:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGKRRi015130 for ; Fri, 24 Oct 2008 09:20:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OGKMV1023515; Fri, 24 Oct 2008 17:20:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900B3H41YM700@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:20:22 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005VB41XSO50@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:20:21 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9OGJrd3021985; Fri, 24 Oct 2008 11:19:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9OGJru3021984; Fri, 24 Oct 2008 11:19:53 -0500 (CDT) Date: Fri, 24 Oct 2008 11:19:53 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F170.8050301@Sun.COM> To: Stefan Teleman Cc: James Carlson , PSARC-ext@sun.com, John Fischer Message-id: <20081024161953.GP21103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1305 On Fri, Oct 24, 2008 at 12:01:52PM -0400, Stefan Teleman wrote: > The other problem with having symlinks in /usr/bin is that we implicitly > assert a preference for one version of binutils, or GCC, over another. > Meaning: as long as there is only one version of binutils, or GCC, > available, everything is fine: the symlinks in /usr/bin point to the sole > instance. This no longer holds when there is more than one version of > either component available: we are making an implicit value judgement ("the > latest version is the one we like best"). This can create binary > compatibility problems. Lots of things in /bin are "versioned" in some way. That's not a good reason to keep them out of /bin -- users still need them, and we're not going to tell them to muck with PATH to get them. We've been down this road and the ARC long ago decided to put all this stuff in /bin, versioned or not. You can always say that the link in /bin points to the latest version and so is Volatile or Uncommitted, or you can say it's Committed and commit to carrying that version as the default for a long time. > [...] > > I can then change the bits in /usr/gnu/bin to remove the 'g', with the > exception of gprof. Aren't gas(1) and gld(1) normally invoked by those names on Linux distros? Nico -- From Darren.Moffat@sun.com Fri Oct 24 09:22:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGM7QY015195 for ; Fri, 24 Oct 2008 09:22:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGM66F010326 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 09:22:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900B0J44UOW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 10:22:06 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005UI44SSG50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 10:22:05 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OGM4Je022530 for ; Fri, 24 Oct 2008 16:22:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9900H01432QP00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 17:22:04 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K990016B44NQO10@fe-emea-09.sun.com>; Fri, 24 Oct 2008 17:22:00 +0100 (BST) Date: Fri, 24 Oct 2008 17:21:59 +0100 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F4DB.3090801@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Fischer Message-id: <4901F627.8000508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 512 Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >> Your confusing "build dependencies" with "delivery". > > No, i am not. Please read my explanation again. I believe it was pretty > clear the first time around. It is *NOT* clear because I came to the same conclusion as Garrett. I've already asked for this case to be put in 'waiting need spec' so that I can see the GCC4 case and see the bigger picture. This is required only because this case is introducing a gcc4 subdir. -- Darren J Moffat From Garrett.Damore@sun.com Fri Oct 24 09:23:57 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGNuME015222 for ; Fri, 24 Oct 2008 09:23:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OGNtpx025041 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 17:23:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K990070147VZI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:23:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K990054Y47UG2E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:23:54 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OGNs4f027749 for ; Fri, 24 Oct 2008 09:23:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9900D013Z55I00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 09:23:54 -0700 (PDT) Received: from [129.153.2.8] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K99001K647KAP50@fe-sfbay-09.sun.com>; Fri, 24 Oct 2008 09:23:45 -0700 (PDT) Date: Fri, 24 Oct 2008 09:23:44 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F4DB.3090801@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Message-id: <4901F690.1040401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1052 On 10/24/08 09:16, Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >> Your confusing "build dependencies" with "delivery". > > No, i am not. Please read my explanation again. I believe it was > pretty clear the first time around. Not to me it wasn't. The statement you made was that you were delivering binutils *first*, because of the fact that in order to build gcc with --configure, you needed to supply paths to gas, etc. What I said is, that problem is a build dependency problem. You could deliver the final bits together (which IMO is the right thing to do if this case is primarily being done for benefit of gcc.) I'll also stand by Darren's comments... if you have this kind of dependency that is driving decisions in this case, then we need to see the entire case work for the big picture. That means that you probably need to submit a case for gcc4. IMO, it would probably be easiest to just *withdraw* this case, and submit a single combined case for gcc4 and any required binutils updates together. -- Garrett From Stefan.Teleman@sun.com Fri Oct 24 09:30:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGU6Tm015400 for ; Fri, 24 Oct 2008 09:30:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGU20j060190; Fri, 24 Oct 2008 10:30:05 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900C0X4I39G00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:30:03 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005KE4I2SO60@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:30:02 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OGU05f755057; Fri, 24 Oct 2008 09:30:01 -0700 (PDT) Date: Fri, 24 Oct 2008 12:30:00 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081024161953.GP21103@Sun.COM> To: Nicolas Williams Cc: James Carlson , PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901F808.5030601@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2626 Nicolas Williams wrote: > On Fri, Oct 24, 2008 at 12:01:52PM -0400, Stefan Teleman wrote: >> The other problem with having symlinks in /usr/bin is that we implicitly >> assert a preference for one version of binutils, or GCC, over another. >> Meaning: as long as there is only one version of binutils, or GCC, >> available, everything is fine: the symlinks in /usr/bin point to the sole >> instance. This no longer holds when there is more than one version of >> either component available: we are making an implicit value judgement ("the >> latest version is the one we like best"). This can create binary >> compatibility problems. > > Lots of things in /bin are "versioned" in some way. That's not a good > reason to keep them out of /bin -- users still need them, and we're not > going to tell them to muck with PATH to get them. > > We've been down this road and the ARC long ago decided to put all this > stuff in /bin, versioned or not. > > You can always say that the link in /bin points to the latest version > and so is Volatile or Uncommitted, or you can say it's Committed and > commit to carrying that version as the default for a long time. Unfortunately, this discussion is, again, C-centric. Yes, for C programs, it most likely does not matter that we will rev up the GCC symlinks in /usr/bin -- GCC's C ABI is stable. That is not the case for C++. GCC's C++ ABI is not stable, and it changes in an incompatible way, even between Minor Releases. Consider the following scenario: Time T0: -------- /usr/bin/g++ -> /usr/gnu/gcc4/4.3.2/bin/g++ /usr/bin/c++ -> /usr/gnu/gcc4/4.3.2/bin/c++ This is GCC version 4.3.2 with its associated GNU Standard C++ Library, and its own C++ ABI. Time T + N: ----------- /usr/bin/g++ -> /usr/gnu/gcc4/4.4.3/g++ /usr/bin/c++ -> /usr/gnu/gcc4/4.4.3/c++ This is GCC version 4.4.3 with its associated GNU Standard C++ Library, and its own C++ ABI.' The GCC C++ ABI has changed in an incompatible way between GCC 4.3.2 and GCC 4.4.3. Unknown to the developer, we have changed the symlinks in a patch, and they now point to GCC 4.4.3 instead of the previous GCC 4.3.2. This developer now wants to build a new C++ software component with our default g++, based on the symlinks in /usr/bin. This new C++ software component depends on some other C++ libraries, which have already been built with the previous version of GCC, and are already installed on his/her system. Result: different and incompatible C++ ABI's will be combined within the same executable address space. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@sun.com Fri Oct 24 09:31:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGVXD5015434 for ; Fri, 24 Oct 2008 09:31:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OGVN0k010303; Sat, 25 Oct 2008 00:31:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K990080T4KCTJ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 09:31:24 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K990055J4KBFOE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 09:31:23 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9OGUtdQ022003; Fri, 24 Oct 2008 11:30:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9OGUt5B022002; Fri, 24 Oct 2008 11:30:55 -0500 (CDT) Date: Fri, 24 Oct 2008 11:30:55 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F627.8000508@Sun.COM> To: Darren J Moffat Cc: Stefan Teleman , "Garrett D'Amore" , PSARC-ext@sun.com, John Fischer Message-id: <20081024163055.GS21103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <4901F627.8000508@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1040 On Fri, Oct 24, 2008 at 05:21:59PM +0100, Darren J Moffat wrote: > Stefan Teleman wrote: > > > > > >Garrett D'Amore wrote: > > > >>Your confusing "build dependencies" with "delivery". > > > >No, i am not. Please read my explanation again. I believe it was pretty > >clear the first time around. > > It is *NOT* clear because I came to the same conclusion as Garrett. > > I've already asked for this case to be put in 'waiting need spec' so > that I can see the GCC4 case and see the bigger picture. This is > required only because this case is introducing a gcc4 subdir. An alternative solution would be to just deliver: - binutils in /bin with 'g' prefixes for conflicting utils - binutils in /usr/gnu/bin without 'g' prefixes for utils that don't normally have the 'g' prefix - if there is a stability concern w.r.t. binutils then also deliver binutils in /usr/gnu/binutils/ That would divorce this case from the future GCC4 case, except in so far as this one would be a dependency of the other one. Nico -- From Stefan.Teleman@sun.com Fri Oct 24 09:33:49 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGXm0W015558 for ; Fri, 24 Oct 2008 09:33:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGXkSl061760; Fri, 24 Oct 2008 10:33:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K990090H4OA1A00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 09:33:46 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005ZF4OAG2E0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 09:33:46 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OGXj6W756259; Fri, 24 Oct 2008 09:33:45 -0700 (PDT) Date: Fri, 24 Oct 2008 12:33:45 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F690.1040401@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4901F8E9.2090902@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <4901F690.1040401@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1142 Garrett D'Amore wrote: > On 10/24/08 09:16, Stefan Teleman wrote: >> >> Garrett D'Amore wrote: >> >>> Your confusing "build dependencies" with "delivery". >> No, i am not. Please read my explanation again. I believe it was >> pretty clear the first time around. > > Not to me it wasn't. The statement you made was that you were > delivering binutils *first*, because of the fact that in order to build > gcc with --configure, you needed to supply paths to gas, etc. > > What I said is, that problem is a build dependency problem. You could > deliver the final bits together (which IMO is the right thing to do if > this case is primarily being done for benefit of gcc.) No, i cannot. 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 and this path will not exist on any Solaris distro that I can speak of. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@sun.com Fri Oct 24 09:41:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGfgd1015641 for ; Fri, 24 Oct 2008 09:41:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGffjf028281; Fri, 24 Oct 2008 09:41:41 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900G0B51GX400@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:41:40 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K990082U51FRGF0@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 09:41:39 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9OGfBFA022011; Fri, 24 Oct 2008 11:41:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9OGfBW7022010; Fri, 24 Oct 2008 11:41:11 -0500 (CDT) Date: Fri, 24 Oct 2008 11:41:11 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F808.5030601@Sun.COM> To: Stefan Teleman Cc: James Carlson , PSARC-ext@sun.com, John Fischer Message-id: <20081024164110.GT21103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2348 On Fri, Oct 24, 2008 at 12:30:00PM -0400, Stefan Teleman wrote: > >You can always say that the link in /bin points to the latest version > >and so is Volatile or Uncommitted, or you can say it's Committed and > >commit to carrying that version as the default for a long time. > > Unfortunately, this discussion is, again, C-centric. > > Yes, for C programs, it most likely does not matter that we will rev up the > GCC symlinks in /usr/bin -- GCC's C ABI is stable. > > That is not the case for C++. GCC's C++ ABI is not stable, and it changes > in an incompatible way, even between Minor Releases. I understand that. This is why we have an interface stability taxonomy. We decide what stability attribute we want to give to the G++ ABI, label all the relevant interfaces accordingly, deliver them, and move on. > [...] > > The GCC C++ ABI has changed in an incompatible way between GCC 4.3.2 and > GCC 4.4.3. Unknown to the developer, we have changed the symlinks in a > patch, and they now point to GCC 4.4.3 instead of the previous GCC 4.3.2. The developer will either know because we've told him in the docs, or this won't happen because the stability attribute that we decide to apply to G++ is such that we cannot change the default version in a minor release. Note that the G++ ABI stability issue is a bigger issue that needs to be addressed. Options: 1) Don't deliver G++; tell developers that the C++ ABI for Solaris is the Sun Studio C++ ABI. 2) Deliver G++ and declare it Volatile; tell developers that we may change the default G++ version delivered at any patch/update/ OpenSolaris release, and let them deal with the headaches. 3) Deliver G++ and declare it Committed; tell developers what to do in order to use the latest G++ instead of the default G++, and let them deal with the headaches. 4) Deliver G++ but not in /bin; tell developers how to find it and to pick the version they want, and let them deal with the headaches. 5) Deliver G++ and declare it Committed and commit to work with the GCC community to make its G++ ABI truly stable. 6) Something else?? (1), (5) and (6) are probably not realistic. So choose from (2), (3) or (4), propose it, and if the ARC approves it, your choice becomes our policy, else we'll eventually end up with one of the other two options. Nico -- From carlsonj@phorcys.east.sun.com Fri Oct 24 09:44:47 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OGilIG015684 for ; Fri, 24 Oct 2008 09:44:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OGijwD017938; Fri, 24 Oct 2008 09:44:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900D0X56ML700@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:44:46 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K990056Q56LSU70@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 10:44:45 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OGiiSA009828; Fri, 24 Oct 2008 12:44:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9OGiidD009825; Fri, 24 Oct 2008 12:44:44 -0400 (EDT) Date: Fri, 24 Oct 2008 12:44:44 -0400 From: James Carlson Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F170.8050301@Sun.COM> To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Message-id: <18689.64380.293235.547644@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> Status: RO Content-Length: 1975 Stefan Teleman writes: > The other problem with having symlinks in /usr/bin is that we implicitly assert > a preference for one version of binutils, or GCC, over another. That's not a problem, that's a benefit. Those who want a particular version (and no other) can either include/exclude specific packages to get to that state or grovel about in /usr/gnu/gcc-mumble/frotz to get the desired bits. Having a canonical version in /usr/bin is a *good* thing, as it makes our system much more like others, where you don't have to putz around with $PATH in order to get common packages to build. > the symlinks in /usr/bin point to the sole instance. This no longer holds when > there is more than one version of either component available: we are making an > implicit value judgement ("the latest version is the one we like best"). This > can create binary compatibility problems. I think the alternative is far worse. Those who don't care what version they get can look in /usr/bin, and we'll give them the benefit of the freshest bits there. Those who do -- for whatever reason -- care can specify exactly what they want. I don't see how it really could be otherwise. It'd be just silly to make /usr/bin be the oldest bits, and it'd be really confusing and weird to make /usr/bin appear to have different contents for different users. > > In other words, /usr/bin/gar makes sense, as does /usr/gnu/bin/ar, but > > /usr/gnu/bin/gar doesn't make sense. > > I can then change the bits in /usr/gnu/bin to remove the 'g', with the exception > of gprof. Bottom line: you're delivering something in /usr/gnu/bin and /usr/bin that has the same name, then that's a mistake. /usr/gnu/bin is supposed to shadow /usr/bin, not contain a replica. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From iant@google.com Fri Oct 24 10:45:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OHjZiV018295 for ; Fri, 24 Oct 2008 10:45:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OHjSwr028716; Fri, 24 Oct 2008 18:45:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900G057ZTK600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 10:45:29 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900B7T7ZT4KC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 10:45:29 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OHgjlu009876; Fri, 24 Oct 2008 17:45:28 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-84972; Fri, 24 Oct 2008 17:45:28 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-32445406; Fri, 24 Oct 2008 17:45:28 +0000 (Z) Received: from smtp-out.google.com ([216.239.45.13] [216.239.45.13]) by relay4i.sun.com with ESMTP id BT-MMP-995932; Fri, 24 Oct 2008 17:45:27 +0000 (Z) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id m9OHim1o010782; Fri, 24 Oct 2008 10:44:48 -0700 Received: from localhost.localdomain.google.com (dhcp-172-22-125-203.corp.google.com [172.22.125.203]) (authenticated bits=0) by wpaz1.hot.corp.google.com with ESMTP id m9OHijfK021066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2008 10:44:46 -0700 Date: Fri, 24 Oct 2008 10:44:45 -0700 From: Ian Lance Taylor Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F808.5030601@Sun.COM> To: Stefan Teleman Cc: Nicolas Williams , PSARC-ext@sun.com, John Fischer , James Carlson , opensolaris-arc@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1224870288; bh=c8tUvZJ0k3DozERJ/GjaFxrYqtY=; h=DomainKey-Signature:To:Cc:Subject:References:From:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type; b=XXf 61X0F45W1Q9rtDOUacw+8gbdyNXbUW9eN9kRMAgKwbgtuSvV++dzdhHLBA37vg7vMu+ fbSXhSy0jWeirmgw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=to:cc:subject:references:from:date:in-reply-to:message-id: user-agent:mime-version:content-type; b=tx652lkIi92/7lvFNkJQSGg1XeUI9nyiPW8/DCrQ09lSFlQcb8jxTFLOD8hr+h2Hf m3XD/yM7WcT0+k5D5/e7g== X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Status: RO Content-Length: 717 Stefan Teleman writes: > That is not the case for C++. GCC's C++ ABI is not stable, and it changes in an > incompatible way, even between Minor Releases. That has not been the case for a while now. The C++ ABI generated by GCC has been stable since the GCC 3.4 release four years ago. The libstdc++ ABI is also stable, although libstdc++ is not fully backward and forward compatible, in the sense that a program compiled with the libstdc++ distributed with GCC 4.3 may use symbols which are not defined by the lisbtdc++ distributed with GCC 3.4. [ This message was forwarded to me--I'm not on the opensolaris-arc mailing list. Please CC me explicitly on any relevant replies. ] Ian From Stefan.Teleman@sun.com Fri Oct 24 11:06:53 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OI6qSe019186 for ; Fri, 24 Oct 2008 11:06:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9OI6h0L013487; Sat, 25 Oct 2008 02:06:47 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900J058Z8GZ00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 12:06:44 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99005A08Z8SRD0@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 12:06:44 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OI6hPb772589; Fri, 24 Oct 2008 11:06:43 -0700 (PDT) Date: Fri, 24 Oct 2008 14:06:42 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: To: Ian Lance Taylor Cc: Nicolas Williams , PSARC-ext@sun.com, John Fischer , James Carlson , opensolaris-arc@opensolaris.org Reply-to: Stefan Teleman Message-id: <49020EB2.6050809@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1093 Ian Lance Taylor wrote: > Stefan Teleman writes: > >> That is not the case for C++. GCC's C++ ABI is not stable, and it changes in an >> incompatible way, even between Minor Releases. > > That has not been the case for a while now. The C++ ABI generated by > GCC has been stable since the GCC 3.4 release four years ago. False. The GCC C++ ABI has changed in an incompatible way several times within the the 3.x Minor versions, and has changed in an incompatible way yet again, for the GCC 4.x Major Release. A simple Google search for 'GCC C++ ABI' would yield relevant results: http://books.google.com/books?id=wQ6r3UTivJgC&pg=PA47&lpg=PA47&dq=GCC+C%2B%2B+ABI&source=web&ots=EJUnUr4CDt&sig=NibMWd8j1y9cs6_zSdGY_A0OXqA&hl=en&sa=X&oi=book_result&resnum=8&ct=result http://lists.alioth.debian.org/pipermail/glibc-bsd-devel/2005-July/000446.html These are just two examples. There doesn't even seem to be a consensus as to which GCC versions introduce ABI incompatible changes. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From iant@google.com Fri Oct 24 12:14:24 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OJENYw021157 for ; Fri, 24 Oct 2008 12:14:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OJELtj016075; Fri, 24 Oct 2008 12:14:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K990030HC3W1C00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 12:14:20 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900IF1C3V6A80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 12:14:20 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9OJEJVT025128; Fri, 24 Oct 2008 19:14:19 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-523232; Fri, 24 Oct 2008 19:14:19 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-67727600; Fri, 24 Oct 2008 19:14:19 +0000 (Z) Received: from smtp-out.google.com ([216.239.33.17] [216.239.33.17]) by relay1i.sun.com with ESMTP id BT-MMP-21262731; Fri, 24 Oct 2008 19:14:18 +0000 (Z) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id m9OJDXvl032314; Fri, 24 Oct 2008 20:13:34 +0100 Received: from localhost.localdomain.google.com (dhcp-172-22-125-203.corp.google.com [172.22.125.203]) (authenticated bits=0) by zps19.corp.google.com with ESMTP id m9OJDVDi026431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2008 12:13:32 -0700 Date: Fri, 24 Oct 2008 12:13:31 -0700 From: Ian Lance Taylor Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49020EB2.6050809@Sun.COM> To: Stefan Teleman Cc: Nicolas Williams , PSARC-ext@sun.com, John Fischer , James Carlson , opensolaris-arc@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1224875615; bh=wj6CZhVafJVD1vw6Kpe7beL8uno=; h=DomainKey-Signature:To:Cc:Subject:References:From:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type; b=XIz yP2kNxNTmHtxKOBxr+GxgJNowqDX7rfSRs3+zXHSiLFV8GcrjQDIrZHRSRAaef3MHD/ G/LdYpk6wkRIux0w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=to:cc:subject:references:from:date:in-reply-to:message-id: user-agent:mime-version:content-type; b=p5MQClkTZZjePNzmCtma6EwploHUCSmFroG4ouw7rWRD9hueCKnXr4tlmrvSbMyxt o3BFKhjKX8Bl6rc6+vx3w== X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> <49020EB2.6050809@Sun.COM> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Status: RO Content-Length: 1320 Stefan Teleman writes: > Ian Lance Taylor wrote: >> Stefan Teleman writes: >> >>> That is not the case for C++. GCC's C++ ABI is not stable, and it >>> changes in an incompatible way, even between Minor Releases. >> >> That has not been the case for a while now. The C++ ABI generated by >> GCC has been stable since the GCC 3.4 release four years ago. > > False. > > The GCC C++ ABI has changed in an incompatible way several times > within the the 3.x Minor versions, and has changed in an incompatible > way yet again, for the GCC 4.x Major Release. > > A simple Google search for 'GCC C++ ABI' would yield relevant results: > > http://books.google.com/books?id=wQ6r3UTivJgC&pg=PA47&lpg=PA47&dq=GCC+C%2B%2B+ABI&source=web&ots=EJUnUr4CDt&sig=NibMWd8j1y9cs6_zSdGY_A0OXqA&hl=en&sa=X&oi=book_result&resnum=8&ct=result > > http://lists.alioth.debian.org/pipermail/glibc-bsd-devel/2005-July/000446.html > > These are just two examples. There doesn't even seem to be a consensus > as to which GCC versions introduce ABI incompatible changes. I'm a GCC maintainer, I'm not some random guy off the street. The book is incorrect. The notes on the glibc-bsd-devel mailing list appears to be consistent with what I said: the C++ ABI has not changed since version 3.4. Ian From Stefan.Teleman@Sun.COM Fri Oct 24 13:01:57 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OK1vSB022215 for ; Fri, 24 Oct 2008 13:01:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OK1tvr029366; Fri, 24 Oct 2008 13:01:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900407EB5XE00@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 14:01:53 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K99001LYEB52720@brm-avmta-1.central.sun.com>; Fri, 24 Oct 2008 14:01:53 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OK1pf2792269; Fri, 24 Oct 2008 13:01:52 -0700 (PDT) Date: Fri, 24 Oct 2008 16:01:51 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: To: Ian Lance Taylor Cc: opensolaris-arc@opensolaris.org, PSARC-ext@Sun.COM, James Carlson , John Fischer , Nicolas Williams Reply-to: Stefan Teleman Message-id: <490229AF.7070903@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> <49020EB2.6050809@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1328 Ian Lance Taylor wrote: > > > I'm a GCC maintainer, I'm not some random guy off the street. > The book is incorrect. And, apparently so is everyone else. > The notes on the glibc-bsd-devel mailing list appears to be consistent > with what I said: the C++ ABI has not changed since version 3.4. One thing i am not going to do is make a far reaching architectural decision about GCC's future C++ ABI compatibility, based on mailing list statements, in absolute disregard for significant and documented C++ ABI compatibility breakage, within GCC Major Version 4, and in direct contradiction of your claimed compatibility statements. In this particular case, past performance is indicative of future results. Barring an official commitment statement from the GCC developers to the effect of "GCC will never break its C++ ABI on Solaris in an incompatible way, within the boundaries of a Major GCC Release Version", sent to this list, and made an integral part of the ARC Case Materials for GCC4, GCC4's C++ ABI on Solaris will maintain its "C++ ABI subject to change in an incompatible way, and without notice in a future release" status. Solaris' tolerance for ABI breakage is zero. We don't do "sorry we broke the ABI" statements. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From iant@google.com Fri Oct 24 13:13:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OKDJN1022975 for ; Fri, 24 Oct 2008 13:13:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9OKDANN023612; Fri, 24 Oct 2008 21:13:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900203EU1M300@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 13:13:13 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900HP4EU02C90@nwk-avmta-2.sfbay.sun.com>; Fri, 24 Oct 2008 13:13:12 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9OKDCle000347; Fri, 24 Oct 2008 20:13:12 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-89270; Fri, 24 Oct 2008 20:13:12 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-32640158; Fri, 24 Oct 2008 20:13:11 +0000 (Z) Received: from smtp-out.google.com ([216.239.45.13] [216.239.45.13]) by relay4i.sun.com with ESMTP id BT-MMP-13998679; Fri, 24 Oct 2008 20:13:11 +0000 (Z) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id m9OKCYmm029776; Fri, 24 Oct 2008 13:12:34 -0700 Received: from localhost.localdomain.google.com (dhcp-172-22-125-203.corp.google.com [172.22.125.203]) (authenticated bits=0) by wpaz17.hot.corp.google.com with ESMTP id m9OKCVTO011386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2008 13:12:31 -0700 Date: Fri, 24 Oct 2008 13:12:30 -0700 From: Ian Lance Taylor Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <490229AF.7070903@Sun.COM> To: Stefan Teleman Cc: opensolaris-arc@opensolaris.org, PSARC-ext@sun.com, James Carlson , John Fischer , Nicolas Williams Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1224879154; bh=/a88oDXVIut/gZy3FYJbKZGja4U=; h=DomainKey-Signature:To:Cc:Subject:References:From:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type; b=yAr M0Y+cr4kHr79AFyj5Jsr2hVrvpvYuF5xOTE38fa2YpSSSLx4yEc/6mehIZrsiqhkuq/ dKFTnHyutDCulgPQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=to:cc:subject:references:from:date:in-reply-to:message-id: user-agent:mime-version:content-type; b=sdXlCBusHi+cRBAgHihCYF1QrMqoJnqZGLJIoJun/E2T5HV3WLNHiuCC1ur441NiK uOxp0FVeT6Ntcq0lpPU8w== X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> <49020EB2.6050809@Sun.COM> <490229AF.7070903@Sun.COM> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Status: RO Content-Length: 1862 Stefan Teleman writes: > Ian Lance Taylor wrote: > >> The book is incorrect. > > And, apparently so is everyone else. I'm not sure who "everyone else" is, so I can't reasonably respond. > One thing i am not going to do is make a far reaching architectural > decision about GCC's future C++ ABI compatibility, based on mailing > list statements, in absolute disregard for significant and documented > C++ ABI compatibility breakage, within GCC Major Version 4, and in > direct contradiction of your claimed compatibility statements. > > In this particular case, past performance is indicative of future results. > > Barring an official commitment statement from the GCC developers to > the effect of "GCC will never break its C++ ABI on Solaris in an > incompatible way, within the boundaries of a Major GCC Release > Version", sent to this list, and made an integral part of the ARC Case > Materials for GCC4, GCC4's C++ ABI on Solaris will maintain its "C++ > ABI subject to change in an incompatible way, and without notice in a > future release" status. > > Solaris' tolerance for ABI breakage is zero. We don't do "sorry we > broke the ABI" statements. You obviously must make your own decisions. I simply wanted to correct your statement about C++ ABI incompatibilities in GCC. We understand that ABI breakages are a very bad idea, and we no longer do them. It's certainly true that we did do them before the 3.4 release, for what we thought were good reasons. In the 3.4 release we rewrote the C++ parser, and committed to a single ABI (documented at http://codesourcery.com/cxx-abi/ -- we use it for all targets, not just for Itanium). If you choose to act as though GCC will break the C++ ABI with every minor release, then you will certainly be safe. I don't know what, if anything, that decision will cost you. Ian From Stefan.Teleman@sun.com Fri Oct 24 13:27:46 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OKRkaa023390 for ; Fri, 24 Oct 2008 13:27:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OKRjb3002658; Fri, 24 Oct 2008 14:27:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900B0HFI6AI00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 13:27:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900IB7FI466F0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 13:27:40 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9OKRc79795799; Fri, 24 Oct 2008 13:27:39 -0700 (PDT) Date: Fri, 24 Oct 2008 16:27:38 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: To: Ian Lance Taylor Cc: opensolaris-arc@opensolaris.org, PSARC-ext@sun.com, James Carlson , John Fischer , Nicolas Williams Reply-to: Stefan Teleman Message-id: <49022FBA.1040702@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> <49020EB2.6050809@Sun.COM> <490229AF.7070903@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 563 Ian Lance Taylor wrote: > If you choose to act as though GCC will break the C++ ABI with every > minor release, then you will certainly be safe. I don't know what, if > anything, that decision will cost you. At a minimum, we warned developers and customers that: - the new version might be incompatible with the older version - don't assume the two versions are ABI compatible -- they may or may not be - experiment and ascertain they are 100% compatible before you decide to mix --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From nicolas.williams@sun.com Fri Oct 24 13:46:12 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OKkCs2024881 for ; Fri, 24 Oct 2008 13:46:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OKk4Im019639; Fri, 24 Oct 2008 13:46:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900D4CGCYR800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 13:46:10 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900B8JGCWLB80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Oct 2008 13:46:08 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9OKUfun022155; Fri, 24 Oct 2008 15:30:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9OKUfwI022154; Fri, 24 Oct 2008 15:30:41 -0500 (CDT) Date: Fri, 24 Oct 2008 15:30:41 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <490229AF.7070903@Sun.COM> To: Stefan Teleman Cc: Ian Lance Taylor , opensolaris-arc@opensolaris.org, PSARC-ext@sun.com, James Carlson , John Fischer Message-id: <20081024203040.GB21103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <18689.49341.355047.257091@gargle.gargle.HOWL> <4901D650.3080205@Sun.COM> <18689.55343.405671.972998@gargle.gargle.HOWL> <4901F170.8050301@Sun.COM> <20081024161953.GP21103@Sun.COM> <4901F808.5030601@Sun.COM> <49020EB2.6050809@Sun.COM> <490229AF.7070903@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1488 On Fri, Oct 24, 2008 at 04:01:51PM -0400, Stefan Teleman wrote: > One thing i am not going to do is make a far reaching architectural > decision about GCC's future C++ ABI compatibility, based on mailing list > statements, in absolute disregard for significant and documented C++ ABI > compatibility breakage, within GCC Major Version 4, and in direct > contradiction of your claimed compatibility statements. Hmmm, no, you can say that a particular version's ABI will be Committed in Solaris, meaning that "g++" (as opposed the full versioned path to the g++ executable, such as /usr/gnu/gcc//bin/g++), will not be changed to a new version that's backwards incompatible, not on any update/patch releases. And you can say that "g++" is Volatile, that only the full versioned paths to g++ are Committed. That's the choice. Leaving potentially-unstable interfaces out of /bin is an option (and what you're proposing), but not a very good one (at least one ARC member didn't like it). > Solaris' tolerance for ABI breakage is zero. We don't do "sorry we broke > the ABI" statements. The SDF has a process by which incompatible changes can be made and by which expectations are documented about when such changes may be made. See the ARC's best practices (interface stability taxonomy, release taxonomy, EOF/EOL processes). Solaris has certainly had backwards- incompatible changes during its history, all in accordance with such processes (including appeals). Nico -- From John.Plocher@sun.com Fri Oct 24 14:50:40 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9OLodbp026775 for ; Fri, 24 Oct 2008 14:50:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9OLob9q006456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Oct 2008 14:50:39 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9900KC7JCEBE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 14:50:38 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9900FXKJBANS20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 14:49:58 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9OLnwav011819 for ; Fri, 24 Oct 2008 14:49:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9900801J4BAW00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 14:49:57 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9900163JB9DEG0@fe-sfbay-09.sun.com>; Fri, 24 Oct 2008 14:49:57 -0700 (PDT) Date: Fri, 24 Oct 2008 14:49:56 -0700 From: John Plocher Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49012E45.7080407@Sun.COM> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: Danek Duvall , PSARC-ext@sun.com, John Fischer Message-id: <49024304.3050500@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <18688.61280.741889.940523@gargle.gargle.HOWL> <4900F63A.3070109@Sun.COM> <20081023225004.GR7489@mumak.SFBay.Sun.COM> <490126B1.5000407@Sun.COM> <20081024015519.GL23882@mumak.SFBay.Sun.COM> <49012E45.7080407@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 2530 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 From Garrett.Damore@sun.com Fri Oct 24 22:08:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9P58aQE005823 for ; Fri, 24 Oct 2008 22:08:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9P58NCM021920 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Oct 2008 13:08:35 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9A004053MAVH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 22:08:34 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9A009IP3M8WUB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 22:08:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9P58WXY028747 for ; Fri, 24 Oct 2008 22:08:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9A006013EWBR00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Oct 2008 22:08:32 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9A00MK43M7TR20@fe-sfbay-10.sun.com>; Fri, 24 Oct 2008 22:08:31 -0700 (PDT) Date: Fri, 24 Oct 2008 22:04:24 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F8E9.2090902@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Reply-to: Garrett.Damore@sun.com Message-id: <4902A8D8.6060600@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <4901F690.1040401@sun.com> <4901F8E9.2090902@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1556 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> On 10/24/08 09:16, Stefan Teleman wrote: >>> >>> Garrett D'Amore wrote: >>> >>>> Your confusing "build dependencies" with "delivery". >>> No, i am not. Please read my explanation again. I believe it was >>> pretty clear the first time around. >> >> Not to me it wasn't. The statement you made was that you were >> delivering binutils *first*, because of the fact that in order to >> build gcc with --configure, you needed to supply paths to gas, etc. >> >> What I said is, that problem is a build dependency problem. You >> could deliver the final bits together (which IMO is the right thing >> to do if this case is primarily being done for benefit of gcc.) > > No, i cannot. > > 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 > > and this path will not exist on any Solaris distro that I can speak of. That hard coding of the path is a *build time* artifact. If you can't figure out how to fix that, then you should probably abandon the effort and let someone else take this task on who can. (Hint: you're build system can temporarily contain binaries and objects that are not part of any official distribution yet. I.e. you could install binutils manually in /usr/bin during the time that you do the build.) -- Garrett From Stefan.Teleman@sun.com Sat Oct 25 00:27:23 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9P7RNGc007774 for ; Sat, 25 Oct 2008 00:27:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9P7RNXQ012231; Sat, 25 Oct 2008 00:27:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9A00G03A1NEB00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Oct 2008 00:27:23 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9A00BQTA1KIS90@nwk-avmta-1.sfbay.Sun.COM>; Sat, 25 Oct 2008 00:27:20 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9P7RKuX906739; Sat, 25 Oct 2008 00:27:20 -0700 (PDT) Date: Sat, 25 Oct 2008 03:27:19 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4902A8D8.6060600@sun.com> To: Garrett.Damore@sun.com Cc: PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4902CA57.7030104@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <4901F690.1040401@sun.com> <4901F8E9.2090902@Sun.COM> <4902A8D8.6060600@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 731 Garrett D'Amore wrote: >> /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas >> >> and this path will not exist on any Solaris distro that I can speak of. > > That hard coding of the path is a *build time* artifact. If you can't > figure out how to fix that, then you should probably abandon the effort > and let someone else take this task on who can. > > (Hint: you're build system can temporarily contain binaries and objects > that are not part of any official distribution yet. I.e. you could > install binutils manually in /usr/bin during the time that you do the > build.) I am not going to dignify this with an answer. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Garrett.Damore@sun.com Sat Oct 25 08:11:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9PFBDTU016577 for ; Sat, 25 Oct 2008 08:11:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9PFB7Qc022970 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 25 Oct 2008 23:11:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9A00B01VIM8M00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 25 Oct 2008 08:11:10 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9A00CW7VIMWPA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 25 Oct 2008 08:11:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9PFBAWa021673 for ; Sat, 25 Oct 2008 08:11:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9A00K01VDHIA00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 25 Oct 2008 08:11:10 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9A004WCVILAP50@fe-sfbay-09.sun.com>; Sat, 25 Oct 2008 08:11:09 -0700 (PDT) Date: Sat, 25 Oct 2008 08:07:01 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4902CA57.7030104@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext@sun.com, John Fischer Reply-to: Garrett.Damore@sun.com Message-id: <49033615.6000908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <4901F690.1040401@sun.com> <4901F8E9.2090902@Sun.COM> <4902A8D8.6060600@sun.com> <4902CA57.7030104@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1391 Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >>> /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas >>> >>> and this path will not exist on any Solaris distro that I can speak of. >> >> That hard coding of the path is a *build time* artifact. If you >> can't figure out how to fix that, then you should probably abandon >> the effort and let someone else take this task on who can. >> >> (Hint: you're build system can temporarily contain binaries and >> objects that are not part of any official distribution yet. I.e. you >> could install binutils manually in /usr/bin during the time that you >> do the build.) > > I am not going to dignify this with an answer. I am sorry if I insulted you. My above statements could have been worded better, I think. However, the underpinning technical point, which is that you can resolve the *build time* dependency fairly trivially remains valid, and the problem of the dependency should not drive the architecture of the project. If you choose not to address my point, that's your choice, but I believe other members (particularly Darren) have stated that you need to provide a clear picture of what we are doing. I don't believe that a problem building the software should drive the architecture of what we deliver to customers, and I strongly suspect that I am not alone in that regard. -- Garrett From Darren.Moffat@sun.com Mon Oct 27 03:37:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RAb7Ns001172 for ; Mon, 27 Oct 2008 03:37:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9RAb2GQ023013 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Oct 2008 18:37:04 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00C0J85R7H00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 04:37:03 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E00GR385P8DB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 04:37:02 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RAb1Bd028877 for ; Mon, 27 Oct 2008 10:37:01 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00H014GJO900@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 10:37:01 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E00AUD83R28C0@fe-emea-09.sun.com>; Mon, 27 Oct 2008 10:35:51 +0000 (GMT) Date: Mon, 27 Oct 2008 10:35:51 +0000 From: Darren J Moffat Subject: DERAILED Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901F4DB.3090801@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Fischer Message-id: <49059987.8070400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1815 I'm derailing this case on the grounds that it is not obvious and also the volume of email traffic involved in trying go get clarifications. The non obvious parts to me are the following: djm-0 Why we need a gcc4 subdir in /usr/gnu/ djm-1 What the connection between this case and gcc4 really is I can't actually find any information on a dependency between GCC 4.3.x on any version of GNU binutils. djm-2 Without seeing the GCC4 case I don't even understand why this issue exists at all since the current GCC 3.4.3 on Solaris uses /usr/sfw/bin/gas and /usr/bin/ld. djm-3 Wither or not binutils (modulo any bugs in a particular version) are so unstable that we need to support multiple versions and if this is only because of a desire to support multiple versions of gcc. djm-4 If the dependency between binutils and GCC4 is build time only or architectural and if there are possibilities for a workaround particularly given the following: http://www.gnu.org/software/gcc/faq.html#gas I also happen to know that it is possible to reconfigure which assembler program gcc uses by giving full paths in the specs file. I haven't checked that with GCC 4.x but it certainly still works with the 3.4.3 that we ship with Solaris. I want to see the documentation that shows exactly what versions of GCC and GNU binutils work together (I looked and couldn't find it). Project team please work with your case sponsor to arrange a full case review, please ensure that the materials presented cover all of the above issues from me and any other issues outstanding from other members and people who have commented. Please remember that a derail of a fast-track just means we wish to review it using the full case review mechanism. I does NOT mean the case is denied. -- Darren J Moffat From John.Plocher@sun.com Mon Oct 27 08:55:06 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RFt5dm008670 for ; Mon, 27 Oct 2008 08:55:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RFt3Nq012187 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Oct 2008 15:55:04 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00J0XMVQX100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 08:55:02 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E00IIIMVPG220@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 08:55:01 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RFt1Ln018388 for ; Mon, 27 Oct 2008 08:55:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00F01M90QU00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 08:55:01 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E00LDRMVF19B0@fe-sfbay-10.sun.com>; Mon, 27 Oct 2008 08:54:51 -0700 (PDT) Date: Mon, 27 Oct 2008 08:54:50 -0700 From: John Plocher Subject: Re: DERAILED Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49059987.8070400@Sun.COM> Sender: John.Plocher@sun.com To: Darren J Moffat Cc: Stefan Teleman , PSARC-ext@sun.com, John Fischer , "Garrett D'Amore" Message-id: <4905E44A.7070204@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <49059987.8070400@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 3756 From my 1:1 offline discussion with Stefan: Darren J Moffat wrote: > I'm derailing this case on the grounds that it is not obvious and also > the volume of email traffic involved in trying go get clarifications. > > The non obvious parts to me are the following: > > djm-0 Why we need a gcc4 subdir in /usr/gnu/ Because the submitter feels that there may be subtle and/or unintended differences between binutils 2.15 (found in snv_99) and binutils 2.17 (used by gcc4 and proposed here) that are impossible to determine without performing a complete set of regression tests. (2004/742 marks binutils 2.15/gcc3 as "External") This is an issue in the submitters view because the shipping gcc3 uses binutils 2.15, and is used to build S10; replacing binutils 2.15 out from under it and replacing it with 2.17 would require some large but unspecified regression testing of the gcc3-built S10 binaries. (left unstated is why the combo of OpenSolaris, gcc3 and binutils 2.whatever has any bearing at all on building the S10 sources...) > > djm-1 What the connection between this case and gcc4 really is > I can't actually find any information on a dependency between > GCC 4.3.x on any version of GNU binutils. gcc is built with a hardcoded full-path dependency on $AS and $LD. These hardcoded executables are used both at source build time and at delivered-binary runtime. In order to support a system that has both "gcc3/binutils2.15" and "gcc4/binutils2.17", there needs to be a way to have both versions of binutils resident at the same time. Thus the (imo poorly named) /usr/gnu/gcc4/... directory which will contain binutils2.17. > > djm-2 Without seeing the GCC4 case I don't even understand why > this issue exists at all since the current GCC 3.4.3 on Solaris > uses /usr/sfw/bin/gas and /usr/bin/ld. /usr/sfw/bin/gas is from binutils 2.15. Upgrading it in place to binutils 2.17 means that the existing gcc3 would (gasp!) use a different assembler (...), which might or might not cause problems. > > djm-3 Wither or not binutils (modulo any bugs in a particular > version) are so unstable that we need to support multiple > versions and if this is only because of a desire to support > multiple versions of gcc. I think you got it - this is to support multiple versions of gcc. IMO, the stability (or not) of binutils has not been characterized by the project team except to state that *any* change would require a complete and time consuming regression test. > > djm-4 If the dependency between binutils and GCC4 is build time > only or architectural and if there are possibilities for a > workaround particularly given the following: > > http://www.gnu.org/software/gcc/faq.html#gas > > I also happen to know that it is possible to reconfigure > which assembler program gcc uses by giving full paths in the > specs file. I haven't checked that with GCC 4.x but it > certainly still works with the 3.4.3 that we ship with Solaris. There probably is some benefit in decoupling the "build gcc" dependencies from the "run the resulting compiler" ones, but only if there are substantive differences between binutils.old and binutils.new. Given the "External" stability classification articulated in 2004/742, I don't believe we need to support multiple versions of the binutils 2.xx release cycle on the system. > > I want to see the documentation that shows exactly what versions of GCC > and GNU binutils work together (I looked and couldn't find it). I /believe/ they ALL are intended to work well together; the only concern is regression testing to find subtle and/or unexpected bugs to make the transition from gcc3/binutils2.15 to gcc3/binutils2.17 easier. -John (not the project team!) From Garrett.Damore@Sun.COM Mon Oct 27 09:15:21 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RGFLaW009874 for ; Mon, 27 Oct 2008 09:15:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9RGFJIu002183 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Oct 2008 09:15:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E00K0XNTKKT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 09:15:20 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E00I9CNTHGJ30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 09:15:17 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RGFHHl003790 for ; Mon, 27 Oct 2008 09:15:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00301N5OII00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 09:15:17 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E00EXQNTDJB30@fe-sfbay-10.sun.com>; Mon, 27 Oct 2008 09:15:13 -0700 (PDT) Date: Mon, 27 Oct 2008 09:10:57 -0700 From: "Garrett D'Amore" Subject: Re: DERAILED Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4905E44A.7070204@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Darren J Moffat , Stefan Teleman , PSARC-ext@Sun.COM, John Fischer Reply-to: Garrett.Damore@Sun.COM Message-id: <4905E811.3020506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901C124.2050601@Sun.COM> <4901DBE5.9020608@Sun.COM> <4901F3A8.90906@sun.com> <4901F4DB.3090801@Sun.COM> <49059987.8070400@Sun.COM> <4905E44A.7070204@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2265 John Plocher wrote: > From my 1:1 offline discussion with Stefan: > > Darren J Moffat wrote: >> I'm derailing this case on the grounds that it is not obvious and >> also the volume of email traffic involved in trying go get >> clarifications. >> >> The non obvious parts to me are the following: >> >> djm-0 Why we need a gcc4 subdir in /usr/gnu/ > > Because the submitter feels that there may be subtle > and/or unintended differences between binutils 2.15 > (found in snv_99) and binutils 2.17 (used by gcc4 and > proposed here) that are impossible to determine without > performing a complete set of regression tests. > > (2004/742 marks binutils 2.15/gcc3 as "External") > > This is an issue in the submitters view because the > shipping gcc3 uses binutils 2.15, and is used to build > S10; replacing binutils 2.15 out from under it and > replacing it with 2.17 would require some large but > unspecified regression testing of the gcc3-built S10 > binaries. Is this project seeking Patch binding on Solaris 10? (If so, why?) If not, then this issue is moot, since I believe only Solaris 10 systems are used to build Solaris 10 itself. (I.e. the build machines do not run Nevada.) > > (left unstated is why the combo of OpenSolaris, gcc3 and > binutils 2.whatever has any bearing at all on building the > S10 sources...) No longer unstated, although unanswered, per my question above. > >> >> I want to see the documentation that shows exactly what versions of >> GCC and GNU binutils work together (I looked and couldn't find it). > > I /believe/ they ALL are intended to work well together; the only > concern is regression testing to find subtle and/or unexpected bugs > to make the transition from gcc3/binutils2.15 to gcc3/binutils2.17 > easier. IMO, project teams should not invent new, and IMO compromising, architectures simply to avoid test burdens. This sounds like the cart driving the horse, to me at least. I strongly suspect that if we can eliminate the S10 issue, then we can also eliminate the need for a separate binutils delivery for gcc4. We've already heard from a gcc maintainer stating that the interfaces involved are considered a Stable (or Committed) interface by the upstream Gnu maintainers. -- Garrett From ro@techfak.uni-bielefeld.de Tue Oct 28 10:35:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SHZHBV000490 for ; Tue, 28 Oct 2008 10:35:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SHZDLZ008262; Wed, 29 Oct 2008 01:35:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00L0VM6QA600@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 10:35:14 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00JK2M6PN530@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 10:35:13 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SHZCtG015836; Tue, 28 Oct 2008 17:35:13 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-48462; Tue, 28 Oct 2008 17:35:12 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-206303; Tue, 28 Oct 2008 17:35:12 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-846556; Tue, 28 Oct 2008 17:35:12 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 885714827E; Tue, 28 Oct 2008 18:35:11 +0100 (CET) Date: Tue, 28 Oct 2008 18:35:09 +0100 (MET) From: Rainer Orth Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4901D429.1060603@Sun.COM> To: Stefan Teleman Cc: John Fischer , PSARC-ext@sun.com Message-id: <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.133sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> Status: RO Content-Length: 5078 Stefan Teleman writes: > >> This FastTrack proposes the Integration of a more recent version > >> of GNU binutils, which is compatible with Versions 4.3.x of the > >> GNU Compiler Collection [ GCC ]. [2] > > > > This is not true: all recent versions up to and including GCC mainline (to > > become 4.4) happily build and run with binutils 2.15 (gas 2.15, to be exact). > > I regularly test that (at least on x86, on SPARC I generally prefer Sun as). > > Please see my comment above. they only describe why you don't use binutils 2.18. > In addition, there were Solaris specific patches for binutils 2.15 which have > been accepted into 2.17. Therefore, no more patch maintenance for 2.17. Maybe, but there's no patch patch maintenance for the 2.15 patches (probably for the amd64 support, I suppose) either because they are done and don't require ongoing maintenance any more. Besides, the only part of binutils that GCC depends on is gas proper, and if it were really necessary do depend on a specific version of gas, you could easily deliver that particular version of gas inside /usr/lib/gcc/ or whereever. In my experience, newer versions of gas are simply drop-in replacements for older version (modulo bugs, of course), maybe offering additional features, but never incompatibilities. Therefore it seems silly to make all of binutils gcc-version dependent because the deliver new features: this would be similar to say delivering different versions of elfdump with the Studio compilers because elfdump developed new features ;-( I still question if it is necessary to use a newer gas with GCC 4 at all: I recently built GCC 4.4 with gas 2.15 and gas 2.19.50 (i.e. binutils mainline), and the resulting changes to gcc/auto-host.h were minimal: --- 10-gcc/gcc/auto-host.h Fri Oct 10 15:54:20 2008 +++ 10-gcc-gas21950/gcc/auto-host.h Thu Oct 9 20:03:42 2008 @@ -15,7 +15,7 @@ /* Define to enable the use of a default assembler. */ #ifndef USED_FOR_TARGET -#define DEFAULT_ASSEMBLER "/usr/sfw/bin/gas" +#define DEFAULT_ASSEMBLER "/vol/gcc/lib/gas-2.19.50" #endif @@ -197,7 +197,7 @@ /* Define if your assembler supports the --debug-prefix-map option. */ #ifndef USED_FOR_TARGET -/* #undef HAVE_AS_DEBUG_PREFIX_MAP */ +#define HAVE_AS_DEBUG_PREFIX_MAP 1 #endif @@ -295,7 +295,7 @@ /* Define if the assembler won't complain about a line such as # 0 "" 2. */ #ifndef USED_FOR_TARGET -/* #undef HAVE_AS_LINE_ZERO */ +#define HAVE_AS_LINE_ZERO 1 #endif @@ -830,13 +830,13 @@ /* Define 0/1 if your assembler supports CFI directives. */ #ifndef USED_FOR_TARGET -#define HAVE_GAS_CFI_DIRECTIVE 0 +#define HAVE_GAS_CFI_DIRECTIVE 1 #endif /* Define 0/1 if your assembler supports .cfi_personality. */ #ifndef USED_FOR_TARGET -#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 0 +#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1 #endif @@ -903,7 +903,7 @@ /* Define if your assembler supports .weakref. */ #ifndef USED_FOR_TARGET -/* #undef HAVE_GAS_WEAKREF */ +#define HAVE_GAS_WEAKREF 1 #endif As far as I can see, the only substantial change is the CFI stuff, and that was only introduced in GCC 4.4, so won't affect 4.3 at all. > >> /usr/gnu/gcc4/lib/libbfd-2.17.so > >> /usr/gnu/gcc4/lib/libbfd.so -> libbfd-2.17.so > >> /usr/gnu/gcc4/lib/libopcodes-2.17.so > >> /usr/gnu/gcc4/lib/libopcodes.so -> libopcodes-2.17.so > > [...] > >> 3. Interfaces > >> > >> 3.1. Interface Stability > >> > >> GNU binutils only provides executables. Although two shared libraries > >> will be included in this Integration [ libbfd.so and libopcodes.so ], > >> the interfaces exposed by these shared objects are classified as > >> Project Private, and should no be relied upon, or used, by any other > >> userland software application. > > > > In that case, there should be *no* compilation symlinks like libbfd.so > > anywhere, just the specific versions used. > > Why ? Because they are only used by the linker, not at runtime (provided the SONAMES aren't constructed incorrectly). > > Btw., the list above doesn't list those specific versions (like libbfd.so.) at all. > > /usr/gnu/gcc4/lib/libbfd-2.17.so > /usr/gnu/gcc4/lib/libopcodes-2.17.so > > These are the names of the objects generated by binutils. I have no intention to > change the default generated object names by introducing unnecessary patches to > binutils' build system, just for the sake of changing the default generated > object names. > > > Beyond that, a > > default build of binutils doesn't build a shared libbfd, but links it > > statically exactly because the interface isn't stable and rapidly changes > > between releases. > > Binutils builds what it is being told to build. In this particular case, I am > telling it to build shared libraries. Which is non-default for a very good reason: those libraries are extremely unstable and change incompatibly from release to release. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Stefan.Teleman@sun.com Tue Oct 28 12:10:24 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SJANY8004161 for ; Tue, 28 Oct 2008 12:10:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SJ9uaI014939; Wed, 29 Oct 2008 03:10:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00M09QL7B800@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 13:10:19 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00M9KQL72500@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 13:10:19 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9SJAHat459473; Tue, 28 Oct 2008 12:10:17 -0700 (PDT) Date: Tue, 28 Oct 2008 15:10:17 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> To: Rainer Orth Cc: John Fischer , PSARC-ext@sun.com, Stefan Teleman Reply-to: Stefan Teleman Message-id: <49076399.4070507@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 6172 Rainer Orth wrote: >> Please see my comment above. > > they only describe why you don't use binutils 2.18. Well, yes. :-) 2.18 is broken on Solaris x86. 2.17 works just fine, passes all the torture tests for binutils and GCC. But, i see that binutils 2.19 was released yesterday, 10/27/2008. So, this new version is a good candidate for inclusion, instead of 2.17 -- modulo passing all the torture tests. Running all the torture tests for GCC with all the languages enabled takes a *very long time*. >> In addition, there were Solaris specific patches for binutils 2.15 which have >> been accepted into 2.17. Therefore, no more patch maintenance for 2.17. > > Maybe, but there's no patch patch maintenance for the 2.15 patches > (probably for the amd64 support, I suppose) either because they are done > and don't require ongoing maintenance any more. Exactly -- and i'd like to integrate a recent version of binutils which is not several years out-of-date, and closed for development. We'd like to involve the binutils and GCC core developers in GCC Solaris: it is much easier for *them* if we provide a recent version. And i still can't think of a reason why we should purposely stay with an old binutils version: while it is true that binutils 2.15 would work with GCC4, there's no reason why we should purposely avoid the most recent version known to work, and continue drifting out-of-date. We already have a GCC (3.4.3) which uses binutils 2.15. > Besides, the only part of binutils that GCC depends on is gas proper, and > if it were really necessary do depend on a specific version of gas, you > could easily deliver that particular version of gas inside /usr/lib/gcc/ version> or whereever. In my experience, newer versions of gas are simply > drop-in replacements for older version (modulo bugs, of course), maybe > offering additional features, but never incompatibilities. Therefore it > seems silly to make all of binutils gcc-version dependent because the > deliver new features: this would be similar to say delivering different > versions of elfdump with the Studio compilers because elfdump developed new > features ;-( Yes, there is the gcc "libexec location" -- which is installs binutils under the libexec target/host subdirectories. But that isn't the plan here. The plan here is to have one version of binutils shared by several different versions of GCC4, for several reasons: 1. If we use the "gcc libexec location", then we have to duplicate the binutils executables for every GCC4 instance (or create symlinks into the libexec location from a shared location, which is just as ugly, if not uglier). We would like to be able to deliver several different versions of GCC4 (and GCC5, and so on) installed on the system, and have all of them share the same binutils. This is what happens in the real world right now: one can install GCC 4.2.4, GCC 4.3.1, GCC 4.3.2 and GCC 4.4.0RC (the latest GCC4's), , and have all of them share the same binutils 2.19 (the latest binutils). 2. GCC 4.4.0 is already in RC. This means a 4.4.x GCC for Solaris is on the radar screen. Same proposition for GCC 4.5.x, etc, until it revs up its Major Version. 3. binutils generally revs up much less frequently than GCC (modulo bugs happening in a particular release). Therefore, the upgrade trains for binutils will be very different than those for GCC. If the upgrade trains are already known to be different, why should we tie them together artificially ? > I still question if it is necessary to use a newer gas with GCC 4 at all: I > recently built GCC 4.4 with gas 2.15 and gas 2.19.50 (i.e. binutils > mainline), and the resulting changes to gcc/auto-host.h were minimal: Because of the "we would like not to fall behind by several years" argument above. :-) > Because they are only used by the linker, not at runtime (provided the > SONAMES aren't constructed incorrectly). > >>> Btw., the list above doesn't list those specific versions (like libbfd.so.) at all. >> /usr/gnu/gcc4/lib/libbfd-2.17.so >> /usr/gnu/gcc4/lib/libopcodes-2.17.so >> >> These are the names of the objects generated by binutils. I have no intention to >> change the default generated object names by introducing unnecessary patches to >> binutils' build system, just for the sake of changing the default generated >> object names. >> >>> Beyond that, a >>> default build of binutils doesn't build a shared libbfd, but links it >>> statically exactly because the interface isn't stable and rapidly changes >>> between releases. >> Binutils builds what it is being told to build. In this particular case, I am >> telling it to build shared libraries. > > Which is non-default for a very good reason: those libraries are extremely > unstable and change incompatibly from release to release. I don't want to stand in the way of a perceived sense of security (removing the symlinks doesn't really prevent anyone from using these libraries, if they are determined to do so, and they do so against the Interface Stability Classification warning), so i will remove the symlinks. Lastly, and for the record (unrelated to your post, but related to other discussions): This ARC Case [ and any subsequent, related ARC Cases ] does not [ do not ] address the existing GCC 3.4.3 and/or binutils 2.15. There have been no change requests for either the upgrade, update, or removal of either GCC 3.4.3, or binutils 2.15. Any change requests pertaining to either GCC 3.4.3 or binutils 2.15 must follow the standard operating procedure for submitting change requests. Future, unspecified ARC Cases may address binutils 2.15 and/or GCC 3.4.3, pursuant to the existence of relevant change requests. Because of the consequences and complexity of updating/upgrading/removing either GCC 3.4.3, or binutils 2.15, comprehensive scrutiny and review of any such change requests, addressing either GCC 3.4.3 or binutils 2.15, will apply. Consensus buy-in from all the Consolidations currently using GCC 3.4.3 and binutils 2.15 will be required. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@sun.com Tue Oct 28 14:39:21 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SLdKKt011640 for ; Tue, 28 Oct 2008 14:39:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SLdFo7004927 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 05:39:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00401XHGGY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 14:39:16 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G006OPXHE30A0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 14:39:16 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SLdEER017377 for ; Tue, 28 Oct 2008 14:39:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9G00H01XCUL700@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 14:39:14 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9G00JKDXHE6G70@fe-sfbay-10.sun.com>; Tue, 28 Oct 2008 14:39:14 -0700 (PDT) Date: Tue, 28 Oct 2008 14:39:14 -0700 From: John Plocher Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49076399.4070507@Sun.COM> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <49078682.4010008@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 2174 Stefan Teleman wrote: > Exactly -- and i'd like to integrate a recent version of binutils I completely agree. > We already have > a GCC (3.4.3) which uses binutils 2.15. Which would not be harmed at all if you removed binutils 2.15 and replaced it with something newer. The gas/binutils maintainers seem to feel that 2.19 is an upwardly compatible drop in replacement for 2.15, the ARC approved stability for binutils 2.15 is "External", which allows this type of upgrade/replacement without too much effort, etc etc etc. The only issue is that binutils 2.15 is in /usr/sfw, which is the wrong place for binutils 2.19. But, /usr/gnu/gcc4/... is also the wrong place. The *right* place is in /bin and/or /usr/gnu/, just like the rest of the GNU stuff. > This ARC Case [ and any subsequent, related ARC Cases ] does not [ do not ] > address the existing GCC 3.4.3 and/or binutils 2.15. There have been no change > requests for either the upgrade, update, or removal of either GCC 3.4.3, or > binutils 2.15. > > Any change requests pertaining to either GCC 3.4.3 or binutils 2.15 must follow > the standard operating procedure for submitting change requests. Future, > unspecified ARC Cases may address binutils 2.15 and/or GCC 3.4.3, pursuant to > the existence of relevant change requests. > > Because of the consequences and complexity of updating/upgrading/removing either > GCC 3.4.3, or binutils 2.15, comprehensive scrutiny and review of any such > change requests, addressing either GCC 3.4.3 or binutils 2.15, will apply. > Consensus buy-in from all the Consolidations currently using GCC 3.4.3 and > binutils 2.15 will be required. What consequences and complexity? You are proposing the inclusion of binutils 2.1[79], so the scope of the ARC case is properly "is this the right way to do this?". As I said above, this proposal isn't the right way. It would introduce a wart into the system - a complete copy of binutils tied to a compiler version and inaccessible to the users of the system (or alternatively, accessible, but in a very strange location). Both of these violate 1991/061's packaging and delivery advice. -John From Stefan.Teleman@sun.com Tue Oct 28 14:50:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SLoBji012046 for ; Tue, 28 Oct 2008 14:50:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SLo315008075; Wed, 29 Oct 2008 05:50:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00527XZKQQ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 28 Oct 2008 14:50:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G006EDXZI2VB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 28 Oct 2008 14:50:06 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9SLo4GY486224; Tue, 28 Oct 2008 14:50:05 -0700 (PDT) Date: Tue, 28 Oct 2008 17:50:04 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49078682.4010008@Sun.Com> To: John Plocher Cc: Rainer Orth , PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <4907890C.7050508@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1624 John Plocher wrote: >> This ARC Case [ and any subsequent, related ARC Cases ] does not [ do >> not ] >> address the existing GCC 3.4.3 and/or binutils 2.15. There have been >> no change requests for either the upgrade, update, or removal of >> either GCC 3.4.3, or binutils 2.15. >> >> Any change requests pertaining to either GCC 3.4.3 or binutils 2.15 >> must follow the standard operating procedure for submitting change >> requests. Future, unspecified ARC Cases may address binutils 2.15 >> and/or GCC 3.4.3, pursuant to the existence of relevant change requests. >> >> Because of the consequences and complexity of >> updating/upgrading/removing either GCC 3.4.3, or binutils 2.15, >> comprehensive scrutiny and review of any such change requests, >> addressing either GCC 3.4.3 or binutils 2.15, will apply. Consensus >> buy-in from all the Consolidations currently using GCC 3.4.3 and >> binutils 2.15 will be required. > > What consequences and complexity? Having all the Consolidations which currently use GCC 3.4.3 discover that the GCC compiler they use no longer exists, and it has been replaced by a newer compiler, and this was done without providing them a proper transition time. AFAIK, O/N does not compile with either GCC 4.3.1 or 4.3.2. I'll happily stand corrected if that is not the case. Is it unreasonable to provide a reasonable compiler transition time, and determine that "stuff compiles" with the new compiler, before removing the existing compiler, which is at least known to "compile stuff" ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@sun.com Tue Oct 28 14:56:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SLuNWj012529 for ; Tue, 28 Oct 2008 14:56:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SLuJaO024450; Tue, 28 Oct 2008 21:56:20 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00801Y9VSH00@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 14:56:19 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G003F3Y9UPU90@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 14:56:19 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9SLtiuq102933; Tue, 28 Oct 2008 16:55:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id m9SLtiAU102932; Tue, 28 Oct 2008 16:55:44 -0500 (CDT) Date: Tue, 28 Oct 2008 16:55:43 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907890C.7050508@Sun.COM> To: Stefan Teleman Cc: John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <20081028215543.GB102869@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1215 On Tue, Oct 28, 2008 at 05:50:04PM -0400, Stefan Teleman wrote: > >What consequences and complexity? > > Having all the Consolidations which currently use GCC 3.4.3 discover that > the GCC compiler they use no longer exists, and it has been replaced by a > newer compiler, and this was done without providing them a proper > transition time. But you're replacing GCC [yet]. You're replacing binutils, and as far as we all understand there's no reason why GCC 3.4.3 shouldn't work just fine with the new binutils. Have you tested GCC 3.4.3 w/ the latest binutils? You certainly could (build binutils, install it, then build all consolidations that can build with GCC 3.4.3, then run some tests (not necessarily every testsuite we have -- that would take a long time and a lot of effort for you). > Is it unreasonable to provide a reasonable compiler transition time, and > determine that "stuff compiles" with the new compiler, before removing the > existing compiler, which is at least known to "compile stuff" ? I don't think it is unreasonable, but if GCC 3.4.3 works fine with the latest binutils I don't see how your question is relevant to the question of where we should ship the latest binutils. From Scott.Rotondo@sun.com Tue Oct 28 14:58:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SLwJgH012885 for ; Tue, 28 Oct 2008 14:58:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SLwF3n010438 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 05:58:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00803YD3VG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Oct 2008 14:58:15 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G003JEYD1PSA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 28 Oct 2008 14:58:13 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9SLwDQh017717 for ; Tue, 28 Oct 2008 21:58:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9G00501Y7CYY00@mail-amer.sun.com> (original mail from Scott.Rotondo@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 28 Oct 2008 15:58:13 -0600 (MDT) Received: from [129.146.108.62] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9G000SRYCWRXF0@mail-amer.sun.com>; Tue, 28 Oct 2008 15:58:08 -0600 (MDT) Date: Tue, 28 Oct 2008 14:58:08 -0700 From: Scott Rotondo Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907890C.7050508@Sun.COM> Sender: Scott.Rotondo@sun.com To: Stefan Teleman Cc: John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <49078AF0.3060800@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 454 Stefan Teleman wrote: > > AFAIK, O/N does not compile with either GCC 4.3.1 or 4.3.2. I'll happily > stand corrected if that is not the case. > You are correct. I happen to have the set of source code changes needed to make ON compile with gcc 4.x, but I haven't integrated them into ON yet. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From bart.smaalders@sun.com Tue Oct 28 15:04:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SM4Z4A013265 for ; Tue, 28 Oct 2008 15:04:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SM4MNn027309; Tue, 28 Oct 2008 22:04:32 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G0090JYNI4M00@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 15:04:30 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G003R5YNHPO90@nwk-avmta-2.sfbay.sun.com>; Tue, 28 Oct 2008 15:04:29 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m9SM4TtM025676; Tue, 28 Oct 2008 22:04:29 +0000 (GMT) Date: Tue, 28 Oct 2008 15:04:28 -0700 From: Bart Smaalders Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907890C.7050508@Sun.COM> To: Stefan Teleman Cc: John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <49078C6C.9070902@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080908) Status: RO Content-Length: 2017 Stefan Teleman wrote: > > > John Plocher wrote: > >>> This ARC Case [ and any subsequent, related ARC Cases ] does not [ do >>> not ] >>> address the existing GCC 3.4.3 and/or binutils 2.15. There have been >>> no change requests for either the upgrade, update, or removal of >>> either GCC 3.4.3, or binutils 2.15. >>> >>> Any change requests pertaining to either GCC 3.4.3 or binutils 2.15 >>> must follow the standard operating procedure for submitting change >>> requests. Future, unspecified ARC Cases may address binutils 2.15 >>> and/or GCC 3.4.3, pursuant to the existence of relevant change requests. >>> >>> Because of the consequences and complexity of >>> updating/upgrading/removing either GCC 3.4.3, or binutils 2.15, >>> comprehensive scrutiny and review of any such change requests, >>> addressing either GCC 3.4.3 or binutils 2.15, will apply. Consensus >>> buy-in from all the Consolidations currently using GCC 3.4.3 and >>> binutils 2.15 will be required. >> >> What consequences and complexity? > > Having all the Consolidations which currently use GCC 3.4.3 discover > that the GCC compiler they use no longer exists, and it has been > replaced by a newer compiler, and this was done without providing them a > proper transition time. > > AFAIK, O/N does not compile with either GCC 4.3.1 or 4.3.2. I'll happily > stand corrected if that is not the case. > > Is it unreasonable to provide a reasonable compiler transition time, and > determine that "stuff compiles" with the new compiler, before removing > the existing compiler, which is at least known to "compile stuff" ? > > --Stefan > Note that Stefan's argument is this: changing binutils for the existing gcc is a compiler change, and would seem to warrant rather extensive testing of the affected consolidations. Is this a good idea? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Stefan.Teleman@sun.com Tue Oct 28 15:04:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SM4mZC013284 for ; Tue, 28 Oct 2008 15:04:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SM4dul027386; Tue, 28 Oct 2008 22:04:44 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00C0FYNU5B00@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:04:42 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00M97YNT2290@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:04:42 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9SM4eg1488990; Tue, 28 Oct 2008 15:04:41 -0700 (PDT) Date: Tue, 28 Oct 2008 18:04:40 -0400 From: Stefan Teleman Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081028215543.GB102869@Sun.COM> To: Nicolas Williams Cc: John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Reply-to: Stefan Teleman Message-id: <49078C78.2060602@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1206 Nicolas Williams wrote: > On Tue, Oct 28, 2008 at 05:50:04PM -0400, Stefan Teleman wrote: >>> What consequences and complexity? >> Having all the Consolidations which currently use GCC 3.4.3 discover that >> the GCC compiler they use no longer exists, and it has been replaced by a >> newer compiler, and this was done without providing them a proper >> transition time. > > But you're replacing GCC [yet]. You're replacing binutils, and as far > as we all understand there's no reason why GCC 3.4.3 shouldn't work just > fine with the new binutils. Have you tested GCC 3.4.3 w/ the latest > binutils? You certainly could (build binutils, install it, then build > all consolidations that can build with GCC 3.4.3, then run some tests > (not necessarily every testsuite we have -- that would take a long > time and a lot of effort for you). It's not a question of me not wanting to do the work, it is simply a matter of "no-one has ever asked for the current GCC 3.4.3 to update its binutils". Therefore, the answer is no, i have not tested GCC 3.4.3 with the newer binutils, because this was never part of the plan. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@sun.com Tue Oct 28 15:07:56 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SM7u22013331 for ; Tue, 28 Oct 2008 15:07:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9SM7oA6002628; Tue, 28 Oct 2008 15:07:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G00C07YT7DH00@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:07:55 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G00MF3YT52290@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:07:54 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9SM7Ogi102949; Tue, 28 Oct 2008 17:07:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id m9SM7Okp102948; Tue, 28 Oct 2008 17:07:24 -0500 (CDT) Date: Tue, 28 Oct 2008 17:07:24 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49078C78.2060602@Sun.COM> To: Stefan Teleman Cc: John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <20081028220723.GD102869@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> <49078C78.2060602@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1250 On Tue, Oct 28, 2008 at 06:04:40PM -0400, Stefan Teleman wrote: > >But you're replacing GCC [yet]. You're replacing binutils, and as far > >as we all understand there's no reason why GCC 3.4.3 shouldn't work just > >fine with the new binutils. Have you tested GCC 3.4.3 w/ the latest > >binutils? You certainly could (build binutils, install it, then build > >all consolidations that can build with GCC 3.4.3, then run some tests > >(not necessarily every testsuite we have -- that would take a long > >time and a lot of effort for you). > > It's not a question of me not wanting to do the work, it is simply a matter I did not think I implied that. I still haven't. However, you seem to be arguing "better not risk it" while it'd be nice to know if it is a problem or not. > of "no-one has ever asked for the current GCC 3.4.3 to update its binutils". So what? > Therefore, the answer is no, i have not tested GCC 3.4.3 with the newer > binutils, because this was never part of the plan. Maybe it should be, because the architecture that makes sense is to deliver binutils in /usr/gnu/bin without 'g' prefixes and in /usr/bin with 'g' prefixes. So far as I can tell every ARC member that's weighed in on this thinks as much. Nico -- From Nicolas.Williams@sun.com Tue Oct 28 15:10:11 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SMAAkf013353 for ; Tue, 28 Oct 2008 15:10:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SMA5ri029276; Tue, 28 Oct 2008 22:10:07 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9G0071JYWTWV00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 28 Oct 2008 15:10:05 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9G006Z1YWR2PC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 28 Oct 2008 15:10:03 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9SM9XbX102956; Tue, 28 Oct 2008 17:09:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id m9SM9Xa2102955; Tue, 28 Oct 2008 17:09:33 -0500 (CDT) Date: Tue, 28 Oct 2008 17:09:33 -0500 From: Nicolas Williams Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49078C6C.9070902@Sun.COM> To: Bart Smaalders Cc: Stefan Teleman , John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <20081028220933.GE102869@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <49078C6C.9070902@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 550 On Tue, Oct 28, 2008 at 03:04:28PM -0700, Bart Smaalders wrote: > Note that Stefan's argument is this: changing binutils for the existing > gcc is a compiler change, and would seem to warrant rather extensive > testing of the affected consolidations. Is this a good idea? We do change compilers from time to time. Maybe this should be tested. Also, perhaps we could move the existing binutils out of the way but keep them around and modify the old/current GCC to use the old binutils, then ship the new binutils where users expect it. Nico -- From gdamore@sun.com Tue Oct 28 15:37:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SMbPk4013880 for ; Tue, 28 Oct 2008 15:37:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SMbGFF023209 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 06:37:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00A0X06BJ800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:37:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H0036W06BPUD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:37:23 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SMbNTL023847 for ; Tue, 28 Oct 2008 15:37:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9G00F01XO8NK00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:37:23 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9H001KA05ZMT60@fe-sfbay-09.sun.com>; Tue, 28 Oct 2008 15:37:12 -0700 (PDT) Date: Tue, 28 Oct 2008 15:32:44 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <20081028220723.GD102869@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Stefan Teleman , John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <4907930C.2060309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> <49078C78.2060602@Sun.COM> <20081028220723.GD102869@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2300 Nicolas Williams wrote: > On Tue, Oct 28, 2008 at 06:04:40PM -0400, Stefan Teleman wrote: > >>> But you're replacing GCC [yet]. You're replacing binutils, and as far >>> as we all understand there's no reason why GCC 3.4.3 shouldn't work just >>> fine with the new binutils. Have you tested GCC 3.4.3 w/ the latest >>> binutils? You certainly could (build binutils, install it, then build >>> all consolidations that can build with GCC 3.4.3, then run some tests >>> (not necessarily every testsuite we have -- that would take a long >>> time and a lot of effort for you). >>> >> It's not a question of me not wanting to do the work, it is simply a matter >> > > I did not think I implied that. I still haven't. However, you seem to > be arguing "better not risk it" while it'd be nice to know if it is a > problem or not. > > >> of "no-one has ever asked for the current GCC 3.4.3 to update its binutils". >> > > So what? > > >> Therefore, the answer is no, i have not tested GCC 3.4.3 with the newer >> binutils, because this was never part of the plan. >> > > Maybe it should be, because the architecture that makes sense is to > deliver binutils in /usr/gnu/bin without 'g' prefixes and in /usr/bin > with 'g' prefixes. So far as I can tell every ARC member that's weighed > in on this thinks as much. > Yes, at least from this ARC member. When the Sun assembler or ld needs to be updated, we don't spin off a new directory and retest the universe. (Although we *do* test things!) There are reasonable assumptions that can be made, and the architecture doesn't need to adapt to these kinds of changes. Nor should the architecture need to adapt to a compatible change in binutils (GNU as namely). If its a drop-in replacement, just test to make sure it really works (and testing here probably means making sure you can build the entire SFW distribution, and then trying to run some sample applications from it... I'm not sure what the most likely to fail apps would be from that, but I'm sure there are folks here who have some good ideas...) What distributions actually "require" gcc to build? I can guess that SFW might because of free software projects that rely on GNUisms, but hopefully none of the others do... -- Garrett From johnlev@barman.uk.sun.com Tue Oct 28 15:44:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SMimHI014232 for ; Tue, 28 Oct 2008 15:44:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9SMihdu011912; Tue, 28 Oct 2008 22:44:46 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00F0H0IJ3F00@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:44:43 -0600 (MDT) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H00ML10II25A0@brm-avmta-1.central.sun.com>; Tue, 28 Oct 2008 16:44:42 -0600 (MDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9SMiZ77011293; Tue, 28 Oct 2008 22:44:35 +0000 (GMT) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1KuxLw-00057A-4x; Tue, 28 Oct 2008 22:47:56 +0000 X-URL: http://jurassic.eng/~johnlev/ Date: Tue, 28 Oct 2008 22:47:56 +0000 From: John Levon Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907930C.2060309@sun.com> Sender: John Levon To: "Garrett D'Amore" Cc: Nicolas Williams , Stefan Teleman , John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <20081028224756.GC27211@barman.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> <49078C78.2060602@Sun.COM> <20081028220723.GD102869@Sun.COM> <4907930C.2060309@sun.com> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 294 On Tue, Oct 28, 2008 at 03:32:44PM -0700, Garrett D'Amore wrote: > What distributions actually "require" gcc to build? I can guess that ON requires GCC to build, since the xVM gate does. It's also full of code using obscure GCC features, as much of the code is Linux derived. regards john From Alan.Coopersmith@sun.com Tue Oct 28 15:54:08 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SMs8FJ014686 for ; Tue, 28 Oct 2008 15:54:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9SMs7xi015887 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 28 Oct 2008 15:54:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00F070Y7RF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 16:54:07 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H00M980Y41ZB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 16:54:06 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SMs4XU025544 for ; Tue, 28 Oct 2008 15:54:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9H003010OOGO00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:54:04 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9H00I0U0Y2IP50@fe-sfbay-10.sun.com>; Tue, 28 Oct 2008 15:54:03 -0700 (PDT) Date: Tue, 28 Oct 2008 15:54:02 -0700 From: Alan Coopersmith Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907930C.2060309@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , Stefan Teleman , John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <4907980A.3000309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> <49078C78.2060602@Sun.COM> <20081028220723.GD102869@Sun.COM> <4907930C.2060309@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 366 Garrett D'Amore wrote: > What distributions actually "require" gcc to build? I can guess that > SFW might because of free software projects that rely on GNUisms, but > hopefully none of the others do... You mean consolidations? ON, X, JDS, SFW... -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Tue Oct 28 16:00:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SN00Ap014968 for ; Tue, 28 Oct 2008 16:00:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SMxkEf000204 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 06:59:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00B0D17YK500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:59:58 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H00B5417XIN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:59:57 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SMxvSF029416 for ; Tue, 28 Oct 2008 15:59:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9H00C0111MGW00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:59:57 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9H00ITY17WIP60@fe-sfbay-10.sun.com>; Tue, 28 Oct 2008 15:59:57 -0700 (PDT) Date: Tue, 28 Oct 2008 15:55:32 -0700 From: "Garrett D'Amore" Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <4907980A.3000309@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Nicolas Williams , Stefan Teleman , John Plocher , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <49079864.6000206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <49078682.4010008@Sun.Com> <4907890C.7050508@Sun.COM> <20081028215543.GB102869@Sun.COM> <49078C78.2060602@Sun.COM> <20081028220723.GD102869@Sun.COM> <4907930C.2060309@sun.com> <4907980A.3000309@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 355 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> What distributions actually "require" gcc to build? I can guess that >> SFW might because of free software projects that rely on GNUisms, but >> hopefully none of the others do... >> > > You mean consolidations? ON, X, JDS, SFW... > Yes, that's what I meant to type. :-) - Garrett From Darren.Moffat@sun.com Wed Oct 29 02:50:15 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9T9oFCs029286 for ; Wed, 29 Oct 2008 02:50:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9T9oCcF001519 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 02:50:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00M03VBP6M00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Oct 2008 03:50:13 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H00CEUVBKJFF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Oct 2008 03:50:13 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9T9o80Z024288 for ; Wed, 29 Oct 2008 09:50:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9H00001U84HJ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Oct 2008 09:50:08 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9H00579VB8LFB0@fe-emea-09.sun.com>; Wed, 29 Oct 2008 09:49:56 +0000 (GMT) Date: Wed, 29 Oct 2008 09:49:56 +0000 From: Darren J Moffat Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <49076399.4070507@Sun.COM> Sender: Darren.Moffat@sun.com To: Stefan Teleman Cc: Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <490831C4.1050204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 183 Point of order please. I derailed this case a few days ago. That means we should be waiting to see full case materials and an agenda not continuing discussion. -- Darren J Moffat From John.Fischer@sun.com Wed Oct 29 07:44:49 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9TEinMN006985 for ; Wed, 29 Oct 2008 07:44:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m9TEimIL012552 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 07:44:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9I003058YOL000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 29 Oct 2008 07:44:48 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9I00EWM8YN1N80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 29 Oct 2008 07:44:48 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9TEilF9001369 for ; Wed, 29 Oct 2008 14:44:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9I00I016Z7W600@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 29 Oct 2008 08:44:47 -0600 (MDT) Received: from [127.0.0.1] ([76.20.56.47]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9I00JLV8Y26A30@mail-amer.sun.com>; Wed, 29 Oct 2008 08:44:32 -0600 (MDT) Date: Wed, 29 Oct 2008 07:44:26 -0700 From: John Fischer Subject: Re: GNU binutils version 4.3.x [PSARC/2008/656 FastTrack timeout 10/30/2008] In-reply-to: <490831C4.1050204@Sun.COM> Sender: John.Fischer@sun.com To: Darren J Moffat Cc: Stefan Teleman , Rainer Orth , PSARC-ext@sun.com, John Fischer Message-id: <490876CA.1040202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200810232108.m9NL8nFs019266@sac.sfbay.sun.com> <4901D429.1060603@Sun.COM> <18695.19789.572340.382147@manam.TechFak.Uni-Bielefeld.DE> <49076399.4070507@Sun.COM> <490831C4.1050204@Sun.COM> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Status: RO Content-Length: 406 All, Darren is correct. Further discussion should be taken off line to help clarify the specification for the review. Please include me in the off line discussions. Thanks, John Darren J Moffat wrote: > Point of order please. > > I derailed this case a few days ago. That means we should be waiting > to see full case materials and an agenda not continuing discussion. > > -- > Darren J Moffat