From Wed Jan 14 15:26:40 2009 Date: Wed, 14 Jan 2009 15:26:40 -0800 (PST) From: Postmaster Subject: Message from mail server Content-Length: 94 Mime-Version: 1.0 Status: RO X-IMAP: 1231974540 28 Delete. This is a system message. --END+PSEUDO-- From Raj.Prakash@sun.com Mon Jan 12 08:35:40 2009 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 n0CGZdOX023906 for ; Mon, 12 Jan 2009 08:35:40 -0800 (PST) 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 n0CGZaHH008012 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 13 Jan 2009 00:35:38 +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 <0KDD00D1FA3D6700@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 12 Jan 2009 08:35:37 -0800 (PST) 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 <0KDD0069DA3CLVD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 12 Jan 2009 08:35:36 -0800 (PST) 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 n0CGZaQs024728 for ; Mon, 12 Jan 2009 08:35:36 -0800 (PST) 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 <0KDD00J018GPQR00@fe-sfbay-10.sun.com> (original mail from Raj.Prakash@Sun.COM); Mon, 12 Jan 2009 08:35:36 -0800 (PST) Received: from [129.146.122.8] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD0014JA2YGG80@fe-sfbay-10.sun.com>; Mon, 12 Jan 2009 08:35:29 -0800 (PST) Date: Mon, 12 Jan 2009 08:35:22 -0800 From: Raj Prakash Subject: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] Sender: Raj.Prakash@sun.com To: LSARC-ext@sun.com Cc: Douglas.Walls@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <496B714A.5040407@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 User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Content-Length: 10159 Status: RO X-Status: $$$$ X-UID: 0000000001 Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Sun Studio C/C++/dbx Collection 1.2. Name of Document Author/Supplier: Douglas Walls (Douglas.Walls@Sun.COM> 1.3. Date of This Document: 1/8/2009 1.3.1. Date this project was conceived: 10/2008 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com 1.4.4. The name of your business unit: CODE (C/C++ Compilers, Optimization, and Debugger) 1.5. Email Aliases: 1.5.1. Responsible Manager: Kurt Goebel 1.5.2. Responsible Engineer: Douglas Walls 1.5.3. Marketing Manager: Ikroop Dhillon 1.5.4. Interest List: tools-compilers@opensolaris.org 2. Project Summary 2.1. Project Description: The project will provide C, C++ and dbx from the current Sun Studio Express release for OpenSolaris. 2.2. Risks and Assumptions: No known risks or assumptions at this time. 3. Business Summary 3.1. Problem Area: Default compilers on OpenSolaris 3.2. Market/Requester: OpenSolaris 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. 3.4. Competitive Analysis: Main competitors: Platforms & Tool Suite Offerings - Red Hat: GCC (bundled and supported) - Windows: Microsoft Visual Studio (unbundled) - MacOS: Xcode (gcc-based), LLVM effort 3.5. Opportunity Window/Exposure: 04/2009 to coincide with the next release of OpenSolaris. 3.6. How will you know when you are done?: The project will be on-going always tracking the latest express release of Sun Studio C, C++ and dbx 4. Technical Description: 4.1. Details: - Existing C, C++ and dbx components of Sun Studio Express 2008.11 release will be installed in /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU Developer Collection - Links will be created in /usr/bin, e.g. /usr/bin/cc, /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate binaries /usr/compilers/suncc2008.11/bin. - Links will be created in /usr/man, e.g. /usr/man/man1/cc, /usr/man/man1/CC, /usr/man/man1/dbx, etc., to point to man pages in /usr/compilers/suncc2008.11/man/man1. 4.2. Bug/RFE Number(s): Not applicable. 4.3. In Scope: - Sun Studio C, C++ compilers and dbx 4.4. Out of Scope: 4.5. Interfaces: The following soft links will be created in /usr/bin to point to the appropriate binaries of /usr/compilers/suncc2008.11/bin. We may choose to omit some of these links which do not contribute to minimizing compiler-related porting efforts to encourage FOSS inclussion into OpenSolaris repositories. /usr/bin/bcheck /usr/bin/c++filt /usr/bin/c89 /usr/bin/c99 /usr/bin/cb /usr/bin/cc /usr/bin/CC /usr/bin/CCadmin /usr/bin/cflow /usr/bin/cscope /usr/bin/ctcr /usr/bin/ctrace /usr/bin/cxref /usr/bin/dbx /usr/bin/dem /usr/bin/dumpstabs /usr/bin/dwarfdump /usr/bin/fbe /usr/bin/fpversion /usr/bin/indent /usr/bin/lint /usr/bin/rtc_patch_area /usr/bin/sunc89 /usr/bin/sunc99 /usr/bin/suncc /usr/bin/sunCC /usr/bin/tcov 4.6. Doc Impact: Links will be created in /usr/share/man/* for the following man pages: /usr/compilers/suncc2008.11/man1/CC.1 /usr/compilers/suncc2008.11/man1/CCadmin.1 /usr/compilers/suncc2008.11/man1/bcheck.1 /usr/compilers/suncc2008.11/man1/binopt.1 /usr/compilers/suncc2008.11/man1/c++filt.1 /usr/compilers/suncc2008.11/man1/c89.1 /usr/compilers/suncc2008.11/man1/c99.1 /usr/compilers/suncc2008.11/man1/cb.1 /usr/compilers/suncc2008.11/man1/cc.1 /usr/compilers/suncc2008.11/man1/cflow.1 /usr/compilers/suncc2008.11/man1/cscope.1 /usr/compilers/suncc2008.11/man1/ctrace.1 /usr/compilers/suncc2008.11/man1/cxref.1 /usr/compilers/suncc2008.11/man1/dbx.1 /usr/compilers/suncc2008.11/man1/dem.1 /usr/compilers/suncc2008.11/man1/fbe.1 /usr/compilers/suncc2008.11/man1/fpversion.1 /usr/compilers/suncc2008.11/man1/indent.1 /usr/compilers/suncc2008.11/man1/inline.1 /usr/compilers/suncc2008.11/man1/lint.1 /usr/compilers/suncc2008.11/man1/rtc_patch_area.1 /usr/compilers/suncc2008.11/man1/ss_attach.1 /usr/compilers/suncc2008.11/man3/gcFixPrematureFrees.3 /usr/compilers/suncc2008.11/man3/gcInitialize.3 /usr/compilers/suncc2008.11/man3cc4/cartpol.3 /usr/compilers/suncc2008.11/man3cc4/cplx.intro.3 /usr/compilers/suncc2008.11/man3cc4/cplxerr.3 /usr/compilers/suncc2008.11/man3cc4/cplxexp.3 /usr/compilers/suncc2008.11/man3cc4/cplxops.3 /usr/compilers/suncc2008.11/man3cc4/cplxtrig.3 /usr/compilers/suncc2008.11/man3cc4/filebuf.3 /usr/compilers/suncc2008.11/man3cc4/fstream.3 /usr/compilers/suncc2008.11/man3cc4/interrupt.3 /usr/compilers/suncc2008.11/man3cc4/ios.3 /usr/compilers/suncc2008.11/man3cc4/ios.intro.3 /usr/compilers/suncc2008.11/man3cc4/istream.3 /usr/compilers/suncc2008.11/man3cc4/manip.3 /usr/compilers/suncc2008.11/man3cc4/ostream.3 /usr/compilers/suncc2008.11/man3cc4/queue.3 /usr/compilers/suncc2008.11/man3cc4/sbufprot.3 /usr/compilers/suncc2008.11/man3cc4/sbufpub.3 /usr/compilers/suncc2008.11/man3cc4/ssbuf.3 /usr/compilers/suncc2008.11/man3cc4/stdiobuf.3 /usr/compilers/suncc2008.11/man3cc4/stream_MT.3 /usr/compilers/suncc2008.11/man3cc4/stream_locker.3 /usr/compilers/suncc2008.11/man3cc4/strstream.3 /usr/compilers/suncc2008.11/man3cc4/task.3 /usr/compilers/suncc2008.11/man3cc4/task.intro.3 /usr/compilers/suncc2008.11/man3cc4/tasksim.3 /usr/compilers/suncc2008.11/man3x/_rtc_check_free.3x /usr/compilers/suncc2008.11/man3x/_rtc_check_malloc.3x /usr/compilers/suncc2008.11/man3x/_rtc_check_malloc_result.3x /usr/compilers/suncc2008.11/man3x/_rtc_check_realloc.3x /usr/compilers/suncc2008.11/man3x/_rtc_check_realloc_result.3x /usr/compilers/suncc2008.11/man3x/_rtc_hide_region.3x /usr/compilers/suncc2008.11/man3x/_rtc_off.3x /usr/compilers/suncc2008.11/man3x/_rtc_on.3x /usr/compilers/suncc2008.11/man3x/_rtc_record_free.3x /usr/compilers/suncc2008.11/man3x/_rtc_record_malloc.3x /usr/compilers/suncc2008.11/man3x/_rtc_record_realloc.3x /usr/compilers/suncc2008.11/man3x/_rtc_report_error.3x /usr/compilers/suncc2008.11/man3x/rtc_api.3x /usr/compilers/suncc2008.11/man4/dbxrc.4 4.7. Admin/Config Impact: No change. 4.8. HA Impact: No change. 4.9. I18N/L10N Impact: Sun Studio C/C++/dbx Collection is I18N L10N to be coordinated with Nevada L10N 4.10. Packaging & Delivery: Name Stability Notes ==== ========= ===== SUNWcompilers Committed Sun Studio C/C++/dbx core cluster SUNWcompilerlinks Committed Sun Studio C/C++/dbx /usr/bin /usr/man links 4.11. Security Impact: No impact. 4.12. Dependencies: SUNWlibC C++ stdlibs SUNWlibms limtsk, etc. SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWesu Extended System Utilities SUNWhea Header files SUNWkvm Core Architecture, (Kvm) SUNWtoo Programming Tools 5. Reference Documents: LSARC/2008/776 GNU Developer Collection LSARC/2006/280 Tools DVD for S10u2 PSARC/2007/074 /usr/gnu Established precedent of having program visible by multiple names. 6. Resources and Schedule: 6.1. Projected Availability: April 2009 to coincide with OpenSolaris 2009.04 6.2. Cost of Effort: .5 developers. 6.3. Cost of Capital Resources: No additional capital resources were required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Devpro 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: Build 107 01/26/2009. 6.4.8. Target Code Design Review Date: Completed 6.4.9. Update approval addition: - SPDE PAC scheduling in progress - Solaris PAC scheduling in progress 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Not applicable. 7. Prototype Availability: 7.1. Prototype Availability: Not applicable. 7.2. Prototype Cost: Not Applicable. From ro@techfak.uni-bielefeld.de Mon Jan 12 10:12:38 2009 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 n0CICYxa026631 for ; Mon, 12 Jan 2009 10:12:37 -0800 (PST) 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 n0CICT75006517; Tue, 13 Jan 2009 02:12:29 +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 <0KDD00J01EKS3000@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Jan 2009 10:12:28 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDD00DBOEKSN760@nwk-avmta-2.sfbay.sun.com>; Mon, 12 Jan 2009 10:12:28 -0800 (PST) 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 n0CI0m4g022714; Mon, 12 Jan 2009 18:12:28 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-2278863; Mon, 12 Jan 2009 18:12:27 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-59715846; Mon, 12 Jan 2009 18:12:26 +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-25145355; Mon, 12 Jan 2009 18:12:26 +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 D144F4834A; Mon, 12 Jan 2009 19:12:25 +0100 (CET) Date: Mon, 12 Jan 2009 19:12:25 +0100 From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Raj Prakash's message of "Mon, 12 Jan 2009 08:35:22 -0800" Sender: ro@techfak.uni-bielefeld.de To: Raj Prakash Cc: LSARC-ext@sun.com, Douglas.Walls@sun.com, Chris.Quenelle@sun.com, David.Ford@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 0.128sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 35 References: <496B714A.5040407@sun.com> Content-Length: 1700 Status: RO X-Status: $$$$ X-UID: 0000000002 Raj Prakash writes: > 4. Technical Description: > 4.1. Details: > - Existing C, C++ and dbx components of Sun Studio Express > 2008.11 release will be installed in > /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU > Developer Collection I've the same objections here as I've raised for LSARC/2008/776 (many of which haven't been answered yet): * Where's the need (or precedent) for the deep nesting with /usr/compilers/suncc2008.11? All other cases use (say) /usr/suncc/2008.11, as I've mentioned several times before. * Where's the need for this level of granularity. If the plan is to integrate successive releases of Studio Express, I cannot see a reason to have them installed in parallel (I see them as similar to Studio 12 + Patches, which aren't installed in parallel either). On the other hand, this creates a usability problem: if the intention is to install different versions of the Studio compilers in parallel (which certainly makes sense e.g. for Studio 12 + Studio Express), the user is not generally interested in which particular delivery (or patch level) of the Studio tools he is using, only in the distinction between Studio 12 and Express. If he wants to specificially select Studio Express when Studio 12 is installed as well, in the proposed scheme he has to update his PATH every time a new delivery is included (which could be as often as every three months), instead of selecting Studio Express vs. Studio 12 once. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Chris.Quenelle@sun.com Mon Jan 12 11:31:19 2009 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 n0CJVJNM000106 for ; Mon, 12 Jan 2009 11:31:19 -0800 (PST) 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 n0CJVIBh008048 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 12 Jan 2009 11:31:18 -0800 (PST) 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 <0KDD00F0NI85VA00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:31:17 -0700 (MST) 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 <0KDD0016LI84KGC0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:31:16 -0700 (MST) 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 n0CJVGQa004775 for ; Mon, 12 Jan 2009 11:31:16 -0800 (PST) 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 <0KDD00101HZDVR00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 11:31:16 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD000NQI7X9P20@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 11:31:13 -0800 (PST) Date: Mon, 12 Jan 2009 11:28:32 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Sender: Chris.Quenelle@sun.com To: Rainer Orth Cc: Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com, David.Ford@sun.com Reply-to: Chris.Quenelle@sun.com Message-id: <496B99E0.8020808@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 2823 Status: RO X-Status: $$$$ X-UID: 0000000003 Rainer, You raise some good points. What would you recommend to resolve your issues? /usr/suncc/*? How should we anticipate the future possible parallel inclusion of SS12+patches? Perhaps /usr/sunccx for the latest express and /usr/suncc for the latest stable/FCS release? I agree that the more normal convention for projects is /usr/XXXX. Do you think the creation of /usr/compilers is so confusing or different that the project should be forcibly prevented from using that path? (I'm trying to understand the scope of the issue) Note: The rationale for multiple versions of gcc is very different than for Sun Studio compilers. I'm not trying to imply anything here about the GCC case. Also Note: The case doesn't discuss how a parallel delivery of two compilers (EG SS12 and SSX) will be handled with regards to symlinks and default paths. That is still TBD at this point. The goal is for the symlinks to cause the "right thing" to happen by default for almost all Solaris developers. IE: You just automatically get a compiler that works. The only concession we've made is to put the symlinks into a separate package, but that's not really a complete story yet. --chris Rainer Orth wrote: > Raj Prakash writes: > >> 4. Technical Description: >> 4.1. Details: >> - Existing C, C++ and dbx components of Sun Studio Express >> 2008.11 release will be installed in >> /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU >> Developer Collection > > I've the same objections here as I've raised for LSARC/2008/776 (many of > which haven't been answered yet): > > * Where's the need (or precedent) for the deep nesting with > /usr/compilers/suncc2008.11? All other cases use (say) > /usr/suncc/2008.11, as I've mentioned several times before. > > * Where's the need for this level of granularity. If the plan is to > integrate successive releases of Studio Express, I cannot see a reason to > have them installed in parallel (I see them as similar to Studio 12 + > Patches, which aren't installed in parallel either). On the other hand, > this creates a usability problem: if the intention is to install > different versions of the Studio compilers in parallel (which certainly > makes sense e.g. for Studio 12 + Studio Express), the user is not > generally interested in which particular delivery (or patch level) of the > Studio tools he is using, only in the distinction between Studio 12 and > Express. If he wants to specificially select Studio Express when Studio > 12 is installed as well, in the proposed scheme he has to update his PATH > every time a new delivery is included (which could be as often as every > three months), instead of selecting Studio Express vs. Studio 12 once. > > Rainer > From Torrey.McMahon@sun.com Mon Jan 12 11:39:15 2009 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 n0CJdFCq000396 for ; Mon, 12 Jan 2009 11:39:15 -0800 (PST) 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 n0CJdEsF013631 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 12 Jan 2009 11:39:15 -0800 (PST) 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 <0KDD00G01ILFKP00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:39:15 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDD0013XILEKQB0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:39:14 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0CJdEh6002489 for ; Mon, 12 Jan 2009 19:39:14 +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 <0KDD00801IGWW600@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:39:14 -0700 (MST) Received: from [192.168.0.198] ([69.143.10.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD00GDAIL0DGF0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 12:39:02 -0700 (MST) Date: Mon, 12 Jan 2009 14:39:01 -0500 From: Torrey McMahon Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496B99E0.8020808@Sun.COM> Sender: Torrey.McMahon@sun.com To: Chris.Quenelle@sun.com Cc: Rainer Orth , Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com, David.Ford@sun.com Message-id: <496B9C55.6090706@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1 Content-Length: 3166 Status: RO X-Status: $$$$ X-UID: 0000000004 Doesn't the method by which you deal with parallel delivery of packages, be it gcc or sunstudio, and any linking impact the install location and default path? On 1/12/2009 2:28 PM, Chris Quenelle wrote: > Rainer, > > You raise some good points. > What would you recommend to resolve your issues? > /usr/suncc/*? > > How should we anticipate the future possible parallel > inclusion of SS12+patches? Perhaps /usr/sunccx for > the latest express and /usr/suncc for the latest stable/FCS release? > > I agree that the more normal convention for projects is /usr/XXXX. > Do you think the creation of /usr/compilers is so confusing > or different that the project should be forcibly prevented from > using that path? (I'm trying to understand the scope of the issue) > > Note: The rationale for multiple versions of gcc is > very different than for Sun Studio compilers. I'm not > trying to imply anything here about the GCC case. > > Also Note: > The case doesn't discuss how a parallel delivery of two > compilers (EG SS12 and SSX) will be handled with regards > to symlinks and default paths. That is still TBD at this point. > The goal is for the symlinks to cause the "right thing" to > happen by default for almost all Solaris developers. > IE: You just automatically get a compiler that works. > The only concession we've made is to put the symlinks into > a separate package, but that's not really a complete story yet. > > > --chris > > > Rainer Orth wrote: > >> Raj Prakash writes: >> >> >>> 4. Technical Description: >>> 4.1. Details: >>> - Existing C, C++ and dbx components of Sun Studio Express >>> 2008.11 release will be installed in >>> /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU >>> Developer Collection >>> >> I've the same objections here as I've raised for LSARC/2008/776 (many of >> which haven't been answered yet): >> >> * Where's the need (or precedent) for the deep nesting with >> /usr/compilers/suncc2008.11? All other cases use (say) >> /usr/suncc/2008.11, as I've mentioned several times before. >> >> * Where's the need for this level of granularity. If the plan is to >> integrate successive releases of Studio Express, I cannot see a reason to >> have them installed in parallel (I see them as similar to Studio 12 + >> Patches, which aren't installed in parallel either). On the other hand, >> this creates a usability problem: if the intention is to install >> different versions of the Studio compilers in parallel (which certainly >> makes sense e.g. for Studio 12 + Studio Express), the user is not >> generally interested in which particular delivery (or patch level) of the >> Studio tools he is using, only in the distinction between Studio 12 and >> Express. If he wants to specificially select Studio Express when Studio >> 12 is installed as well, in the proposed scheme he has to update his PATH >> every time a new delivery is included (which could be as often as every >> three months), instead of selecting Studio Express vs. Studio 12 once. >> >> Rainer >> >> From Chris.Quenelle@Sun.COM Mon Jan 12 13:16:33 2009 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 n0CLGXPE020484 for ; Mon, 12 Jan 2009 13:16:33 -0800 (PST) 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 n0CLGWCT002287 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 12 Jan 2009 13:16:32 -0800 (PST) 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 <0KDD00301N3KB300@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:16:32 -0700 (MST) 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 <0KDD00MDRN3H1Q20@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:16:31 -0700 (MST) 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 n0CLGSQB019124 for ; Mon, 12 Jan 2009 13:16:28 -0800 (PST) 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 <0KDD00C01MZPDH00@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:16:28 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD00MZ0N38UE40@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:16:21 -0800 (PST) Date: Mon, 12 Jan 2009 13:13:43 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496B9C55.6090706@sun.com> Sender: Chris.Quenelle@Sun.COM To: Torrey McMahon Cc: Rainer Orth , Raj Prakash , LSARC-ext@Sun.COM, Douglas.Walls@Sun.COM, David.Ford@Sun.COM Reply-to: Chris.Quenelle@Sun.COM Message-id: <496BB287.9030502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 4247 Status: RO X-Status: $$$$ X-UID: 0000000005 Torrey McMahon wrote: > Doesn't the method by which you deal with parallel delivery of packages, > be it gcc or sunstudio, and any linking impact the install location and > default path? There is no "default path" because this is a bundled component, the path that we choose will be hard-wired for this delivery of the bits. It was probably a mistake to use "Sun Studio" in the name of this ARC case, because the delivery is separate from the official "Sun Studio" product per-se. The answer to your question is yes. The impact is this: If we want to support parallel delivery of multiple versions of Sun Studio Express, then we'll need to use a version specific name for the path. The same decision applies to parallel install of SS12 and SSX. The case proposes to use a fully-distinguished path (including version number). This leaves our options open to support parallel installs in whatever form we choose without committing us to do so. Any feedback for or against parallel installs of Sun compilers would be appreciated. Might we want both SS11 and SS12 in Nevada at the same time? Or in Solaris 10? --chris > > On 1/12/2009 2:28 PM, Chris Quenelle wrote: >> Rainer, >> >> You raise some good points. >> What would you recommend to resolve your issues? >> /usr/suncc/*? >> >> How should we anticipate the future possible parallel >> inclusion of SS12+patches? Perhaps /usr/sunccx for >> the latest express and /usr/suncc for the latest stable/FCS release? >> >> I agree that the more normal convention for projects is /usr/XXXX. >> Do you think the creation of /usr/compilers is so confusing >> or different that the project should be forcibly prevented from >> using that path? (I'm trying to understand the scope of the issue) >> >> Note: The rationale for multiple versions of gcc is >> very different than for Sun Studio compilers. I'm not >> trying to imply anything here about the GCC case. >> >> Also Note: >> The case doesn't discuss how a parallel delivery of two >> compilers (EG SS12 and SSX) will be handled with regards >> to symlinks and default paths. That is still TBD at this point. >> The goal is for the symlinks to cause the "right thing" to >> happen by default for almost all Solaris developers. >> IE: You just automatically get a compiler that works. >> The only concession we've made is to put the symlinks into >> a separate package, but that's not really a complete story yet. >> >> >> --chris >> >> >> Rainer Orth wrote: >> >>> Raj Prakash writes: >>> >>> >>>> 4. Technical Description: >>>> 4.1. Details: >>>> - Existing C, C++ and dbx components of Sun Studio Express >>>> 2008.11 release will be installed in >>>> /usr/compilers/suncc2008.11 similar to LSARC/2008/776 GNU >>>> Developer Collection >>>> >>> I've the same objections here as I've raised for LSARC/2008/776 (many of >>> which haven't been answered yet): >>> >>> * Where's the need (or precedent) for the deep nesting with >>> /usr/compilers/suncc2008.11? All other cases use (say) >>> /usr/suncc/2008.11, as I've mentioned several times before. >>> >>> * Where's the need for this level of granularity. If the plan is to >>> integrate successive releases of Studio Express, I cannot see a >>> reason to >>> have them installed in parallel (I see them as similar to Studio 12 + >>> Patches, which aren't installed in parallel either). On the other >>> hand, >>> this creates a usability problem: if the intention is to install >>> different versions of the Studio compilers in parallel (which >>> certainly >>> makes sense e.g. for Studio 12 + Studio Express), the user is not >>> generally interested in which particular delivery (or patch level) >>> of the >>> Studio tools he is using, only in the distinction between Studio >>> 12 and >>> Express. If he wants to specificially select Studio Express when >>> Studio >>> 12 is installed as well, in the proposed scheme he has to update >>> his PATH >>> every time a new delivery is included (which could be as often as >>> every >>> three months), instead of selecting Studio Express vs. Studio 12 >>> once. >>> >>> Rainer >>> >>> From Torrey.McMahon@sun.com Mon Jan 12 13:22:44 2009 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 n0CLMh00020785 for ; Mon, 12 Jan 2009 13:22:44 -0800 (PST) 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 n0CLMfBZ020390 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 13 Jan 2009 05:22:42 +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 <0KDD00701NDTO400@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:22:41 -0800 (PST) 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 <0KDD0048HNDS6140@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:22:41 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0CLMePZ018459 for ; Mon, 12 Jan 2009 21:22:40 +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 <0KDD00I01MKHAF00@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:22:40 -0700 (MST) Received: from [192.168.0.198] ([69.143.10.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD00HFUND28220@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:22:15 -0700 (MST) Date: Mon, 12 Jan 2009 16:22:14 -0500 From: Torrey McMahon Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BB287.9030502@Sun.COM> Sender: Torrey.McMahon@sun.com To: Chris.Quenelle@sun.com Cc: Rainer Orth , Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com, David.Ford@sun.com Message-id: <496BB486.6030209@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1 Content-Length: 1496 Status: RO X-Status: $$$$ X-UID: 0000000006 On 1/12/2009 4:13 PM, Chris Quenelle wrote: > Torrey McMahon wrote: > >> Doesn't the method by which you deal with parallel delivery of packages, >> be it gcc or sunstudio, and any linking impact the install location and >> default path? >> > > There is no "default path" because this is a bundled component, > the path that we choose will be hard-wired for this delivery > of the bits. It was probably a mistake to use "Sun Studio" in > the name of this ARC case, because the delivery is separate from > the official "Sun Studio" product per-se. > > The answer to your question is yes. The impact is this: > If we want to support parallel delivery of multiple versions > of Sun Studio Express, then we'll need to use a version specific > name for the path. The same decision applies to parallel install > of SS12 and SSX. The case proposes to use a fully-distinguished > path (including version number). This leaves our options open > to support parallel installs in whatever form we choose without > committing us to do so. > > Any feedback for or against parallel installs of Sun compilers > would be appreciated. Might we want both SS11 and SS12 in Nevada > at the same time? Or in Solaris 10? I might be asking a lot here but it would be nice if there was some CLI/GUI widget that lists all of the relevant versions and lets a user select the one they want to be their preferred version. Netbeans has something like that last I checked though it's product specific. From Chris.Quenelle@Sun.COM Mon Jan 12 13:47:12 2009 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 n0CLlBqa021573 for ; Mon, 12 Jan 2009 13:47:12 -0800 (PST) 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 n0CLl91T017459 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 12 Jan 2009 21:47:10 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 <0KDD0060ROILDI00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:47:09 -0700 (MST) 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 <0KDD00MUMOIL1D40@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 14:47:09 -0700 (MST) 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 n0CLl8p7023862 for ; Mon, 12 Jan 2009 13:47:08 -0800 (PST) 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 <0KDD00601OGRZT00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:47:08 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD003NAOI91M40@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 13:46:57 -0800 (PST) Date: Mon, 12 Jan 2009 13:44:20 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BB486.6030209@sun.com> Sender: Chris.Quenelle@Sun.COM To: Torrey McMahon Cc: Rainer Orth , Raj Prakash , LSARC-ext@Sun.COM, Douglas.Walls@Sun.COM, David.Ford@Sun.COM Reply-to: Chris.Quenelle@Sun.COM Message-id: <496BB9B4.3010502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 1315 Status: RO X-Status: $$$$ X-UID: 0000000007 Torrey McMahon wrote: > I might be asking a lot here but it would be nice if there was some > CLI/GUI widget that lists all of the relevant versions and lets a user > select the one they want to be their preferred version. Netbeans has > something like that last I checked though it's product specific. This is certainly a very reasonable thing to ask. But we don't yet have any distribution with more than one version bundled. So we decided to defer this until we got more user feedback. The argument against this is that the normal UNIX way of doing this is to use your PATH to select a customized search order if you are not happy with the default search order. If you put /usr/compilers/XXXX/bin (or whatever) in your path before /usr/bin, then you can select which compiler you want to be the "default" compiler. This works for command-line selection. Controlling which compiler is seen by a configure script that looks stright at /usr/bin/cc is a harder problem, and requires some sort of package change. In my mind, I am hoping we can get by with telling users to use the package manager to uninstall the "sunstudioXXXXlinks" package, and install a different, non-default "XXXXlinks" package to control which symlinks they want in /usr/bin. But that's still very tentative at this point. --chris From swalker@opensolaris.org Mon Jan 12 14:13:36 2009 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 n0CMDZB7022807 for ; Mon, 12 Jan 2009 14:13:36 -0800 (PST) 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 n0CMDOr9017419; Tue, 13 Jan 2009 06:13:29 +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 <0KDD00B03PQFUE00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 12 Jan 2009 14:13:27 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDD003RFPQEOV60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 12 Jan 2009 14:13:26 -0800 (PST) Received: from [10.7.250.78] (punchin-client-10-7-250-78.SFBay.Sun.COM [10.7.250.78]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0CMDPBK937066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 14:13:26 -0800 (PST) Date: Mon, 12 Jan 2009 16:13:21 -0600 From: Shawn Walker Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BB9B4.3010502@Sun.COM> To: Chris.Quenelle@sun.com Cc: Torrey McMahon , David.Ford@sun.com, Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <496BC081.3080905@opensolaris.org> 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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> <496BB9B4.3010502@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Content-Length: 1630 Status: RO X-Status: $$$$ X-UID: 0000000008 Chris Quenelle wrote: > Torrey McMahon wrote: >> I might be asking a lot here but it would be nice if there was some >> CLI/GUI widget that lists all of the relevant versions and lets a user >> select the one they want to be their preferred version. Netbeans has >> something like that last I checked though it's product specific. > > This is certainly a very reasonable thing to ask. But we don't yet have > any distribution with more than one version bundled. So we decided > to defer this until we got more user feedback. The argument against this > is that the normal UNIX way of doing this is to use your PATH to select > a customized search order if you are not happy with the default > search order. If you put /usr/compilers/XXXX/bin (or whatever) in your > path before /usr/bin, then you can select which compiler you want to > be the "default" compiler. This works for command-line selection. > Controlling which compiler is seen by a configure script that > looks stright at /usr/bin/cc is a harder problem, and requires some > sort of package change. > > In my mind, I am hoping we can get by with telling users to use the > package manager to uninstall the "sunstudioXXXXlinks" package, and > install a different, non-default "XXXXlinks" package to control > which symlinks they want in /usr/bin. But that's still very tentative > at this point. ...and the symlinks approach also happens to be the best model for working with the pkg(5) system at the moment as far as I'm aware. packages are manageable; random symlinks are not and just end punting the management onto another program. -- Shawn Walker From Torrey.McMahon@sun.com Mon Jan 12 15:34:54 2009 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 n0CNYrcb025028 for ; Mon, 12 Jan 2009 15:34:54 -0800 (PST) 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 n0CNYjq4028029 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 13 Jan 2009 07:34:52 +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 <0KDD00G0DTI37100@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 15:34:51 -0800 (PST) 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 <0KDD004C6TI261D0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 15:34:50 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0CNYorq015299 for ; Mon, 12 Jan 2009 23:34:50 +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 <0KDD00901TCIKR00@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:34:50 -0700 (MST) Received: from [192.168.0.198] ([69.143.10.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD008FBTI0RYD0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:34:49 -0700 (MST) Date: Mon, 12 Jan 2009 18:34:48 -0500 From: Torrey McMahon Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BC081.3080905@opensolaris.org> Sender: Torrey.McMahon@sun.com To: Shawn Walker Cc: Chris.Quenelle@sun.com, David.Ford@sun.com, Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <496BD398.206@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> <496BB9B4.3010502@Sun.COM> <496BC081.3080905@opensolaris.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1 Content-Length: 2547 Status: RO X-Status: $$$$ X-UID: 0000000009 On 1/12/2009 5:13 PM, Shawn Walker wrote: > Chris Quenelle wrote: >> Torrey McMahon wrote: >>> I might be asking a lot here but it would be nice if there was some >>> CLI/GUI widget that lists all of the relevant versions and lets a user >>> select the one they want to be their preferred version. Netbeans has >>> something like that last I checked though it's product specific. >> >> This is certainly a very reasonable thing to ask. But we don't yet have >> any distribution with more than one version bundled. So we decided >> to defer this until we got more user feedback. The argument against >> this >> is that the normal UNIX way of doing this is to use your PATH to select >> a customized search order if you are not happy with the default >> search order. If you put /usr/compilers/XXXX/bin (or whatever) in your >> path before /usr/bin, then you can select which compiler you want to >> be the "default" compiler. This works for command-line selection. >> Controlling which compiler is seen by a configure script that >> looks stright at /usr/bin/cc is a harder problem, and requires some >> sort of package change. >> >> In my mind, I am hoping we can get by with telling users to use the >> package manager to uninstall the "sunstudioXXXXlinks" package, and >> install a different, non-default "XXXXlinks" package to control >> which symlinks they want in /usr/bin. But that's still very tentative >> at this point. > > ...and the symlinks approach also happens to be the best model for > working with the pkg(5) system at the moment as far as I'm aware. > > packages are manageable; random symlinks are not and just end punting > the management onto another program. What's the plan for systems that have multiple users or users that require access to different versions at different times? In theory you'd want to allow a user to have access to multiple versions of the {toolkit, compiler, ...} and let them select which they want as default. It might be as simple as, "Have the user change their path" but it shouldn't be that hard to do and the system shouldn't get in the way. If I have /usr/bin in my path and all those symlinks are in the way I'd have to make sure I place /path/to/the/version I want at the front every time I want to override. (Perhaps do the logout/login cha-cha too.) Setting an environment variable is a bit easier but requires a lot more work on the part of the packagers. I'm thinking along the lines of ISALIST when used, ironically, when building things in the first place. From Chris.Quenelle@sun.com Mon Jan 12 16:05:33 2009 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 n0D05WBW013203 for ; Mon, 12 Jan 2009 16:05:32 -0800 (PST) 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 n0D05Lct009879 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 13 Jan 2009 00:05:31 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 <0KDD00K0JUX4MF00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 17:05:28 -0700 (MST) 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 <0KDD00MR0UX31FD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 17:05:27 -0700 (MST) 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 n0D05RlN010737 for ; Mon, 12 Jan 2009 16:05:27 -0800 (PST) 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 <0KDD00J01UQVBA00@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:05:27 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD00BYAUWXU4A0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:05:21 -0800 (PST) Date: Mon, 12 Jan 2009 16:02:44 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BD398.206@sun.com> Sender: Chris.Quenelle@sun.com To: Torrey McMahon Cc: Shawn Walker , David.Ford@sun.com, Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Reply-to: Chris.Quenelle@sun.com Message-id: <496BDA24.30905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> <496BB9B4.3010502@Sun.COM> <496BC081.3080905@opensolaris.org> <496BD398.206@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 1446 Status: RO X-Status: $$$$ X-UID: 0000000010 Torrey McMahon wrote: > What's the plan for systems that have multiple users or users that > require access to different versions at different times? In theory you'd > want to allow a user to have access to multiple versions of the > {toolkit, compiler, ...} and let them select which they want as default. > It might be as simple as, "Have the user change their path" but it > shouldn't be that hard to do and the system shouldn't get in the way. If > I have /usr/bin in my path and all those symlinks are in the way I'd > have to make sure I place /path/to/the/version I want at the front every > time I want to override. (Perhaps do the logout/login cha-cha too.) > Setting an environment variable is a bit easier but requires a lot more > work on the part of the packagers. I'm thinking along the lines of > ISALIST when used, ironically, when building things in the first place. For the forseeable future, unbundled versions of Sun Studio will still be available for download and install as before. This case only covers the inclusion of one specific version as a bundled compiler. Using packaging to select the default compiler is not nearly as useful on a multi-user system as it is on a single-user system. We are not solving the "$PATH sucks" problem. Perhaps you are prepared to argue that we should not include any compiler on the user's default path because we might chose wrong. I don't think you'd win that argument. --chris From Torrey.McMahon@sun.com Mon Jan 12 16:17:33 2009 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 n0D0HWMB014797 for ; Mon, 12 Jan 2009 16:17:33 -0800 (PST) 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 n0D0HSwQ017091 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 13 Jan 2009 00:17: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 <0KDD00I03VH7W900@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:17:31 -0800 (PST) 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 <0KDD00HSSVH7HDA0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:17:31 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0D0HV7o000053 for ; Tue, 13 Jan 2009 00:17:31 +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 <0KDD00F01UE80H00@mail-amer.sun.com> (original mail from Torrey.McMahon@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 17:17:31 -0700 (MST) Received: from [192.168.0.198] ([69.143.10.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD000POVGTZIC0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 17:17:18 -0700 (MST) Date: Mon, 12 Jan 2009 19:17:18 -0500 From: Torrey McMahon Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BDA24.30905@Sun.COM> Sender: Torrey.McMahon@sun.com To: Chris.Quenelle@sun.com Cc: Shawn Walker , David.Ford@sun.com, Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <496BDD8E.2080309@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> <496BB9B4.3010502@Sun.COM> <496BC081.3080905@opensolaris.org> <496BD398.206@sun.com> <496BDA24.30905@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1 Content-Length: 1844 Status: RO X-Status: $$$$ X-UID: 0000000011 On 1/12/2009 7:02 PM, Chris Quenelle wrote: > Torrey McMahon wrote: > >> What's the plan for systems that have multiple users or users that >> require access to different versions at different times? In theory you'd >> want to allow a user to have access to multiple versions of the >> {toolkit, compiler, ...} and let them select which they want as default. >> It might be as simple as, "Have the user change their path" but it >> shouldn't be that hard to do and the system shouldn't get in the way. If >> I have /usr/bin in my path and all those symlinks are in the way I'd >> have to make sure I place /path/to/the/version I want at the front every >> time I want to override. (Perhaps do the logout/login cha-cha too.) >> Setting an environment variable is a bit easier but requires a lot more >> work on the part of the packagers. I'm thinking along the lines of >> ISALIST when used, ironically, when building things in the first place. >> > > > For the forseeable future, unbundled versions of Sun Studio will still be > available for download and install as before. This case only covers > the inclusion of one specific version as a bundled compiler. > > Using packaging to select the default compiler is not nearly as useful > on a multi-user system as it is on a single-user system. > > We are not solving the "$PATH sucks" problem. > > Perhaps you are prepared to argue that we should not include any > compiler on the user's default path because we might chose wrong. > I don't think you'd win that argument. > Not at all. Just that, down the road, we should make sure to keep such things in mind. A standard way to allow such things to live together would be nice. Even in the case of gnu vs. sunstudio. Again, I'll point at the NetBeans example but expand it to be system wide for what I'm thinking about. From Chris.Quenelle@Sun.COM Mon Jan 12 16:23:26 2009 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 n0D0NPlZ014993 for ; Mon, 12 Jan 2009 16:23:26 -0800 (PST) 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 n0D0NOCu061695 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 12 Jan 2009 17:23:25 -0700 (MST) 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 <0KDD0070JVR0FX00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:23:24 -0800 (PST) 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 <0KDD00K7KVQZQN50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:23:23 -0800 (PST) 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 n0D0NNjL012688 for ; Mon, 12 Jan 2009 16:23:23 -0800 (PST) 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 <0KDD00201VML1900@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:23:23 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDD009SPVQP9DC0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 12 Jan 2009 16:23:17 -0800 (PST) Date: Mon, 12 Jan 2009 16:20:35 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496BDD8E.2080309@sun.com> Sender: Chris.Quenelle@Sun.COM To: Torrey McMahon Cc: Shawn Walker , David.Ford@Sun.COM, Douglas.Walls@Sun.COM, LSARC-ext@Sun.COM, Raj Prakash Reply-to: Chris.Quenelle@Sun.COM Message-id: <496BDE53.4000303@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <496B9C55.6090706@sun.com> <496BB287.9030502@Sun.COM> <496BB486.6030209@sun.com> <496BB9B4.3010502@Sun.COM> <496BC081.3080905@opensolaris.org> <496BD398.206@sun.com> <496BDA24.30905@Sun.COM> <496BDD8E.2080309@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 434 Status: RO X-Status: $$$$ X-UID: 0000000012 Torrey McMahon wrote: > Not at all. Just that, down the road, we should make sure to keep such > things in mind. A standard way to allow such things to live together > would be nice. Even in the case of gnu vs. sunstudio. Again, I'll point > at the NetBeans example but expand it to be system wide for what I'm > thinking about. Can you give me a pointer to a description of the netbeans solution to this kind of problem? --chris From ro@techfak.uni-bielefeld.de Tue Jan 13 07:03:34 2009 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 n0DF3YD1021968 for ; Tue, 13 Jan 2009 07:03:34 -0800 (PST) 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 n0DF3Tt0038374; Tue, 13 Jan 2009 08:03:32 -0700 (MST) 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 <0KDF0006B0HUY800@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 08:03:30 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF00JQL0HSRH50@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 08:03:28 -0700 (MST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0DEwjfk002458; Tue, 13 Jan 2009 15:03:27 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-199431; Tue, 13 Jan 2009 15:03:24 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-61032499; Tue, 13 Jan 2009 15:03:23 +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-18500740; Tue, 13 Jan 2009 15:03:23 +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 BB4A3482C7; Tue, 13 Jan 2009 16:03:22 +0100 (CET) Date: Tue, 13 Jan 2009 16:03:20 +0100 (MET) From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496B99E0.8020808@Sun.COM> To: Chris.Quenelle@sun.com Cc: Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com, David.Ford@sun.com Message-id: <18796.44344.585396.842019@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.2/5.0, scanned in 0.376sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> Content-Length: 3430 Status: RO X-Status: $$$$ X-UID: 0000000013 Chris, > You raise some good points. > What would you recommend to resolve your issues? > /usr/suncc/*? in principle, yes, though I'm a bit confused about the suncc moniker. It reminds me of Sun C Compiler, which doesn't seem to fit given that all of C, C++ and Fortran are included. I suppose it is meant as Sun Compiler Collection, just like GCC was reinterpreted from GNU C Compiler to GNU Compiler Collection? I'd have chosen /usr/studio/* instead, but given Sun Marketing's history of randomly renaming products at least every other year (consider WorkShop, Forte, Studio ...), this may be unwise. > How should we anticipate the future possible parallel > inclusion of SS12+patches? Perhaps /usr/sunccx for > the latest express and /usr/suncc for the latest stable/FCS release? I'd just use /usr/suncc/12.0 and /usr/suncc/13.0 (or omit the .0 part if there are no and never will be minor releases), just as is done for all other cases of parallel installations (like mysql, postgres, ...). This is a model familiar to users. One might want to think about 13.0ea or some such while Studio 13 isn't yet released to make users aware that they are using an alpha/beta product, but that's about it. I don't think a solution that only supports the latest stable version and express is enough. Many sites may need to have more different version installed in parallel, and using a different directory in /usr for each such version seems to unnecessarily clutter that directory. > I agree that the more normal convention for projects is /usr/XXXX. > Do you think the creation of /usr/compilers is so confusing > or different that the project should be forcibly prevented from > using that path? (I'm trying to understand the scope of the issue) It's just different from a well-established convention, and if there are no very good reasons to deviate here, I'd strongly suggest to stay with the convention. Familiarity helps users, and so far I've seen no strong argument suggesting why this different convention (/usr/compilers/) is useful or necessary. > Note: The rationale for multiple versions of gcc is > very different than for Sun Studio compilers. I'm not > trying to imply anything here about the GCC case. Even in the Studio case, it is useful to keep more than two versions around. At least our site currently does. > Also Note: > The case doesn't discuss how a parallel delivery of two > compilers (EG SS12 and SSX) will be handled with regards > to symlinks and default paths. That is still TBD at this point. > The goal is for the symlinks to cause the "right thing" to > happen by default for almost all Solaris developers. > IE: You just automatically get a compiler that works. > The only concession we've made is to put the symlinks into > a separate package, but that's not really a complete story yet. Maybe something can be learned from the JDK deliveries here? I don't know the full story, but know that the JDK 1.5 and 1.6 packages somehow dealt with setting a default. In my opinion, the only sane solution is to have the latest stable version as the default (i.e. in /usr/bin), and leave Studio Express to those that need the new features/want to experiment. Solaris has a reputation to loose for its stability, after all. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Raj.Prakash@sun.com Tue Jan 13 13:50:33 2009 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 n0DLoW5d012940 for ; Tue, 13 Jan 2009 13:50:33 -0800 (PST) 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 n0DLoE5H001996 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 13 Jan 2009 21:50:31 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 <0KDF00B01JC2IG00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 13 Jan 2009 13:50:26 -0800 (PST) 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 <0KDF003NIJC2Q5E0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 13 Jan 2009 13:50:26 -0800 (PST) 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 n0DLoQpd017500 for ; Tue, 13 Jan 2009 13:50:26 -0800 (PST) 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 <0KDF00401IY23V00@fe-sfbay-10.sun.com> (original mail from Raj.Prakash@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 13 Jan 2009 13:50:26 -0800 (PST) Received: from [129.146.122.8] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF00C79JBWFR20@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 13 Jan 2009 13:50:20 -0800 (PST) Date: Tue, 13 Jan 2009 13:50:20 -0800 From: Raj Prakash Subject: LSARC/2008/776 and LSARC/2009/017 (GNU Developer and Sun Studio collections) Sender: Raj.Prakash@sun.com To: lsarc-ext@sun.com Cc: George Vasick , Douglas Walls , Chris Quenelle , David.Ford@sun.com Message-id: <496D0C9C.8080302@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 User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Content-Length: 503 Status: RO X-Status: $$$$ X-UID: 0000000014 This is in reference to the following two projects LSARC/2008/776 GNU Developer Collection LSARC/2009/017 Sun Studio C/C++/dbx Collection Based on the valuable feedback, the two projects have agreed not to co-locate their files under /usr/compilers. Following the precedence sited, they will place them in something like /usr/gcc and /usr/suncc. Therefore, I am canceling the timeouts for the two projects and will set new timeouts after updated proposals are submitted. Thank you, Raj. From David.Ford@sun.com Tue Jan 13 15:13:09 2009 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 n0DND7d0016235 for ; Tue, 13 Jan 2009 15:13:08 -0800 (PST) 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 n0DND6WP009163 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 Jan 2009 07:13:07 +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 <0KDF00M03N5CNZ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 15:12:48 -0800 (PST) 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 <0KDF00FBYN5BZ0F0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 15:12:48 -0800 (PST) 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 n0DNClp0028476 for ; Tue, 13 Jan 2009 15:12:47 -0800 (PST) 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 <0KDF00K01MWWSC00@fe-sfbay-10.sun.com> (original mail from David.Ford@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 15:12:47 -0800 (PST) Received: from [129.146.86.88] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF00MQTN5BNLB0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 15:12:47 -0800 (PST) Date: Tue, 13 Jan 2009 15:12:47 -0800 From: David.Ford@sun.com Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> Sender: David.Ford@sun.com To: Rainer Orth Cc: Chris.Quenelle@sun.com, Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com Message-id: <496D1FEF.10108@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Content-Length: 604 Status: RO X-Status: $$$$ X-UID: 0000000015 On 01/13/09 07:03, Rainer Orth wrote: > Chris, > >> You raise some good points. >> What would you recommend to resolve your issues? >> /usr/suncc/*? > > in principle, yes, though I'm a bit confused about the suncc moniker. It > reminds me of Sun C Compiler, which doesn't seem to fit given that all of > C, C++ and Fortran are included. Fortran is not included. We propose to install a C/C++/dbx subset of Sun Studio in /usr. Sun Studio remains a separate unbundled product which can be installed as usual on Solaris or Linux, and which does have Fortran, and an IDE, and Perflib, etc. -- Dave F From Douglas.Walls@sun.com Tue Jan 13 16:28:17 2009 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 n0E0SGTO004477 for ; Tue, 13 Jan 2009 16:28:16 -0800 (PST) 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 n0E0SBTF001721 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 Jan 2009 00:28:15 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 <0KDF00L01QN3CM00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 16:28:15 -0800 (PST) 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 <0KDF00C4DQN21GA0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 16:28:14 -0800 (PST) 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 n0E0SEFS006124 for ; Tue, 13 Jan 2009 16:28:14 -0800 (PST) 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 <0KDF00B01QKM2D00@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 16:28:14 -0800 (PST) Received: from [129.146.86.116] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF001HWQN1DI30@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 13 Jan 2009 16:28:14 -0800 (PST) Date: Tue, 13 Jan 2009 16:23:26 -0800 From: Douglas Walls Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> Sender: Douglas.Walls@sun.com To: Rainer Orth Cc: Chris.Quenelle@sun.com, Raj Prakash , LSARC-ext@sun.com, David.Ford@sun.com Message-id: <496D307E.4050006@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Content-Length: 5036 Status: RO X-Status: $$$$ X-UID: 0000000016 Rainer, I misnamed this ARC case, and it appears to be causing a significant amount of confusion. This case should have been named Bundled Compiler Collection. The intent is to bundle Sun compilers into /usr. We are not bundling all of Sun Studio. This collection only contains C and C++ compilers along with their debugger, dbx. Given the design of the Sun compilers, we can not just install them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components in /usr/bin and /usr/share/man. So our original intent was to install the bundled compiler collection components into /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'compilers' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There would not be multiple versions, there would always and only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/sunstudio13, /opt/sunstudio14, etc. As it happens there was some amount of miscommunication and the LSARC/2008/776 GNU Developer Collection case was submitted installing into /usr/compilers/gcc432. So we adapted our misnamed case (LSARC/2009/017) by choosing to install into /usr/compilers/suncc2008.11. As our ARC case sponsor has noted, we will update our proposal and start anew. Regards, Douglas Rainer Orth wrote: > Chris, > >> You raise some good points. >> What would you recommend to resolve your issues? >> /usr/suncc/*? > > in principle, yes, though I'm a bit confused about the suncc moniker. It > reminds me of Sun C Compiler, which doesn't seem to fit given that all of > C, C++ and Fortran are included. I suppose it is meant as Sun Compiler > Collection, just like GCC was reinterpreted from GNU C Compiler to GNU > Compiler Collection? > > I'd have chosen /usr/studio/* instead, but given Sun Marketing's history of > randomly renaming products at least every other year (consider WorkShop, > Forte, Studio ...), this may be unwise. > >> How should we anticipate the future possible parallel >> inclusion of SS12+patches? Perhaps /usr/sunccx for >> the latest express and /usr/suncc for the latest stable/FCS release? > > I'd just use /usr/suncc/12.0 and /usr/suncc/13.0 (or omit the .0 part if > there are no and never will be minor releases), just as is done for all > other cases of parallel installations (like mysql, postgres, ...). This is > a model familiar to users. One might want to think about 13.0ea or some > such while Studio 13 isn't yet released to make users aware that they are > using an alpha/beta product, but that's about it. I don't think a solution > that only supports the latest stable version and express is enough. Many > sites may need to have more different version installed in parallel, and > using a different directory in /usr for each such version seems to > unnecessarily clutter that directory. > >> I agree that the more normal convention for projects is /usr/XXXX. >> Do you think the creation of /usr/compilers is so confusing >> or different that the project should be forcibly prevented from >> using that path? (I'm trying to understand the scope of the issue) > > It's just different from a well-established convention, and if there are no > very good reasons to deviate here, I'd strongly suggest to stay with the > convention. Familiarity helps users, and so far I've seen no strong > argument suggesting why this different convention (/usr/compilers/ release>) is useful or necessary. > >> Note: The rationale for multiple versions of gcc is >> very different than for Sun Studio compilers. I'm not >> trying to imply anything here about the GCC case. > > Even in the Studio case, it is useful to keep more than two versions > around. At least our site currently does. > >> Also Note: >> The case doesn't discuss how a parallel delivery of two >> compilers (EG SS12 and SSX) will be handled with regards >> to symlinks and default paths. That is still TBD at this point. >> The goal is for the symlinks to cause the "right thing" to >> happen by default for almost all Solaris developers. >> IE: You just automatically get a compiler that works. >> The only concession we've made is to put the symlinks into >> a separate package, but that's not really a complete story yet. > > Maybe something can be learned from the JDK deliveries here? I don't know > the full story, but know that the JDK 1.5 and 1.6 packages somehow dealt > with setting a default. > > In my opinion, the only sane solution is to have the latest stable version > as the default (i.e. in /usr/bin), and leave Studio Express to those that > need the new features/want to experiment. Solaris has a reputation to > loose for its stability, after all. > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Faculty of Technology, Bielefeld University From daleg@elemental.org Wed Jan 14 10:18:22 2009 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 n0EIILbc006854 for ; Wed, 14 Jan 2009 10:18:22 -0800 (PST) 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 n0EIIDts024957; Wed, 14 Jan 2009 18:18:17 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 <0KDH0042746GLY00@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 11:18:16 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH009U146DPOE0@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 11:18:14 -0700 (MST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0EI8jcf024700; Wed, 14 Jan 2009 18:18:13 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-2448396; Wed, 14 Jan 2009 18:18:13 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-62723607; Wed, 14 Jan 2009 18:18:13 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1i.sun.com with ESMTP id BT-MMP-26740007; Wed, 14 Jan 2009 18:18:12 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-148-rvo.net.salesforce.com [204.14.233.148]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0EIIC08013147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2009 13:18:12 -0500 (EST) Date: Wed, 14 Jan 2009 13:18:11 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496D307E.4050006@sun.com> To: Douglas Walls Cc: Rainer Orth , David.Ford@sun.com, Chris.Quenelle@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Wed, 14 Jan 2009 13:18:12 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.118sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> Content-Length: 1912 Status: RO X-Status: $$$$ X-UID: 0000000017 On Jan 13, 2009, at 7:23 PM, Douglas Walls wrote: > We chose the name 'compilers' to intentionally > indicate these are the default|builtin|preferred|bundled compilers. > There would not be multiple versions, there would always and only be > one set of bundled compilers. Versions of the unbundled Sun Studio > will continue to install into /opt, i.e. /opt/sunstudio13, > /opt/sunstudio14, etc. Understood, but I can imagine that this would lead to some confusion in a few areas in that your result might look and smell like a bona fide Sun Studio installation, but it's not (missing Fortran, Performance Analyzer, etc). This will cause users to have to resort to knowing when or if they have to install the full, unbundled Sun Stuido environment... which as you point out installs into it's own place under /opt, per tradition. Now the user has two "same but different" compiler environments under two different paths. I believe this moves us away from the "it's there and works without any headaches" pseudo-goal I think we all desire. One of complaints I hear a lot from new adopters are the $PATH acrobatics one has to go through in certain situations because of stuff like this. One existing thing to perhaps take a cue from is how the Java JRE is bundled. These use /usr/jdk (analogous here to /usr/compilers) and each JRE version gets its own sub-directory in there. Within /usr/jdk there is a "latest" symlink that points to the JRE that is the system default. /usr/bin/java and friends are then just symlinks to /usr/jdk/ latest/bin/java (and friends.) In the end, this allows for multiple versions of the JRE to be installed, and they're all in one place instead of spread about the system. So perhaps this question has already been answered, but why couldn't Sun Studio take a similar approach, but with a full installation (C/C+ +/Fortran et al) ? /dale From ro@techfak.uni-bielefeld.de Wed Jan 14 10:24:43 2009 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 n0EIOg6H006914 for ; Wed, 14 Jan 2009 10:24:43 -0800 (PST) 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 n0EIOT4H029178; Thu, 15 Jan 2009 02:24:38 +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 <0KDH00J034GYY200@nwk-avmta-2.sfbay.sun.com>; Wed, 14 Jan 2009 10:24:34 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH00A114GY5AE0@nwk-avmta-2.sfbay.sun.com>; Wed, 14 Jan 2009 10:24:34 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0EIH4Cu016053; Wed, 14 Jan 2009 18:24:34 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay22i.sun.com with ESMTP id BT-MMP-2909332; Wed, 14 Jan 2009 18:24:33 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-57951754; Wed, 14 Jan 2009 18:24:33 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay21i.sun.com with ESMTP id BT-MMP-8511609; Wed, 14 Jan 2009 18:24:33 +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 7B5F9482ED; Wed, 14 Jan 2009 19:24:32 +0100 (CET) Date: Wed, 14 Jan 2009 19:24:31 +0100 (MET) From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496D1FEF.10108@Sun.COM> To: David.Ford@sun.com Cc: Chris.Quenelle@sun.com, Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com Message-id: <18798.11743.214197.293522@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.145sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D1FEF.10108@Sun.COM> Content-Length: 1276 Status: RO X-Status: $$$$ X-UID: 0000000018 David, > > in principle, yes, though I'm a bit confused about the suncc moniker. It > > reminds me of Sun C Compiler, which doesn't seem to fit given that all of > > C, C++ and Fortran are included. > > Fortran is not included. We propose to install a C/C++/dbx subset of Sun Studio > in /usr. Sun Studio remains a separate unbundled product which can be installed > as usual on Solaris or Linux, and which does have Fortran, and an IDE, and Perflib, > etc. I fear that's unfortunate, at least for the set of languages bundled (I don't care too much about the IDE, but similar arguments hold). Besides, it creates an unnecessary disparity between GCC (which currently already includes g77/gfortran and will hopefully include more languages in the future) and the Studio compilers: everyone using non-C/C++ languages will be forced to have a second compiler installation with Fortran included just to get the Fortran compiler. I'd feel like a second-class citizen in those circumstances. To be honest, I don't see what limiting the set of languages and tools delivered buys the team in simplicity and especially the users. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From ro@techfak.uni-bielefeld.de Wed Jan 14 10:28:38 2009 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 n0EISbeV007112 for ; Wed, 14 Jan 2009 10:28:38 -0800 (PST) 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 n0EISanV015777; Wed, 14 Jan 2009 10:28:37 -0800 (PST) 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 <0KDH00E0H4NO2300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 14 Jan 2009 10:28:36 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH00KJK4NOODB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 14 Jan 2009 10:28:36 -0800 (PST) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0EIPhrh028426; Wed, 14 Jan 2009 18:28:35 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay24i.sun.com with ESMTP id BT-MMP-2909591; Wed, 14 Jan 2009 18:28:35 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-57958014; Wed, 14 Jan 2009 18:28:34 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay22i.sun.com with ESMTP id BT-MMP-8522973; Wed, 14 Jan 2009 18:28:34 +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 CE26B482ED; Wed, 14 Jan 2009 19:28:33 +0100 (CET) Date: Wed, 14 Jan 2009 19:28:32 +0100 (MET) From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496D307E.4050006@sun.com> To: Douglas Walls Cc: Chris.Quenelle@sun.com, Raj Prakash , LSARC-ext@sun.com, David.Ford@sun.com Message-id: <18798.11984.482739.246623@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.071sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> Content-Length: 1863 Status: RO X-Status: $$$$ X-UID: 0000000019 Douglas, > I misnamed this ARC case, and it appears to be causing a significant > amount of confusion. This case should have been named Bundled Compiler > Collection. The intent is to bundle Sun compilers into /usr. We are > not bundling all of Sun Studio. This collection only contains C > and C++ compilers along with their debugger, dbx. ok, but where's the benefit of doing so, both for the users/developers and the DevPro team? > Given the design of the Sun compilers, we can not just install them > into /usr/bin, /usr/lib, etc. without significant redesign. We need a > location into which to install the compiler components, with symlinks > to those components in /usr/bin and /usr/share/man. So our original > intent was to install the bundled compiler collection components into > /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and > /usr/share/man. We chose the name 'compilers' to intentionally > indicate these are the default|builtin|preferred|bundled compilers. > There would not be multiple versions, there would always and only be > one set of bundled compilers. Versions of the unbundled Sun Studio > will continue to install into /opt, i.e. /opt/sunstudio13, > /opt/sunstudio14, etc. There's no problem here, on the contrary I consider it a benefit that/if the installation supports the installation of several different versions in parallel, only designating one as the default (this should be the latest stable release in my opinion), but giving developers the opportunity to easily use either an earlier release should the need to for some reason, or test Studio Express if they desire. The architecture seems to be in place to handle all this, so why not go the whole way? Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From carlsonj@phorcys.east.sun.com Wed Jan 14 10:41:54 2009 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 n0EIfsOr007277 for ; Wed, 14 Jan 2009 10:41:54 -0800 (PST) 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 n0EIfp50026075; Wed, 14 Jan 2009 10:41:53 -0800 (PST) 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 <0KDH0060959TXY00@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 11:41:53 -0700 (MST) 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 <0KDH005PR59SN720@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 11:41:52 -0700 (MST) 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 n0EIUOCC003791; Wed, 14 Jan 2009 13:30:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0EIULQd003784; Wed, 14 Jan 2009 13:30:21 -0500 (EST) Date: Wed, 14 Jan 2009 13:30:21 -0500 From: James Carlson Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> To: Dale Ghent Cc: Douglas Walls , LSARC-ext@sun.com, Raj Prakash , David.Ford@sun.com, Chris.Quenelle@sun.com Message-id: <18798.12093.413445.295846@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> Content-Length: 1091 Status: RO X-Status: $$$$ X-UID: 0000000020 Dale Ghent writes: > In the end, this allows for multiple versions of the JRE to be > installed, and they're all in one place instead of spread about the > system. It also caused a lot of troubles with zones, as /usr isn't writable in "sparse root" non-global zones. The problems included at least: - Inability for non-global zone administrators to choose which version of Java to make the default; the global zone administrator chooses, and all others get read-only copies. - Failures in packaging and patching postinstall scripts (mostly related to the above Zones issues). - Surprises for users, such as seeing that installing an old Java just for compatibility suddenly switched the default (because the rule is "last to install wins"). I agree that it can probably work, but the way it was done for Java wasn't without warts. -- 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 daleg@elemental.org Wed Jan 14 11:30:35 2009 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 n0EJUYr3008523 for ; Wed, 14 Jan 2009 11:30:34 -0800 (PST) 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 n0EJUVMQ020257; Wed, 14 Jan 2009 11:30:32 -0800 (PST) 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 <0KDH0020L7IWF600@nwk-avmta-1.sfbay.Sun.COM>; Wed, 14 Jan 2009 11:30:32 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH00KH17IVO9E0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 14 Jan 2009 11:30:31 -0800 (PST) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0EJMH8C015787; Wed, 14 Jan 2009 19:30:31 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay21i.sun.com with ESMTP id BT-MMP-2913706; Wed, 14 Jan 2009 19:30:31 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-58066630; Wed, 14 Jan 2009 19:30:30 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay24i.sun.com with ESMTP id BT-MMP-8593795; Wed, 14 Jan 2009 19:30:30 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-148-rvo.net.salesforce.com [204.14.233.148]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0EJUUdk017924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2009 14:30:30 -0500 (EST) Date: Wed, 14 Jan 2009 14:30:29 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <18798.12093.413445.295846@gargle.gargle.HOWL> To: James Carlson Cc: Douglas Walls , LSARC-ext@sun.com, Raj Prakash , David.Ford@sun.com, Chris.Quenelle@sun.com Message-id: <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Wed, 14 Jan 2009 14:30:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=-0.7/5.0, scanned in 0.139sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> <18798.12093.413445.295846@gargle.gargle.HOWL> Content-Length: 1719 Status: RO X-Status: $$$$ X-UID: 0000000021 On Jan 14, 2009, at 1:30 PM, James Carlson wrote: > Dale Ghent writes: >> In the end, this allows for multiple versions of the JRE to be >> installed, and they're all in one place instead of spread about the >> system. > > It also caused a lot of troubles with zones, as /usr isn't writable in > "sparse root" non-global zones. The problems included at least: Good points. I keep forgetting about the conditions sparse zones introduce. Well, hopefully I won't be departing too far from the scope of this case with the follow suggestion, and I bet that it will probably cause some people to cringe and scrunch their nose in utter disgust. The suggestion is to do someone a la /usr/jdk for the sunstudio compilers, but deliver shell scripts instead of symlinks to /usr/bin. /usr/bin/cc for example would be a shell script (or C program, whatever) that looks for a particular environment variable, eg; $SUN_STUDIO_VER. This variable could be set to "10" or "11" or "12" or a specific directory under /usr/compilers. When executed, /usr/bin/cc would look at the contents of this environment variable and use it to determine which "real" cc of the Sun Studio installations in /usr/compilers to utilize. If this variable is absent, a default is chosen. If it set to an ambiguous value, a suitable error is given. This would grant a user in both global and sparse zones the ability to set a desired Sun Studio version to be default (either in their own environment, or in the global shell rc files). As for the default that should be chosen in absence of the environment variable, I guess it could determine which is that latest Sun Studio that is installed and use that. /dale From Douglas.Walls@sun.com Wed Jan 14 13:45:23 2009 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 n0ELjMF2029617 for ; Wed, 14 Jan 2009 13:45:22 -0800 (PST) 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 n0ELjIFF001968 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 Jan 2009 21:45:21 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 <0KDH00107DRKPB00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 14:45:20 -0700 (MST) 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 <0KDH00FAIDRHHP70@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 14:45:20 -0700 (MST) 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 n0ELjHA4017503 for ; Wed, 14 Jan 2009 13:45:17 -0800 (PST) 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 <0KDH00501DKZMY00@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:45:17 -0800 (PST) Received: from [129.146.86.116] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH005QTDRFQ580@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:45:15 -0800 (PST) Date: Wed, 14 Jan 2009 13:40:27 -0800 From: Douglas Walls Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> Sender: Douglas.Walls@sun.com To: Rainer Orth Cc: Chris.Quenelle@sun.com, Raj Prakash , LSARC-ext@sun.com, David.Ford@sun.com Message-id: <496E5BCB.4060409@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Content-Length: 3060 Status: RO X-Status: $$$$ X-UID: 0000000022 Rainer Orth wrote: > Douglas, > >> I misnamed this ARC case, and it appears to be causing a significant >> amount of confusion. This case should have been named Bundled Compiler >> Collection. The intent is to bundle Sun compilers into /usr. We are >> not bundling all of Sun Studio. This collection only contains C >> and C++ compilers along with their debugger, dbx. > > ok, but where's the benefit of doing so, both for the users/developers and > the DevPro team? The next version of the ARC case will say this: 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. > >> Given the design of the Sun compilers, we can not just install them >> into /usr/bin, /usr/lib, etc. without significant redesign. We need a >> location into which to install the compiler components, with symlinks >> to those components in /usr/bin and /usr/share/man. So our original >> intent was to install the bundled compiler collection components into >> /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and >> /usr/share/man. We chose the name 'compilers' to intentionally >> indicate these are the default|builtin|preferred|bundled compilers. >> There would not be multiple versions, there would always and only be >> one set of bundled compilers. Versions of the unbundled Sun Studio >> will continue to install into /opt, i.e. /opt/sunstudio13, >> /opt/sunstudio14, etc. > > There's no problem here, on the contrary I consider it a benefit that/if > the installation supports the installation of several different versions in > parallel, only designating one as the default (this should be the latest > stable release in my opinion), but giving developers the opportunity to > easily use either an earlier release should the need to for some reason, or > test Studio Express if they desire. The architecture seems to be in place > to handle all this, so why not go the whole way? The unbundled Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these override the links of this bundled compiler as it does the links of any other installed versions of Sun Studio. We believe this does give developers the opportunity to easily use any version of Sun Studio. As to why not bundle all of Sun Studio so it is available in any distribution of Solaris, that is a marketing decision or opportunity for which I do not have an explanation. > > Rainer > > ----------------------------------------------------------------------------- > Rainer Orth, Faculty of Technology, Bielefeld University From Douglas.Walls@Sun.COM Wed Jan 14 13:55:04 2009 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 n0ELt3di000784 for ; Wed, 14 Jan 2009 13:55:04 -0800 (PST) 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 n0ELt2iZ016554 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 05:55:02 +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 <0KDH00801E7PQP00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:55:02 -0800 (PST) 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 <0KDH0088GE7PKM00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:55:01 -0800 (PST) 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 n0ELt1ku018782 for ; Wed, 14 Jan 2009 13:55:01 -0800 (PST) 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 <0KDH00H01DMW4900@fe-sfbay-09.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:55:01 -0800 (PST) Received: from [129.146.86.116] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH009ATE7OCZA0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 13:55:00 -0800 (PST) Date: Wed, 14 Jan 2009 13:50:13 -0800 From: Douglas Walls Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496E5BCB.4060409@sun.com> Sender: Douglas.Walls@Sun.COM To: Raj Prakash , LSARC-ext@Sun.COM Cc: Chris.Quenelle@Sun.COM, David.Ford@Sun.COM Message-id: <496E5E15.4090400@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081010) Content-Length: 10901 Status: RO X-Status: $$$$ X-UID: 0000000023 Raj, Here is the updated case for [LSARC/2009/017 Bundled Compiler Collection], please set the new timeout. Thanks, Douglas ============================================ Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bundled Compiler Collection 1.2. Name of Document Author/Supplier: Douglas Walls (Douglas.Walls@Sun.COM> 1.3. Date of This Document: 1/14/2009 1.3.1. Date this project was conceived: 10/2008 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com 1.4.4. The name of your business unit: CODE (C/C++ Compilers, Optimization, and Debugger) 1.5. Email Aliases: 1.5.1. Responsible Manager: Kurt Goebel 1.5.2. Responsible Engineer: Douglas Walls 1.5.3. Marketing Manager: Ikroop Dhillon 1.5.4. Interest List: tools-compilers@opensolaris.org 2. Project Summary 2.1. Project Description: The project will deliver C, C++ and dbx from the current Sun Studio Express release into Nevada through the devpro consolidation. The intent is to bundle Sun compilers into /usr. We are not bundling all of Sun Studio. This collection only contains C and C++ compilers along with their debugger, dbx. 2.2. Risks and Assumptions: No known risks or assumptions at this time. 3. Business Summary 3.1. Problem Area: Default compilers on OpenSolaris Default compilers bundled with all distribution of Solaris 3.2. Market/Requester: OpenSolaris 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. 3.4. Competitive Analysis: Main competitors: Platforms & Tool Suite Offerings - Red Hat: GCC (bundled and supported) - Windows: Microsoft Visual Studio (unbundled) - MacOS: Xcode (gcc-based), LLVM effort 3.5. Opportunity Window/Exposure: 04/2009 to coincide with the next release of OpenSolaris. 3.6. How will you know when you are done?: The project will be on-going always tracking the latest express release of Sun Studio C, C++ and dbx 4. Technical Description: 4.1. Details: - The design of the Sun compilers precludes just installing them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components installed in /usr/bin and /usr/share/man. The delivery will install the bundled compiler collection components into /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'compilers' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There will not be multiple versions, there will only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/sunstudio13, /opt/sunstudio14, etc.. Note Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these would then override the links of this bundled compiler as it does previously installed versions of Sun Studio. - The first delivery will be the C, C++ and dbx components of Sun Studio Express 2008.11 release.. - Links will be created in /usr/bin, e.g. /usr/bin/cc, /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate binaries /usr/compilers. - Links will be created in /usr/man, e.g. /usr/man/man1/cc, /usr/man/man1/CC, /usr/man/man1/dbx, etc., to point to man pages in /usr/compilers/man/man1. 4.2. Bug/RFE Number(s): Not applicable. 4.3. In Scope: - C, C++ compilers and dbx 4.4. Out of Scope: 4.5. Interfaces: The following soft links will be created in /usr/bin to point to the appropriate binaries of /usr/compilers/suncc2008.11/bin. We may choose to omit some of these links which do not contribute to minimizing compiler-related porting efforts to encourage FOSS inclussion into OpenSolaris repositories. /usr/bin/bcheck /usr/bin/c++filt /usr/bin/c89 /usr/bin/c99 /usr/bin/cb /usr/bin/cc /usr/bin/CC /usr/bin/CCadmin /usr/bin/cflow /usr/bin/cscope /usr/bin/ctcr /usr/bin/ctrace /usr/bin/cxref /usr/bin/dbx /usr/bin/dem /usr/bin/dumpstabs /usr/bin/dwarfdump /usr/bin/fbe /usr/bin/fpversion /usr/bin/indent /usr/bin/lint /usr/bin/rtc_patch_area /usr/bin/sunc89 /usr/bin/sunc99 /usr/bin/suncc /usr/bin/sunCC /usr/bin/tcov 4.6. Doc Impact: Links will be created in /usr/share/man/* for the following man pages: /usr/compilers/man1/CC.1 /usr/compilers/man1/CCadmin.1 /usr/compilers/man1/bcheck.1 /usr/compilers/man1/binopt.1 /usr/compilers/man1/c++filt.1 /usr/compilers/man1/c89.1 /usr/compilers/man1/c99.1 /usr/compilers/man1/cb.1 /usr/compilers/man1/cc.1 /usr/compilers/man1/cflow.1 /usr/compilers/man1/cscope.1 /usr/compilers/man1/ctrace.1 /usr/compilers/man1/cxref.1 /usr/compilers/man1/dbx.1 /usr/compilers/man1/dem.1 /usr/compilers/man1/fbe.1 /usr/compilers/man1/fpversion.1 /usr/compilers/man1/indent.1 /usr/compilers/man1/inline.1 /usr/compilers/man1/lint.1 /usr/compilers/man1/rtc_patch_area.1 /usr/compilers/man1/ss_attach.1 /usr/compilers/man3/gcFixPrematureFrees.3 /usr/compilers/man3/gcInitialize.3 /usr/compilers/man3cc4/cartpol.3 /usr/compilers/man3cc4/cplx.intro.3 /usr/compilers/man3cc4/cplxerr.3 /usr/compilers/man3cc4/cplxexp.3 /usr/compilers/man3cc4/cplxops.3 /usr/compilers/man3cc4/cplxtrig.3 /usr/compilers/man3cc4/filebuf.3 /usr/compilers/man3cc4/fstream.3 /usr/compilers/man3cc4/interrupt.3 /usr/compilers/man3cc4/ios.3 /usr/compilers/man3cc4/ios.intro.3 /usr/compilers/man3cc4/istream.3 /usr/compilers/man3cc4/manip.3 /usr/compilers/man3cc4/ostream.3 /usr/compilers/man3cc4/queue.3 /usr/compilers/man3cc4/sbufprot.3 /usr/compilers/man3cc4/sbufpub.3 /usr/compilers/man3cc4/ssbuf.3 /usr/compilers/man3cc4/stdiobuf.3 /usr/compilers/man3cc4/stream_MT.3 /usr/compilers/man3cc4/stream_locker.3 /usr/compilers/man3cc4/strstream.3 /usr/compilers/man3cc4/task.3 /usr/compilers/man3cc4/task.intro.3 /usr/compilers/man3cc4/tasksim.3 /usr/compilers/man3x/_rtc_check_free.3x /usr/compilers/man3x/_rtc_check_malloc.3x /usr/compilers/man3x/_rtc_check_malloc_result.3x /usr/compilers/man3x/_rtc_check_realloc.3x /usr/compilers/man3x/_rtc_check_realloc_result.3x /usr/compilers/man3x/_rtc_hide_region.3x /usr/compilers/man3x/_rtc_off.3x /usr/compilers/man3x/_rtc_on.3x /usr/compilers/man3x/_rtc_record_free.3x /usr/compilers/man3x/_rtc_record_malloc.3x /usr/compilers/man3x/_rtc_record_realloc.3x /usr/compilers/man3x/_rtc_report_error.3x /usr/compilers/man3x/rtc_api.3x /usr/compilers/man4/dbxrc.4 4.7. Admin/Config Impact: No change. 4.8. HA Impact: No change. 4.9. I18N/L10N Impact: Sun Studio C/C++/dbx Collection is I18N L10N to be coordinated with Nevada L10N 4.10. Packaging & Delivery: Name Stability Notes ==== ========= ===== SUNWcompilers Committed Sun Studio C/C++/dbx core cluster SUNWcompilerlinks Committed Sun Studio C/C++/dbx /usr/bin /usr/man links 4.11. Security Impact: No impact. 4.12. Dependencies: SUNWlibC C++ stdlibs SUNWlibms limtsk, etc. SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWesu Extended System Utilities SUNWhea Header files SUNWkvm Core Architecture, (Kvm) SUNWtoo Programming Tools 5. Reference Documents: LSARC/2008/776 GNU Developer Collection LSARC/2006/280 Tools DVD for S10u2 PSARC/2007/074 /usr/gnu Established precedent of having program visible by multiple names. 6. Resources and Schedule: 6.1. Projected Availability: April 2009 to coincide with OpenSolaris 2009.04 6.2. Cost of Effort: .5 developers. 6.3. Cost of Capital Resources: No additional capital resources were required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Devpro 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: Build 108 02/09/2009. 6.4.8. Target Code Design Review Date: Completed 6.4.9. Update approval addition: - SPDE PAC scheduling in progress - Solaris PAC scheduling in progress 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Not applicable. 7. Prototype Availability: 7.1. Prototype Availability: Not applicable. 7.2. Prototype Cost: Not Applicable. From daleg@elemental.org Wed Jan 14 13:57:36 2009 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 n0ELvavv000922 for ; Wed, 14 Jan 2009 13:57:36 -0800 (PST) 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 n0ELvXdB000111; Wed, 14 Jan 2009 14:57:34 -0700 (MST) 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 <0KDH00805EBXV300@nwk-avmta-2.sfbay.sun.com>; Wed, 14 Jan 2009 13:57:33 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH008LKEBXKM00@nwk-avmta-2.sfbay.sun.com>; Wed, 14 Jan 2009 13:57:33 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0ELpnut007697; Wed, 14 Jan 2009 21:57:32 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-319319; Wed, 14 Jan 2009 21:57:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-62961655; Wed, 14 Jan 2009 21:57:32 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1ib.sun.com with ESMTP id BT-MMP-24603531; Wed, 14 Jan 2009 21:57:32 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0ELvOSx027522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2009 16:57:32 -0500 (EST) Date: Wed, 14 Jan 2009 16:57:24 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496E5BCB.4060409@sun.com> To: Douglas Walls Cc: Rainer Orth , David.Ford@sun.com, Chris.Quenelle@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <82D56F18-CC2F-4546-9AAA-E669B5725AE7@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Wed, 14 Jan 2009 16:57:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.050sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> Content-Length: 618 Status: RO X-Status: $$$$ X-UID: 0000000024 On Jan 14, 2009, at 4:40 PM, Douglas Walls wrote: > As to why not bundle all of Sun Studio so it is available in any > distribution > of Solaris, that is a marketing decision or opportunity for which I > do not have > an explanation. Can someone ask why marketing believes that having a neutered installation of Sun Studio is supposed to be a good thing? Could they be persuaded to change this stance due to the impact of maneuvering around this affect the overall usability and presentation of OpenSolaris? It seems that "because marketing said so" is the local version of Godwin's Law here. /dale From Chris.Quenelle@Sun.COM Wed Jan 14 14:17:45 2009 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 n0EMHjIt001763 for ; Wed, 14 Jan 2009 14:17:45 -0800 (PST) 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 n0EMHjPL006636 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 Jan 2009 14:17:45 -0800 (PST) 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 <0KDH00401F9LXF00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 15:17:45 -0700 (MST) 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 <0KDH00FFEF9KHT90@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 15:17:44 -0700 (MST) 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 n0EMHiUp021717 for ; Wed, 14 Jan 2009 14:17:44 -0800 (PST) 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 <0KDH00501DKZMY00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 14:17:44 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH004EOF99S130@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 14:17:33 -0800 (PST) Date: Wed, 14 Jan 2009 14:14:51 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> Sender: Chris.Quenelle@Sun.COM To: Dale Ghent Cc: James Carlson , Douglas Walls , LSARC-ext@Sun.COM, Raj Prakash , David.Ford@Sun.COM Reply-to: Chris.Quenelle@Sun.COM Message-id: <496E63DB.90408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> <18798.12093.413445.295846@gargle.gargle.HOWL> <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 490 Status: RO X-Status: $$$$ X-UID: 0000000025 Dale Ghent wrote: > /usr/bin/cc for example would be a shell script (or C program, whatever) > that looks for a particular environment variable, eg; $SUN_STUDIO_VER. > This variable could be set to "10" or "11" or "12" or a specific > directory under /usr/compilers. What are the circumstances where it is possible/acceptable to set the SUN_STUDIO_VER environment variable, but it's not possible/acceptable to set the PATH variable to control where the compilers are coming from? --chris From daleg@elemental.org Wed Jan 14 14:34:22 2009 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 n0EMYMZ3002466 for ; Wed, 14 Jan 2009 14:34:22 -0800 (PST) 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 n0EMYKil018460; Wed, 14 Jan 2009 15:34:20 -0700 (MST) 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 <0KDH00609G18I200@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 15:34:20 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDH00FKCG17HK90@brm-avmta-1.central.sun.com>; Wed, 14 Jan 2009 15:34:19 -0700 (MST) 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 n0EMYJw0012528; Wed, 14 Jan 2009 22:34:19 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-2394705; Wed, 14 Jan 2009 22:34:19 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-62998704; Wed, 14 Jan 2009 22:34:18 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1i.sun.com with ESMTP id BT-MMP-26874605; Wed, 14 Jan 2009 22:34:18 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0EMYIur029670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2009 17:34:18 -0500 (EST) Date: Wed, 14 Jan 2009 17:34:18 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496E63DB.90408@Sun.COM> To: Chris.Quenelle@sun.com Cc: James Carlson , Douglas Walls , LSARC-ext@sun.com, Raj Prakash , David.Ford@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Wed, 14 Jan 2009 17:34:18 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.060sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> <18798.12093.413445.295846@gargle.gargle.HOWL> <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> <496E63DB.90408@Sun.COM> Content-Length: 1428 Status: RO X-Status: $$$$ X-UID: 0000000026 On Jan 14, 2009, at 5:14 PM, Chris Quenelle wrote: > Dale Ghent wrote: >> /usr/bin/cc for example would be a shell script (or C program, >> whatever) >> that looks for a particular environment variable, eg; >> $SUN_STUDIO_VER. >> This variable could be set to "10" or "11" or "12" or a specific >> directory under /usr/compilers. > > What are the circumstances where it is possible/acceptable to set > the SUN_STUDIO_VER environment variable, but it's not possible/ > acceptable > to set the PATH variable to control where the compilers are coming > from? The circumstances where it would be useful, you mean? Some things come to mind: 1) Easily switching between Sun Studio versions without having to rearrange $PATH 2) Some software being built from source could easily specify a specific version for it to be compiled with. 3) The need for a sysadmin to set the system-wide default for developers, while individual Sun Studio users are still free to set their own. The suggestion does seem sort of voodoo-ish, but aims to ease usability in terms of setting a default version of Sun Studio to use... and do this without jumping through hoops with $PATH or fooling around with symlinks somewhere under /usr to accomplish the same. The latter would impinge on sparse zones as Mr. Carlson pointed out earlier. It's just an idea for the issue of choosing compilers, use it (or not!) FWIW :) /dale From Chris.Quenelle@sun.com Wed Jan 14 15:09:50 2009 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 n0EN9ofd004057 for ; Wed, 14 Jan 2009 15:09:50 -0800 (PST) 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 n0EN9e1l026766 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 Jan 2009 15:09:50 -0800 (PST) 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 <0KDH00A0FHOB3600@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 16:09:47 -0700 (MST) 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 <0KDH00F1FHO8HOE0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 16:09:45 -0700 (MST) 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 n0EN9iu4014705 for ; Wed, 14 Jan 2009 15:09:44 -0800 (PST) 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 <0KDH00J01HKOYM00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 15:09:44 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH00AIIHO2XIA0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 Jan 2009 15:09:38 -0800 (PST) Date: Wed, 14 Jan 2009 15:06:56 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Sender: Chris.Quenelle@sun.com To: Dale Ghent Cc: James Carlson , Douglas Walls , LSARC-ext@sun.com, Raj Prakash , David.Ford@sun.com Reply-to: Chris.Quenelle@sun.com Message-id: <496E7010.7070507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> <18798.12093.413445.295846@gargle.gargle.HOWL> <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> <496E63DB.90408@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081203) Content-Length: 390 Status: RO X-Status: $$$$ X-UID: 0000000027 Dale Ghent wrote: > It's just an idea for the issue of choosing compilers, use it (or not!) > FWIW :) I'm always happy to get constructive advice, so thanks! In this case, my judgment of the cost/benefit trade off tells me it's not worth the added complication. I'd be happy to dig into the details with you offline. If you want to discuss it further, send me a separate email. --chris From Raj.Prakash@sun.com Wed Jan 14 15:13:03 2009 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 n0END3rw004177 for ; Wed, 14 Jan 2009 15:13:03 -0800 (PST) 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 n0ENCmr7036797 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 14 Jan 2009 16:13:03 -0700 (MST) 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 <0KDH00701HTR9E00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 15:13:03 -0800 (PST) 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 <0KDH003MDHTQJG10@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 15:13:02 -0800 (PST) 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 n0END2EH015059 for ; Wed, 14 Jan 2009 15:13:02 -0800 (PST) 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 <0KDH00J01HKOYM00@fe-sfbay-10.sun.com> (original mail from Raj.Prakash@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 15:13:02 -0800 (PST) Received: from [192.168.0.4] ([76.233.216.111]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH00AVHHTEXIB0@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 15:13:01 -0800 (PST) Date: Wed, 14 Jan 2009 15:12:34 -0800 From: Raj Prakash Subject: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] Sender: Raj.Prakash@sun.com To: LSARC-ext@sun.com Cc: Douglas.Walls@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <496E7162.5010107@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 User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Content-Length: 11089 Status: RO X-Status: $$$$ X-UID: 0000000028 Here is an updated proposal from Douglas. I am setting the new timeout to one week from now on 01/21/2009. Raj The case has been retitled, and additional text added, to make it clear that the project is to bundle the Sun C and C++ compilers and dbx into Nevada so to make them available as the default set of compilers for any distribution of Solaris. Their relationship to the unbundled compilers of Sun Studio and how the Sun Studio compilers can be installed to override the default compilers has been explained. ============================================ Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bundled Compiler Collection 1.2. Name of Document Author/Supplier: Douglas Walls (Douglas.Walls@Sun.COM> 1.3. Date of This Document: 1/14/2009 1.3.1. Date this project was conceived: 10/2008 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com 1.4.4. The name of your business unit: CODE (C/C++ Compilers, Optimization, and Debugger) 1.5. Email Aliases: 1.5.1. Responsible Manager: Kurt Goebel 1.5.2. Responsible Engineer: Douglas Walls 1.5.3. Marketing Manager: Ikroop Dhillon 1.5.4. Interest List: tools-compilers@opensolaris.org 2. Project Summary 2.1. Project Description: The project will deliver C, C++ and dbx from the current Sun Studio Express release into Nevada through the devpro consolidation. The intent is to bundle Sun compilers into /usr. We are not bundling all of Sun Studio. This collection only contains C and C++ compilers along with their debugger, dbx. 2.2. Risks and Assumptions: No known risks or assumptions at this time. 3. Business Summary 3.1. Problem Area: Default compilers on OpenSolaris Default compilers bundled with all distribution of Solaris 3.2. Market/Requester: OpenSolaris 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. 3.4. Competitive Analysis: Main competitors: Platforms & Tool Suite Offerings - Red Hat: GCC (bundled and supported) - Windows: Microsoft Visual Studio (unbundled) - MacOS: Xcode (gcc-based), LLVM effort 3.5. Opportunity Window/Exposure: 04/2009 to coincide with the next release of OpenSolaris. 3.6. How will you know when you are done?: The project will be on-going always tracking the latest express release of Sun Studio C, C++ and dbx 4. Technical Description: 4.1. Details: - The design of the Sun compilers precludes just installing them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components installed in /usr/bin and /usr/share/man. The delivery will install the bundled compiler collection components into /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'compilers' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There will not be multiple versions, there will only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/sunstudio13, /opt/sunstudio14, etc.. Note Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these would then override the links of this bundled compiler as it does previously installed versions of Sun Studio. - The first delivery will be the C, C++ and dbx components of Sun Studio Express 2008.11 release.. - Links will be created in /usr/bin, e.g. /usr/bin/cc, /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate binaries /usr/compilers. - Links will be created in /usr/man, e.g. /usr/man/man1/cc, /usr/man/man1/CC, /usr/man/man1/dbx, etc., to point to man pages in /usr/compilers/man/man1. 4.2. Bug/RFE Number(s): Not applicable. 4.3. In Scope: - C, C++ compilers and dbx 4.4. Out of Scope: 4.5. Interfaces: The following soft links will be created in /usr/bin to point to the appropriate binaries of /usr/compilers/suncc2008.11/bin. We may choose to omit some of these links which do not contribute to minimizing compiler-related porting efforts to encourage FOSS inclussion into OpenSolaris repositories. /usr/bin/bcheck /usr/bin/c++filt /usr/bin/c89 /usr/bin/c99 /usr/bin/cb /usr/bin/cc /usr/bin/CC /usr/bin/CCadmin /usr/bin/cflow /usr/bin/cscope /usr/bin/ctcr /usr/bin/ctrace /usr/bin/cxref /usr/bin/dbx /usr/bin/dem /usr/bin/dumpstabs /usr/bin/dwarfdump /usr/bin/fbe /usr/bin/fpversion /usr/bin/indent /usr/bin/lint /usr/bin/rtc_patch_area /usr/bin/sunc89 /usr/bin/sunc99 /usr/bin/suncc /usr/bin/sunCC /usr/bin/tcov 4.6. Doc Impact: Links will be created in /usr/share/man/* for the following man pages: /usr/compilers/man1/CC.1 /usr/compilers/man1/CCadmin.1 /usr/compilers/man1/bcheck.1 /usr/compilers/man1/binopt.1 /usr/compilers/man1/c++filt.1 /usr/compilers/man1/c89.1 /usr/compilers/man1/c99.1 /usr/compilers/man1/cb.1 /usr/compilers/man1/cc.1 /usr/compilers/man1/cflow.1 /usr/compilers/man1/cscope.1 /usr/compilers/man1/ctrace.1 /usr/compilers/man1/cxref.1 /usr/compilers/man1/dbx.1 /usr/compilers/man1/dem.1 /usr/compilers/man1/fbe.1 /usr/compilers/man1/fpversion.1 /usr/compilers/man1/indent.1 /usr/compilers/man1/inline.1 /usr/compilers/man1/lint.1 /usr/compilers/man1/rtc_patch_area.1 /usr/compilers/man1/ss_attach.1 /usr/compilers/man3/gcFixPrematureFrees.3 /usr/compilers/man3/gcInitialize.3 /usr/compilers/man3cc4/cartpol.3 /usr/compilers/man3cc4/cplx.intro.3 /usr/compilers/man3cc4/cplxerr.3 /usr/compilers/man3cc4/cplxexp.3 /usr/compilers/man3cc4/cplxops.3 /usr/compilers/man3cc4/cplxtrig.3 /usr/compilers/man3cc4/filebuf.3 /usr/compilers/man3cc4/fstream.3 /usr/compilers/man3cc4/interrupt.3 /usr/compilers/man3cc4/ios.3 /usr/compilers/man3cc4/ios.intro.3 /usr/compilers/man3cc4/istream.3 /usr/compilers/man3cc4/manip.3 /usr/compilers/man3cc4/ostream.3 /usr/compilers/man3cc4/queue.3 /usr/compilers/man3cc4/sbufprot.3 /usr/compilers/man3cc4/sbufpub.3 /usr/compilers/man3cc4/ssbuf.3 /usr/compilers/man3cc4/stdiobuf.3 /usr/compilers/man3cc4/stream_MT.3 /usr/compilers/man3cc4/stream_locker.3 /usr/compilers/man3cc4/strstream.3 /usr/compilers/man3cc4/task.3 /usr/compilers/man3cc4/task.intro.3 /usr/compilers/man3cc4/tasksim.3 /usr/compilers/man3x/_rtc_check_free.3x /usr/compilers/man3x/_rtc_check_malloc.3x /usr/compilers/man3x/_rtc_check_malloc_result.3x /usr/compilers/man3x/_rtc_check_realloc.3x /usr/compilers/man3x/_rtc_check_realloc_result.3x /usr/compilers/man3x/_rtc_hide_region.3x /usr/compilers/man3x/_rtc_off.3x /usr/compilers/man3x/_rtc_on.3x /usr/compilers/man3x/_rtc_record_free.3x /usr/compilers/man3x/_rtc_record_malloc.3x /usr/compilers/man3x/_rtc_record_realloc.3x /usr/compilers/man3x/_rtc_report_error.3x /usr/compilers/man3x/rtc_api.3x /usr/compilers/man4/dbxrc.4 4.7. Admin/Config Impact: No change. 4.8. HA Impact: No change. 4.9. I18N/L10N Impact: Sun Studio C/C++/dbx Collection is I18N L10N to be coordinated with Nevada L10N 4.10. Packaging & Delivery: Name Stability Notes ==== ========= ===== SUNWcompilers Committed Sun Studio C/C++/dbx core cluster SUNWcompilerlinks Committed Sun Studio C/C++/dbx /usr/bin /usr/man links 4.11. Security Impact: No impact. 4.12. Dependencies: SUNWlibC C++ stdlibs SUNWlibms limtsk, etc. SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWesu Extended System Utilities SUNWhea Header files SUNWkvm Core Architecture, (Kvm) SUNWtoo Programming Tools 5. Reference Documents: LSARC/2008/776 GNU Developer Collection LSARC/2006/280 Tools DVD for S10u2 PSARC/2007/074 /usr/gnu Established precedent of having program visible by multiple names. 6. Resources and Schedule: 6.1. Projected Availability: April 2009 to coincide with OpenSolaris 2009.04 6.2. Cost of Effort: .5 developers. 6.3. Cost of Capital Resources: No additional capital resources were required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Devpro 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: Build 108 02/09/2009. 6.4.8. Target Code Design Review Date: Completed 6.4.9. Update approval addition: - SPDE PAC scheduling in progress - Solaris PAC scheduling in progress 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Not applicable. 7. Prototype Availability: 7.1. Prototype Availability: Not applicable. 7.2. Prototype Cost: Not Applicable. From Raj.Prakash@sun.com Wed Jan 14 17:22:27 2009 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 n0F1MQx7026464 for ; Wed, 14 Jan 2009 17:22:27 -0800 (PST) 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 n0F1MIGw005986 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 15 Jan 2009 01:22:25 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 <0KDH0010BNTBIY00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 18:22:23 -0700 (MST) 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 <0KDH00L1GNTAQ610@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 18:22:22 -0700 (MST) 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 n0F1MMGP012065 for ; Wed, 14 Jan 2009 17:22:22 -0800 (PST) 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 <0KDH00601NNSFD00@fe-sfbay-09.sun.com> (original mail from Raj.Prakash@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 17:22:22 -0800 (PST) Received: from [129.150.16.146] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDH001EPNT9L5A0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 14 Jan 2009 17:22:21 -0800 (PST) Date: Wed, 14 Jan 2009 17:22:23 -0800 From: Raj Prakash Subject: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] (was: Sun Studio C/C++/dbx Collection) In-reply-to: <496E7162.5010107@sun.com> Sender: Raj.Prakash@sun.com To: lsarc-ext@sun.com Cc: douglas.walls@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <496E8FCF.2030502@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: <496E7162.5010107@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 11722 I just changed the subject line of the email to reflect the modified name of the project to avoid any confusion. Raj Prakash wrote: > Here is an updated proposal from Douglas. I am setting the new timeout > to one week from now on 01/21/2009. > > Raj > > The case has been retitled, and additional text added, to make it > clear that > the project is to bundle the Sun C and C++ compilers and dbx into > Nevada so > to make them available as the default set of compilers for any > distribution > of Solaris. Their relationship to the unbundled compilers of Sun > Studio and > how the Sun Studio compilers can be installed to override the default > compilers has been explained. > > ============================================ > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: Bundled Compiler Collection > > 1.2. Name of Document Author/Supplier: > Douglas Walls (Douglas.Walls@Sun.COM> > > 1.3. Date of This Document: 1/14/2009 > 1.3.1. Date this project was conceived: 10/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris > 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC > 1.4.2. The ARC(s) you expect to review your project: LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: > Kurt.Goebel@Sun.Com > 1.4.4. The name of your business unit: CODE (C/C++ Compilers, > Optimization, and Debugger) > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Kurt Goebel > 1.5.2. Responsible Engineer: Douglas Walls > 1.5.3. Marketing Manager: Ikroop Dhillon > 1.5.4. Interest List: tools-compilers@opensolaris.org > > 2. Project Summary > 2.1. Project Description: > > The project will deliver C, C++ and dbx from the current Sun > Studio Express release into Nevada through the devpro > consolidation. The intent is to bundle Sun compilers into > /usr. We are not bundling all of Sun Studio. This collection > only contains C and C++ compilers along with their debugger, > dbx. > > 2.2. Risks and Assumptions: > No known risks or assumptions at this time. > > 3. Business Summary > 3.1. Problem Area: > Default compilers on OpenSolaris > Default compilers bundled with all distribution of Solaris > > 3.2. Market/Requester: > OpenSolaris > > 3.3. Business Justification: > Encourage FOSS inclusion into OpenSolaris repositories by > minimizing compiler-related porting effort. > > Provide a bundled set of compilers for any distribution of > Solaris. > > The target customers are people building software on Solaris > Nevada derived distributions. Not necessarily people building > Solaris itself. The culture of Nevada is for consolidations to > deliver the latest semi-stable development builds, which are > periodically updated. This closely matches the Sun Studio > Express release cycle. > > 3.4. Competitive Analysis: > Main competitors: Platforms & Tool Suite Offerings > - Red Hat: GCC (bundled and supported) > - Windows: Microsoft Visual Studio (unbundled) > - MacOS: Xcode (gcc-based), LLVM effort > > 3.5. Opportunity Window/Exposure: > 04/2009 to coincide with the next release of OpenSolaris. > > 3.6. How will you know when you are done?: > The project will be on-going always tracking the latest express > release of Sun Studio C, C++ and dbx > > 4. Technical Description: > 4.1. Details: > > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant > redesign. We need a location into which to install the > compiler components, with symlinks to those components > installed in /usr/bin and /usr/share/man. The delivery will > install the bundled compiler collection components into > /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and > /usr/share/man. We chose the name 'compilers' to > intentionally indicate these are the > default|builtin|preferred|bundled compilers. There will not > be multiple versions, there will only be one set of bundled > compilers. Versions of the unbundled Sun Studio will > continue to install into /opt, i.e. /opt/sunstudio13, > /opt/sunstudio14, etc.. Note Sun Studio also provides an > optional package for installing links in /usr/bin and > /usr/share/man, these would then override the links of this > bundled compiler as it does previously installed versions of > Sun Studio. > > - The first delivery will be the C, C++ and dbx components of > Sun Studio Express 2008.11 release.. > > - Links will be created in /usr/bin, e.g. /usr/bin/cc, > /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate > binaries /usr/compilers. > > - Links will be created in /usr/man, e.g. /usr/man/man1/cc, > /usr/man/man1/CC, /usr/man/man1/dbx, etc., to > point to man pages in /usr/compilers/man/man1. > > 4.2. Bug/RFE Number(s): > Not applicable. > > 4.3. In Scope: > - C, C++ compilers and dbx > > 4.4. Out of Scope: > > > 4.5. Interfaces: > > The following soft links will be created in /usr/bin to point to > the appropriate binaries of /usr/compilers/suncc2008.11/bin. We > may choose to omit some of these links which do not contribute > to minimizing compiler-related porting efforts to encourage FOSS > inclussion into OpenSolaris repositories. > > /usr/bin/bcheck > /usr/bin/c++filt > /usr/bin/c89 > /usr/bin/c99 > /usr/bin/cb > /usr/bin/cc > /usr/bin/CC > /usr/bin/CCadmin > /usr/bin/cflow > /usr/bin/cscope > /usr/bin/ctcr > /usr/bin/ctrace > /usr/bin/cxref > /usr/bin/dbx > /usr/bin/dem > /usr/bin/dumpstabs > /usr/bin/dwarfdump > /usr/bin/fbe > /usr/bin/fpversion > /usr/bin/indent > /usr/bin/lint > /usr/bin/rtc_patch_area > /usr/bin/sunc89 > /usr/bin/sunc99 > /usr/bin/suncc > /usr/bin/sunCC > /usr/bin/tcov > > 4.6. Doc Impact: > > Links will be created in /usr/share/man/* for the following man > pages: > > /usr/compilers/man1/CC.1 > /usr/compilers/man1/CCadmin.1 > /usr/compilers/man1/bcheck.1 > /usr/compilers/man1/binopt.1 > /usr/compilers/man1/c++filt.1 > /usr/compilers/man1/c89.1 > /usr/compilers/man1/c99.1 > /usr/compilers/man1/cb.1 > /usr/compilers/man1/cc.1 > /usr/compilers/man1/cflow.1 > /usr/compilers/man1/cscope.1 > /usr/compilers/man1/ctrace.1 > /usr/compilers/man1/cxref.1 > /usr/compilers/man1/dbx.1 > /usr/compilers/man1/dem.1 > /usr/compilers/man1/fbe.1 > /usr/compilers/man1/fpversion.1 > /usr/compilers/man1/indent.1 > /usr/compilers/man1/inline.1 > /usr/compilers/man1/lint.1 > /usr/compilers/man1/rtc_patch_area.1 > /usr/compilers/man1/ss_attach.1 > /usr/compilers/man3/gcFixPrematureFrees.3 > /usr/compilers/man3/gcInitialize.3 > /usr/compilers/man3cc4/cartpol.3 > /usr/compilers/man3cc4/cplx.intro.3 > /usr/compilers/man3cc4/cplxerr.3 > /usr/compilers/man3cc4/cplxexp.3 > /usr/compilers/man3cc4/cplxops.3 > /usr/compilers/man3cc4/cplxtrig.3 > /usr/compilers/man3cc4/filebuf.3 > /usr/compilers/man3cc4/fstream.3 > /usr/compilers/man3cc4/interrupt.3 > /usr/compilers/man3cc4/ios.3 > /usr/compilers/man3cc4/ios.intro.3 > /usr/compilers/man3cc4/istream.3 > /usr/compilers/man3cc4/manip.3 > /usr/compilers/man3cc4/ostream.3 > /usr/compilers/man3cc4/queue.3 > /usr/compilers/man3cc4/sbufprot.3 > /usr/compilers/man3cc4/sbufpub.3 > /usr/compilers/man3cc4/ssbuf.3 > /usr/compilers/man3cc4/stdiobuf.3 > /usr/compilers/man3cc4/stream_MT.3 > /usr/compilers/man3cc4/stream_locker.3 > /usr/compilers/man3cc4/strstream.3 > /usr/compilers/man3cc4/task.3 > /usr/compilers/man3cc4/task.intro.3 > /usr/compilers/man3cc4/tasksim.3 > /usr/compilers/man3x/_rtc_check_free.3x > /usr/compilers/man3x/_rtc_check_malloc.3x > /usr/compilers/man3x/_rtc_check_malloc_result.3x > /usr/compilers/man3x/_rtc_check_realloc.3x > /usr/compilers/man3x/_rtc_check_realloc_result.3x > /usr/compilers/man3x/_rtc_hide_region.3x > /usr/compilers/man3x/_rtc_off.3x > /usr/compilers/man3x/_rtc_on.3x > /usr/compilers/man3x/_rtc_record_free.3x > /usr/compilers/man3x/_rtc_record_malloc.3x > /usr/compilers/man3x/_rtc_record_realloc.3x > /usr/compilers/man3x/_rtc_report_error.3x > /usr/compilers/man3x/rtc_api.3x > /usr/compilers/man4/dbxrc.4 > > 4.7. Admin/Config Impact: > No change. > > 4.8. HA Impact: > No change. > > 4.9. I18N/L10N Impact: > Sun Studio C/C++/dbx Collection is I18N > L10N to be coordinated with Nevada L10N > > 4.10. Packaging & Delivery: > Name Stability Notes > ==== ========= ===== > SUNWcompilers Committed Sun Studio > C/C++/dbx core cluster > SUNWcompilerlinks Committed Sun Studio > C/C++/dbx /usr/bin /usr/man links > > 4.11. Security Impact: > No impact. > > 4.12. Dependencies: > SUNWlibC C++ stdlibs > SUNWlibms limtsk, etc. > SUNWcar Core Architecture, (Root) > SUNWcsd Core Solaris Devices > SUNWcsr Core Solaris, (Root) > SUNWcsu Core Solaris, (Usr) > SUNWesu Extended System Utilities > SUNWhea Header files > SUNWkvm Core Architecture, (Kvm) > SUNWtoo Programming Tools > > 5. Reference Documents: > LSARC/2008/776 GNU Developer Collection > LSARC/2006/280 Tools DVD for S10u2 > PSARC/2007/074 /usr/gnu > Established precedent of having program visible by multiple > names. > > 6. Resources and Schedule: > 6.1. Projected Availability: > April 2009 to coincide with OpenSolaris 2009.04 > > 6.2. Cost of Effort: > .5 developers. > > 6.3. Cost of Capital Resources: > No additional capital resources were required. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > Devpro > 6.4.3. Type of CPT Review and Approval expected: > FastTrack > 6.4.4. Project Boundary Conditions: > > 6.4.5. Is this a necessary project for OEM agreements: > No > 6.4.6. Notes: > > 6.4.7. Target RTI Date/Release: > Build 108 02/09/2009. > 6.4.8. Target Code Design Review Date: > Completed > > 6.4.9. Update approval addition: > - SPDE PAC scheduling in progress > - Solaris PAC scheduling in progress > > 6.5. ARC review type: > FastTrack > > 6.6. ARC Exposure: > open > 6.6.1. Rationale: > Not applicable. > > 7. Prototype Availability: > 7.1. Prototype Availability: > Not applicable. > > 7.2. Prototype Cost: > Not Applicable. > > From ro@techfak.uni-bielefeld.de Thu Jan 15 04:01:19 2009 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 n0FC1I3x018258 for ; Thu, 15 Jan 2009 04:01:19 -0800 (PST) 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 n0FC18jH048160; Thu, 15 Jan 2009 05:01:16 -0700 (MST) 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 <0KDI00K0HHE3XQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 04:01:15 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI00ET9HE3GM50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 04:01:15 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FC1EIQ006618; Thu, 15 Jan 2009 12:01:14 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-360908; Thu, 15 Jan 2009 12:00:35 +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-63776958; Thu, 15 Jan 2009 12:00:34 +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-26776603; Thu, 15 Jan 2009 12:00:34 +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 EC768482AE; Thu, 15 Jan 2009 13:00:33 +0100 (CET) Date: Thu, 15 Jan 2009 13:00:33 +0100 From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Chris Quenelle's message of "Wed, 14 Jan 2009 15:06:56 -0800" Sender: ro@techfak.uni-bielefeld.de To: Chris.Quenelle@sun.com Cc: Dale Ghent , Douglas Walls , David.Ford@sun.com, LSARC-ext@sun.com, James Carlson , Raj Prakash 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 0.595sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 22 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <988955F8-C928-48AC-AC1A-16768038A79A@elemental.org> <18798.12093.413445.295846@gargle.gargle.HOWL> <15611CDF-069A-46F6-A694-AA3C107C6C86@elemental.org> <496E63DB.90408@Sun.COM> <496E7010.7070507@Sun.COM> Status: RO Content-Length: 894 Chris Quenelle writes: > Dale Ghent wrote: > > It's just an idea for the issue of choosing compilers, use it (or not!) > > FWIW :) > > I'm always happy to get constructive advice, so thanks! > In this case, my judgment of the cost/benefit trade off > tells me it's not worth the added complication. I'd be happy Not only that, but it's an uncommon additional variable which adds into the question which compiler is used, which can make debugging compile problems harder. Using $PATH is well-known and understood on every platform, such a new variable is not. That's the reason the GCC developers adamantly refuse to have environment variables influence the compilation, and I think they are right in this regards. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From tom.childers@sun.com Thu Jan 15 08:14:51 2009 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 n0FGEpGT019866 for ; Thu, 15 Jan 2009 08:14:51 -0800 (PST) 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 n0FGEn1j008916 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 08:14:51 -0800 (PST) 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 <0KDI00A09T4RQ100@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 08:14:51 -0800 (PST) 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 <0KDI00511T4QPE70@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 08:14:50 -0800 (PST) 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 n0FGEow2025737 for ; Thu, 15 Jan 2009 08:14:50 -0800 (PST) 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 <0KDI00F01SYFHI00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 08:14:50 -0800 (PST) Received: from [10.0.1.5] ([98.210.99.213]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDI00180T4PQE60@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 08:14:50 -0800 (PST) Date: Thu, 15 Jan 2009 08:14:42 -0800 From: Tom Childers Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496E5E15.4090400@sun.com> Sender: Thomas.Childers@sun.com To: Douglas Walls Cc: Raj Prakash , LSARC-ext@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> Status: RO Content-Length: 11334 I think the man pages have to be in a versioned directory along with the binaries. Is there any reason you did not put them into something like /usr/compilers/suncc2008.1/man*? -tdc On Jan 14, 2009, at 1:50 PM, Douglas Walls wrote: > Raj, > > Here is the updated case for > [LSARC/2009/017 Bundled Compiler Collection], > please set the new timeout. > > Thanks, Douglas > ============================================ > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: Bundled Compiler Collection > > 1.2. Name of Document Author/Supplier: > Douglas Walls (Douglas.Walls@Sun.COM> > > 1.3. Date of This Document: 1/14/2009 > 1.3.1. Date this project was conceived: 10/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris > 1.4.1. The PAC or CPT you expect to review your project: SPDE > PAC > 1.4.2. The ARC(s) you expect to review your project: LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com > 1.4.4. The name of your business unit: CODE (C/C++ Compilers, > Optimization, and Debugger) > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Kurt Goebel > 1.5.2. Responsible Engineer: Douglas Walls > > 1.5.3. Marketing Manager: Ikroop Dhillon > > 1.5.4. Interest List: tools-compilers@opensolaris.org > > 2. Project Summary > 2.1. Project Description: > > The project will deliver C, C++ and dbx from the current Sun > Studio Express release into Nevada through the devpro > consolidation. The intent is to bundle Sun compilers into > /usr. We are not bundling all of Sun Studio. This collection > only contains C and C++ compilers along with their debugger, > dbx. > > 2.2. Risks and Assumptions: > No known risks or assumptions at this time. > > 3. Business Summary > 3.1. Problem Area: > Default compilers on OpenSolaris > Default compilers bundled with all distribution of Solaris > > 3.2. Market/Requester: > OpenSolaris > > 3.3. Business Justification: > Encourage FOSS inclusion into OpenSolaris repositories by > minimizing compiler-related porting effort. > > Provide a bundled set of compilers for any distribution of > Solaris. > > The target customers are people building software on Solaris > Nevada derived distributions. Not necessarily people building > Solaris itself. The culture of Nevada is for consolidations to > deliver the latest semi-stable development builds, which are > periodically updated. This closely matches the Sun Studio > Express release cycle. > > 3.4. Competitive Analysis: > Main competitors: Platforms & Tool Suite Offerings > - Red Hat: GCC (bundled and supported) > - Windows: Microsoft Visual Studio (unbundled) > - MacOS: Xcode (gcc-based), LLVM effort > > 3.5. Opportunity Window/Exposure: > 04/2009 to coincide with the next release of OpenSolaris. > > 3.6. How will you know when you are done?: > The project will be on-going always tracking the latest express > release of Sun Studio C, C++ and dbx > > 4. Technical Description: > 4.1. Details: > > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant > redesign. We need a location into which to install the > compiler components, with symlinks to those components > installed in /usr/bin and /usr/share/man. The delivery will > install the bundled compiler collection components into > /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and > /usr/share/man. We chose the name 'compilers' to > intentionally indicate these are the > default|builtin|preferred|bundled compilers. There will not > be multiple versions, there will only be one set of bundled > compilers. Versions of the unbundled Sun Studio will > continue to install into /opt, i.e. /opt/sunstudio13, > /opt/sunstudio14, etc.. Note Sun Studio also provides an > optional package for installing links in /usr/bin and > /usr/share/man, these would then override the links of this > bundled compiler as it does previously installed versions of > Sun Studio. > > - The first delivery will be the C, C++ and dbx components of > Sun Studio Express 2008.11 release.. > > - Links will be created in /usr/bin, e.g. /usr/bin/cc, > /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate > binaries /usr/compilers. > > - Links will be created in /usr/man, e.g. /usr/man/man1/cc, > /usr/man/man1/CC, /usr/man/man1/dbx, etc., to > point to man pages in /usr/compilers/man/man1. > > 4.2. Bug/RFE Number(s): > Not applicable. > > 4.3. In Scope: > - C, C++ compilers and dbx > > 4.4. Out of Scope: > > > 4.5. Interfaces: > > The following soft links will be created in /usr/bin to point > to > the appropriate binaries of /usr/compilers/suncc2008.11/bin. > We > may choose to omit some of these links which do not contribute > to minimizing compiler-related porting efforts to encourage > FOSS > inclussion into OpenSolaris repositories. > > /usr/bin/bcheck > /usr/bin/c++filt > /usr/bin/c89 > /usr/bin/c99 > /usr/bin/cb > /usr/bin/cc > /usr/bin/CC > /usr/bin/CCadmin > /usr/bin/cflow > /usr/bin/cscope > /usr/bin/ctcr > /usr/bin/ctrace > /usr/bin/cxref > /usr/bin/dbx > /usr/bin/dem > /usr/bin/dumpstabs > /usr/bin/dwarfdump > /usr/bin/fbe > /usr/bin/fpversion > /usr/bin/indent > /usr/bin/lint > /usr/bin/rtc_patch_area > /usr/bin/sunc89 > /usr/bin/sunc99 > /usr/bin/suncc > /usr/bin/sunCC > /usr/bin/tcov > > 4.6. Doc Impact: > > Links will be created in /usr/share/man/* for the following > man pages: > > /usr/compilers/man1/CC.1 > /usr/compilers/man1/CCadmin.1 > /usr/compilers/man1/bcheck.1 > /usr/compilers/man1/binopt.1 > /usr/compilers/man1/c++filt.1 > /usr/compilers/man1/c89.1 > /usr/compilers/man1/c99.1 > /usr/compilers/man1/cb.1 > /usr/compilers/man1/cc.1 > /usr/compilers/man1/cflow.1 > /usr/compilers/man1/cscope.1 > /usr/compilers/man1/ctrace.1 > /usr/compilers/man1/cxref.1 > /usr/compilers/man1/dbx.1 > /usr/compilers/man1/dem.1 > /usr/compilers/man1/fbe.1 > /usr/compilers/man1/fpversion.1 > /usr/compilers/man1/indent.1 > /usr/compilers/man1/inline.1 > /usr/compilers/man1/lint.1 > /usr/compilers/man1/rtc_patch_area.1 > /usr/compilers/man1/ss_attach.1 > /usr/compilers/man3/gcFixPrematureFrees.3 > /usr/compilers/man3/gcInitialize.3 > /usr/compilers/man3cc4/cartpol.3 > /usr/compilers/man3cc4/cplx.intro.3 > /usr/compilers/man3cc4/cplxerr.3 > /usr/compilers/man3cc4/cplxexp.3 > /usr/compilers/man3cc4/cplxops.3 > /usr/compilers/man3cc4/cplxtrig.3 > /usr/compilers/man3cc4/filebuf.3 > /usr/compilers/man3cc4/fstream.3 > /usr/compilers/man3cc4/interrupt.3 > /usr/compilers/man3cc4/ios.3 > /usr/compilers/man3cc4/ios.intro.3 > /usr/compilers/man3cc4/istream.3 > /usr/compilers/man3cc4/manip.3 > /usr/compilers/man3cc4/ostream.3 > /usr/compilers/man3cc4/queue.3 > /usr/compilers/man3cc4/sbufprot.3 > /usr/compilers/man3cc4/sbufpub.3 > /usr/compilers/man3cc4/ssbuf.3 > /usr/compilers/man3cc4/stdiobuf.3 > /usr/compilers/man3cc4/stream_MT.3 > /usr/compilers/man3cc4/stream_locker.3 > /usr/compilers/man3cc4/strstream.3 > /usr/compilers/man3cc4/task.3 > /usr/compilers/man3cc4/task.intro.3 > /usr/compilers/man3cc4/tasksim.3 > /usr/compilers/man3x/_rtc_check_free.3x > /usr/compilers/man3x/_rtc_check_malloc.3x > /usr/compilers/man3x/_rtc_check_malloc_result.3x > /usr/compilers/man3x/_rtc_check_realloc.3x > /usr/compilers/man3x/_rtc_check_realloc_result.3x > /usr/compilers/man3x/_rtc_hide_region.3x > /usr/compilers/man3x/_rtc_off.3x > /usr/compilers/man3x/_rtc_on.3x > /usr/compilers/man3x/_rtc_record_free.3x > /usr/compilers/man3x/_rtc_record_malloc.3x > /usr/compilers/man3x/_rtc_record_realloc.3x > /usr/compilers/man3x/_rtc_report_error.3x > /usr/compilers/man3x/rtc_api.3x > /usr/compilers/man4/dbxrc.4 > > 4.7. Admin/Config Impact: > No change. > > 4.8. HA Impact: > No change. > > 4.9. I18N/L10N Impact: > Sun Studio C/C++/dbx Collection is I18N > L10N to be coordinated with Nevada L10N > > 4.10. Packaging & Delivery: > Name Stability Notes > ==== ========= ===== > SUNWcompilers Committed Sun Studio C/C > ++/dbx core cluster > SUNWcompilerlinks Committed Sun Studio C/C > ++/dbx /usr/bin /usr/man links > > 4.11. Security Impact: > No impact. > > 4.12. Dependencies: > SUNWlibC C++ stdlibs > SUNWlibms limtsk, etc. > SUNWcar Core Architecture, (Root) > SUNWcsd Core Solaris Devices > SUNWcsr Core Solaris, (Root) > SUNWcsu Core Solaris, (Usr) > SUNWesu Extended System Utilities > SUNWhea Header files > SUNWkvm Core Architecture, (Kvm) > SUNWtoo Programming Tools > > 5. Reference Documents: > LSARC/2008/776 GNU Developer Collection > LSARC/2006/280 Tools DVD for S10u2 > PSARC/2007/074 /usr/gnu > Established precedent of having program visible by multiple > names. > > 6. Resources and Schedule: > 6.1. Projected Availability: > April 2009 to coincide with OpenSolaris 2009.04 > > 6.2. Cost of Effort: > .5 developers. > > 6.3. Cost of Capital Resources: > No additional capital resources were required. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > Devpro > 6.4.3. Type of CPT Review and Approval expected: > FastTrack > 6.4.4. Project Boundary Conditions: > > 6.4.5. Is this a necessary project for OEM agreements: > No > 6.4.6. Notes: > > 6.4.7. Target RTI Date/Release: > Build 108 02/09/2009. > 6.4.8. Target Code Design Review Date: > Completed > > 6.4.9. Update approval addition: > - SPDE PAC scheduling in progress > - Solaris PAC scheduling in progress > > 6.5. ARC review type: > FastTrack > > 6.6. ARC Exposure: > open > 6.6.1. Rationale: > Not applicable. > > 7. Prototype Availability: > 7.1. Prototype Availability: > Not applicable. > > 7.2. Prototype Cost: > Not Applicable. From Chris.Quenelle@Sun.COM Thu Jan 15 09:37:44 2009 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 n0FHbiR2021447 for ; Thu, 15 Jan 2009 09:37:44 -0800 (PST) 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 n0FHbhfu006228 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 09:37:44 -0800 (PST) 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 <0KDI00G07WYV6K00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 09:37:43 -0800 (PST) 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 <0KDI0051CWYVP6E0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 09:37:43 -0800 (PST) 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 n0FHbgoX015067 for ; Thu, 15 Jan 2009 09:37:42 -0800 (PST) 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 <0KDI00I01USH0Y00@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 09:37:42 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDI000ZVWYNFQG0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 09:37:35 -0800 (PST) Date: Thu, 15 Jan 2009 09:34:52 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Sender: Chris.Quenelle@Sun.COM To: Tom Childers Cc: Douglas Walls , Raj Prakash , LSARC-ext@Sun.COM, David.Ford@Sun.COM Reply-to: Chris.Quenelle@Sun.COM Message-id: <496F73BC.3050303@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 12188 The man pages need to be treated similarly to the binaries, the versioning and selection issues are the same. In the latest proposal, the bundled compiler binaries are not versioned, and neither are the man pages. If you want multiple versions of the compilers, you can install as many different versions of the unbundled product as you want. This case is about choosing one version to bundle into the OS as the default compiler. --chris Tom Childers wrote: > I think the man pages have to be in a versioned directory along with the > binaries. Is there any reason you did not put them into something like > /usr/compilers/suncc2008.1/man*? > -tdc > > On Jan 14, 2009, at 1:50 PM, Douglas Walls wrote: > >> Raj, >> >> Here is the updated case for >> [LSARC/2009/017 Bundled Compiler Collection], >> please set the new timeout. >> >> Thanks, Douglas >> ============================================ >> >> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >> Copyright 2007 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: Bundled Compiler Collection >> >> 1.2. Name of Document Author/Supplier: >> Douglas Walls (Douglas.Walls@Sun.COM> >> >> 1.3. Date of This Document: 1/14/2009 >> 1.3.1. Date this project was conceived: 10/2008 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris >> 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC >> 1.4.2. The ARC(s) you expect to review your project: LSARC >> 1.4.3. The Director/VP who is "Sponsoring" this project: >> Kurt.Goebel@Sun.Com >> 1.4.4. The name of your business unit: CODE (C/C++ Compilers, >> Optimization, and Debugger) >> >> 1.5. Email Aliases: >> 1.5.1. Responsible Manager: Kurt Goebel >> 1.5.2. Responsible Engineer: Douglas Walls >> 1.5.3. Marketing Manager: Ikroop Dhillon >> 1.5.4. Interest List: tools-compilers@opensolaris.org >> >> 2. Project Summary >> 2.1. Project Description: >> >> The project will deliver C, C++ and dbx from the current Sun >> Studio Express release into Nevada through the devpro >> consolidation. The intent is to bundle Sun compilers into >> /usr. We are not bundling all of Sun Studio. This collection >> only contains C and C++ compilers along with their debugger, >> dbx. >> >> 2.2. Risks and Assumptions: >> No known risks or assumptions at this time. >> >> 3. Business Summary >> 3.1. Problem Area: >> Default compilers on OpenSolaris >> Default compilers bundled with all distribution of Solaris >> >> 3.2. Market/Requester: >> OpenSolaris >> >> 3.3. Business Justification: >> Encourage FOSS inclusion into OpenSolaris repositories by >> minimizing compiler-related porting effort. >> >> Provide a bundled set of compilers for any distribution of >> Solaris. >> >> The target customers are people building software on Solaris >> Nevada derived distributions. Not necessarily people building >> Solaris itself. The culture of Nevada is for consolidations to >> deliver the latest semi-stable development builds, which are >> periodically updated. This closely matches the Sun Studio >> Express release cycle. >> >> 3.4. Competitive Analysis: >> Main competitors: Platforms & Tool Suite Offerings >> - Red Hat: GCC (bundled and supported) >> - Windows: Microsoft Visual Studio (unbundled) >> - MacOS: Xcode (gcc-based), LLVM effort >> >> 3.5. Opportunity Window/Exposure: >> 04/2009 to coincide with the next release of OpenSolaris. >> >> 3.6. How will you know when you are done?: >> The project will be on-going always tracking the latest express >> release of Sun Studio C, C++ and dbx >> >> 4. Technical Description: >> 4.1. Details: >> >> - The design of the Sun compilers precludes just installing >> them into /usr/bin, /usr/lib, etc. without significant >> redesign. We need a location into which to install the >> compiler components, with symlinks to those components >> installed in /usr/bin and /usr/share/man. The delivery will >> install the bundled compiler collection components into >> /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and >> /usr/share/man. We chose the name 'compilers' to >> intentionally indicate these are the >> default|builtin|preferred|bundled compilers. There will not >> be multiple versions, there will only be one set of bundled >> compilers. Versions of the unbundled Sun Studio will >> continue to install into /opt, i.e. /opt/sunstudio13, >> /opt/sunstudio14, etc.. Note Sun Studio also provides an >> optional package for installing links in /usr/bin and >> /usr/share/man, these would then override the links of this >> bundled compiler as it does previously installed versions of >> Sun Studio. >> >> - The first delivery will be the C, C++ and dbx components of >> Sun Studio Express 2008.11 release.. >> >> - Links will be created in /usr/bin, e.g. /usr/bin/cc, >> /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate >> binaries /usr/compilers. >> >> - Links will be created in /usr/man, e.g. /usr/man/man1/cc, >> /usr/man/man1/CC, /usr/man/man1/dbx, etc., to >> point to man pages in /usr/compilers/man/man1. >> >> 4.2. Bug/RFE Number(s): >> Not applicable. >> >> 4.3. In Scope: >> - C, C++ compilers and dbx >> >> 4.4. Out of Scope: >> >> >> 4.5. Interfaces: >> >> The following soft links will be created in /usr/bin to point to >> the appropriate binaries of /usr/compilers/suncc2008.11/bin. We >> may choose to omit some of these links which do not contribute >> to minimizing compiler-related porting efforts to encourage FOSS >> inclussion into OpenSolaris repositories. >> >> /usr/bin/bcheck >> /usr/bin/c++filt >> /usr/bin/c89 >> /usr/bin/c99 >> /usr/bin/cb >> /usr/bin/cc >> /usr/bin/CC >> /usr/bin/CCadmin >> /usr/bin/cflow >> /usr/bin/cscope >> /usr/bin/ctcr >> /usr/bin/ctrace >> /usr/bin/cxref >> /usr/bin/dbx >> /usr/bin/dem >> /usr/bin/dumpstabs >> /usr/bin/dwarfdump >> /usr/bin/fbe >> /usr/bin/fpversion >> /usr/bin/indent >> /usr/bin/lint >> /usr/bin/rtc_patch_area >> /usr/bin/sunc89 >> /usr/bin/sunc99 >> /usr/bin/suncc >> /usr/bin/sunCC >> /usr/bin/tcov >> >> 4.6. Doc Impact: >> >> Links will be created in /usr/share/man/* for the following man >> pages: >> >> /usr/compilers/man1/CC.1 >> /usr/compilers/man1/CCadmin.1 >> /usr/compilers/man1/bcheck.1 >> /usr/compilers/man1/binopt.1 >> /usr/compilers/man1/c++filt.1 >> /usr/compilers/man1/c89.1 >> /usr/compilers/man1/c99.1 >> /usr/compilers/man1/cb.1 >> /usr/compilers/man1/cc.1 >> /usr/compilers/man1/cflow.1 >> /usr/compilers/man1/cscope.1 >> /usr/compilers/man1/ctrace.1 >> /usr/compilers/man1/cxref.1 >> /usr/compilers/man1/dbx.1 >> /usr/compilers/man1/dem.1 >> /usr/compilers/man1/fbe.1 >> /usr/compilers/man1/fpversion.1 >> /usr/compilers/man1/indent.1 >> /usr/compilers/man1/inline.1 >> /usr/compilers/man1/lint.1 >> /usr/compilers/man1/rtc_patch_area.1 >> /usr/compilers/man1/ss_attach.1 >> /usr/compilers/man3/gcFixPrematureFrees.3 >> /usr/compilers/man3/gcInitialize.3 >> /usr/compilers/man3cc4/cartpol.3 >> /usr/compilers/man3cc4/cplx.intro.3 >> /usr/compilers/man3cc4/cplxerr.3 >> /usr/compilers/man3cc4/cplxexp.3 >> /usr/compilers/man3cc4/cplxops.3 >> /usr/compilers/man3cc4/cplxtrig.3 >> /usr/compilers/man3cc4/filebuf.3 >> /usr/compilers/man3cc4/fstream.3 >> /usr/compilers/man3cc4/interrupt.3 >> /usr/compilers/man3cc4/ios.3 >> /usr/compilers/man3cc4/ios.intro.3 >> /usr/compilers/man3cc4/istream.3 >> /usr/compilers/man3cc4/manip.3 >> /usr/compilers/man3cc4/ostream.3 >> /usr/compilers/man3cc4/queue.3 >> /usr/compilers/man3cc4/sbufprot.3 >> /usr/compilers/man3cc4/sbufpub.3 >> /usr/compilers/man3cc4/ssbuf.3 >> /usr/compilers/man3cc4/stdiobuf.3 >> /usr/compilers/man3cc4/stream_MT.3 >> /usr/compilers/man3cc4/stream_locker.3 >> /usr/compilers/man3cc4/strstream.3 >> /usr/compilers/man3cc4/task.3 >> /usr/compilers/man3cc4/task.intro.3 >> /usr/compilers/man3cc4/tasksim.3 >> /usr/compilers/man3x/_rtc_check_free.3x >> /usr/compilers/man3x/_rtc_check_malloc.3x >> /usr/compilers/man3x/_rtc_check_malloc_result.3x >> /usr/compilers/man3x/_rtc_check_realloc.3x >> /usr/compilers/man3x/_rtc_check_realloc_result.3x >> /usr/compilers/man3x/_rtc_hide_region.3x >> /usr/compilers/man3x/_rtc_off.3x >> /usr/compilers/man3x/_rtc_on.3x >> /usr/compilers/man3x/_rtc_record_free.3x >> /usr/compilers/man3x/_rtc_record_malloc.3x >> /usr/compilers/man3x/_rtc_record_realloc.3x >> /usr/compilers/man3x/_rtc_report_error.3x >> /usr/compilers/man3x/rtc_api.3x >> /usr/compilers/man4/dbxrc.4 >> >> 4.7. Admin/Config Impact: >> No change. >> >> 4.8. HA Impact: >> No change. >> >> 4.9. I18N/L10N Impact: >> Sun Studio C/C++/dbx Collection is I18N >> L10N to be coordinated with Nevada L10N >> >> 4.10. Packaging & Delivery: >> Name Stability Notes >> ==== ========= ===== >> SUNWcompilers Committed Sun Studio >> C/C++/dbx core cluster >> SUNWcompilerlinks Committed Sun Studio >> C/C++/dbx /usr/bin /usr/man links >> >> 4.11. Security Impact: >> No impact. >> >> 4.12. Dependencies: >> SUNWlibC C++ stdlibs >> SUNWlibms limtsk, etc. >> SUNWcar Core Architecture, (Root) >> SUNWcsd Core Solaris Devices >> SUNWcsr Core Solaris, (Root) >> SUNWcsu Core Solaris, (Usr) >> SUNWesu Extended System Utilities >> SUNWhea Header files >> SUNWkvm Core Architecture, (Kvm) >> SUNWtoo Programming Tools >> >> 5. Reference Documents: >> LSARC/2008/776 GNU Developer Collection >> LSARC/2006/280 Tools DVD for S10u2 >> PSARC/2007/074 /usr/gnu >> Established precedent of having program visible by multiple >> names. >> >> 6. Resources and Schedule: >> 6.1. Projected Availability: >> April 2009 to coincide with OpenSolaris 2009.04 >> >> 6.2. Cost of Effort: >> .5 developers. >> >> 6.3. Cost of Capital Resources: >> No additional capital resources were required. >> >> 6.4. Product Approval Committee requested information: >> 6.4.1. Consolidation or Component Name: >> Devpro >> 6.4.3. Type of CPT Review and Approval expected: >> FastTrack >> 6.4.4. Project Boundary Conditions: >> >> 6.4.5. Is this a necessary project for OEM agreements: >> No >> 6.4.6. Notes: >> >> 6.4.7. Target RTI Date/Release: >> Build 108 02/09/2009. >> 6.4.8. Target Code Design Review Date: >> Completed >> >> 6.4.9. Update approval addition: >> - SPDE PAC scheduling in progress >> - Solaris PAC scheduling in progress >> >> 6.5. ARC review type: >> FastTrack >> >> 6.6. ARC Exposure: >> open >> 6.6.1. Rationale: >> Not applicable. >> >> 7. Prototype Availability: >> 7.1. Prototype Availability: >> Not applicable. >> >> 7.2. Prototype Cost: >> Not Applicable. > From danek.duvall@sun.com Thu Jan 15 09:50:18 2009 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 n0FHoIFJ021585 for ; Thu, 15 Jan 2009 09:50:18 -0800 (PST) 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 n0FHoGI2003500 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 09:50:18 -0800 (PST) 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 <0KDI00C0JXJT8Q00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 10:50:17 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI007QTXJSHE30@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 10:50:16 -0700 (MST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FHoGGU010607; Thu, 15 Jan 2009 09:50:16 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FHq30H019498; Thu, 15 Jan 2009 09:52:03 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FHq3DR019497; Thu, 15 Jan 2009 09:52:03 -0800 (PST) Date: Thu, 15 Jan 2009 09:52:03 -0800 From: Danek Duvall Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496E5E15.4090400@sun.com> To: Douglas Walls Cc: Raj Prakash , LSARC-ext@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <20090115175203.GT2706@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1175 On Wed, Jan 14, 2009 at 01:50:13PM -0800, Douglas Walls wrote: > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant > redesign. Could you talk about that briefly? I'm guessing that you assume that an executable can find things by looking at its realpath (or equivalent) and fetching ../lib/, and that putting all those s into /usr/lib would be messy, but perhaps there's something else going on. What would be the work involved to fix that, perhaps even just noting that when the executable is in /usr/bin, the auxiliary bits can be found in /usr/lib/suncc (or whatever). Not for this case, perhaps, but for a future update of the bundled compilers. > We need a location into which to install the > compiler components, with symlinks to those components > installed in /usr/bin and /usr/share/man. The delivery will > install the bundled compiler collection components into > /usr/compilers/{bin,lib,...}, Why /usr/compilers, then, rather than something under /usr/lib/? And the man pages should be able to go directly in /usr/share/man, no? Danek From john.plocher@gmail.com Thu Jan 15 10:22:03 2009 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 n0FIM2LX023285 for ; Thu, 15 Jan 2009 10:22:03 -0800 (PST) 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 n0FILpIv007026; Fri, 16 Jan 2009 02:21:58 +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 <0KDI00F0NZ0LA500@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 11:21:57 -0700 (MST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI007PQZ0KHH60@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 11:21:56 -0700 (MST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FILtXP025313; Thu, 15 Jan 2009 18:21:56 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay11i.sun.com with ESMTP id BT-MMP-2662901; Thu, 15 Jan 2009 18:21:55 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-64215509; Thu, 15 Jan 2009 18:21:55 +0000 (Z) Received: from rv-out-0506.google.com ([209.85.198.235] [209.85.198.235]) by relay1ib.sun.com with ESMTP id BT-MMP-24511578; Thu, 15 Jan 2009 18:21:55 +0000 (Z) Received: by rv-out-0506.google.com with SMTP id f9so2399098rvb.2 for ; Thu, 15 Jan 2009 10:21:54 -0800 (PST) Received: by 10.141.210.2 with SMTP id m2mr735413rvq.284.1232043714136; Thu, 15 Jan 2009 10:21:54 -0800 (PST) Received: by 10.141.43.21 with HTTP; Thu, 15 Jan 2009 10:21:54 -0800 (PST) Date: Thu, 15 Jan 2009 10:21:54 -0800 From: John Plocher Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496F73BC.3050303@Sun.COM> To: Chris.Quenelle@sun.com Cc: Tom Childers , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bb5eI/Z7Ysc+OiJ+H7axiGqo02sr88q9NiBIyp1U+m4=; b=CXgqs5BmKTtjEt45BWNlVJ/FfArdQuS30VdfBOOYKK4khWNUF+0tmF1qrF1LnU9AwT Cx43lx8KRh4R1amH1yUpksi9FJm1R67xb21z93mdL3kzw8rtzXJ0ziJwAY75JgN8EluM Fj3bpAlZ8kqjO/fCWyit/L6257aKWzgeT9MyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=onB2mkYOm31wCtF3huAvutfDa5NV2EbXSi4xAcrqZuWz9EzJeRxxKIW67xm+PeLkUp FIt2TW43S4XeDX4PoI0OgOMPzTVG93u30J5mc8Hk5fzt23230pBBU450/gUeSYXWecJy WvxgPeHthBxIqoCAuCCN8cnMyX+WaL9WbIgQE= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> Status: RO Content-Length: 1176 On Thu, Jan 15, 2009 at 9:34 AM, Chris Quenelle wrote: > In the latest proposal, the bundled compiler binaries are not versioned, > and neither are the man pages. If you want multiple versions of the > compilers, you can install as many different versions of the > unbundled product as you want. This case is about choosing one > version to bundle into the OS as the default compiler. This case *should* be about setting up a structure that allows for both the bundled and unbundled compilers to coexist and evolve in a coordinated way. The customer doesn't care one bit about whether Sun considers a particular version to be bundled or not; history shows that Sun changes its mind often about this sort of thing. The architecture shouldn't be tied to such marketing distinctions either. A scheme like the current studio compilers one would work well: /usr/suncc/$version/[bin, lib, man, ...] A separate should be used to manage the concept of "default". Links to /usr/bin, management of a /usr/suncc/latest symlink, whatever should all be architecturally independent from the delivery of a versioned compiler instance. -John From Douglas.Walls@Sun.COM Thu Jan 15 11:22:32 2009 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 n0FJMVdm025579 for ; Thu, 15 Jan 2009 11:22:32 -0800 (PST) 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 n0FJMTXC012598 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 19:22:30 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 <0KDJ00L0V1TH3P00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:22:29 -0700 (MST) 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 <0KDJ007UA1TGH9C0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:22:28 -0700 (MST) 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 n0FJMSwI000260 for ; Thu, 15 Jan 2009 11:22:28 -0800 (PST) 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 <0KDJ00D011MTFS00@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 11:22:28 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.18.182]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00AQV1T90820@fe-sfbay-10.sun.com>; Thu, 15 Jan 2009 11:22:26 -0800 (PST) Date: Thu, 15 Jan 2009 11:22:29 -0800 From: Douglas Walls Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <20090115175203.GT2706@mumak.SFBay.Sun.COM> Sender: Douglas.Walls@Sun.COM To: Danek Duvall Cc: Raj Prakash , LSARC-ext@Sun.COM, Chris.Quenelle@Sun.COM, David.Ford@Sun.COM Message-id: <496F8CF5.7090907@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 2468 Danek Duvall wrote: > On Wed, Jan 14, 2009 at 01:50:13PM -0800, Douglas Walls wrote: > >> - The design of the Sun compilers precludes just installing >> them into /usr/bin, /usr/lib, etc. without significant >> redesign. > > Could you talk about that briefly? I'm guessing that you assume that an > executable can find things by looking at its realpath (or equivalent) and > fetching ../lib/, and that putting all those s into > /usr/lib would be messy, but perhaps there's something else going on. > > What would be the work involved to fix that, perhaps even just noting that > when the executable is in /usr/bin, the auxiliary bits can be found in > /usr/lib/suncc (or whatever). Not for this case, perhaps, but for a future > update of the bundled compilers. You understand the basic concept. The binaries and libraries that make up the compilation system need to be relative to each other. The compilation system for example consists of drivers like "cc", which invokes components acomp, iropt, ir2hf, ube, etc. Those binaries need to live in relative locations to each other. Same with support libraries and other files. Many of the binaries like those mentioned do not belong in /usr/bin, i.e. on the user's path. So reorganizing this is a significant job for which we do not have an estimate. This ARC case is about bundling the Sun C and C++ compilers in Nevada for all distributions of Solaris in a reasonable time without reoganizing/redesigning those compilers. Such a reorganization of the compiler so to place the binaries cc, CC, etc. in /usr/bin would be the subject of another case. > >> We need a location into which to install the >> compiler components, with symlinks to those components >> installed in /usr/bin and /usr/share/man. The delivery will >> install the bundled compiler collection components into >> /usr/compilers/{bin,lib,...}, > > Why /usr/compilers, then, rather than something under /usr/lib/? If ARC members recommend we install the bundled compilers in /usr/lib/ that is fine by us, it's just a name and a path. We chose /usr/compilers as it was not clear to us that we want another WOS in /usr/lib. > And the man pages should be able to go directly in /usr/share/man, no? If we do the reoganization of the compiler for binaries in /usr/bin with support files in /usr/lib/, then yes man pages go directly in /usr/share/man. > > Danek From danek.duvall@sun.com Thu Jan 15 11:30:03 2009 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 n0FJU39v025994 for ; Thu, 15 Jan 2009 11:30:03 -0800 (PST) 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 n0FJU0PI017662 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 11:30:03 -0800 (PST) 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 <0KDJ00M0L2628K00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:30:02 -0700 (MST) 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 <0KDJ0079H261H6D0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:30:01 -0700 (MST) 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 n0FJU1Kc032918; Thu, 15 Jan 2009 11:30:01 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FJVmU3021715; Thu, 15 Jan 2009 11:31:48 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FJVmDT021714; Thu, 15 Jan 2009 11:31:48 -0800 (PST) Date: Thu, 15 Jan 2009 11:31:48 -0800 From: Danek Duvall Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496F8CF5.7090907@sun.com> To: Douglas Walls Cc: Raj Prakash , LSARC-ext@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <20090115193148.GY2706@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 856 On Thu, Jan 15, 2009 at 11:22:29AM -0800, Douglas Walls wrote: >> Why /usr/compilers, then, rather than something under /usr/lib/? > > If ARC members recommend we install the bundled compilers in > /usr/lib/ > that is fine by us, it's just a name and a path. We chose /usr/compilers > as it was not clear to us that we want another WOS in /usr/lib. I'm not sure that there's any real definition, but /usr/ seems to be used for components which have Public interfaces beneath that directory -- their own bin, man, lib, and so forth, which you'd actually put into your $PATH, $MANPATH, -L, etc. If there are no user-serviceable parts there, though (or all of the ones you'd want to use are linked into the standard places) then /usr/lib/ seems like the place to go. But others may have a different understanding. Danek From Douglas.Walls@sun.com Thu Jan 15 11:46:08 2009 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 n0FJk8Yu026545 for ; Thu, 15 Jan 2009 11:46:08 -0800 (PST) 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 n0FJk4P0025288 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 11:46:07 -0800 (PST) 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 <0KDJ000192WVNV00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:46:07 -0700 (MST) 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 <0KDJ007322WUHHD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:46:07 -0700 (MST) 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 n0FJk6fl026588 for ; Thu, 15 Jan 2009 11:46:06 -0800 (PST) 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 <0KDJ003012P8Q300@fe-sfbay-09.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 11:46:06 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.18.182]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00JV82WSIOG0@fe-sfbay-09.sun.com>; Thu, 15 Jan 2009 11:46:06 -0800 (PST) Date: Thu, 15 Jan 2009 11:46:11 -0800 From: Douglas Walls Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115193148.GY2706@mumak.SFBay.Sun.COM> Sender: Douglas.Walls@sun.com To: Danek Duvall Cc: Raj Prakash , LSARC-ext@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <496F9283.4050106@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1151 Danek Duvall wrote: > On Thu, Jan 15, 2009 at 11:22:29AM -0800, Douglas Walls wrote: > >>> Why /usr/compilers, then, rather than something under /usr/lib/? >> If ARC members recommend we install the bundled compilers in >> /usr/lib/ >> that is fine by us, it's just a name and a path. We chose /usr/compilers >> as it was not clear to us that we want another WOS in /usr/lib. > > I'm not sure that there's any real definition, but /usr/ seems to > be used for components which have Public interfaces beneath that directory > -- their own bin, man, lib, and so forth, which you'd actually put into > your $PATH, $MANPATH, -L, etc. If there are no user-serviceable parts > there, though (or all of the ones you'd want to use are linked into the > standard places) then /usr/lib/ seems like the place to go. But > others may have a different understanding. Ah, yes thanks for that clarification. /usr/compilers has such public interfaces, i.e. a bin, lib and man directory intended to be placed in $PATH and $MANPATH when necessary to override whatever the current defaults are in /usr/bin /usr/man. > > Danek From Douglas.Walls@sun.com Thu Jan 15 11:48:00 2009 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 n0FJlxLc026566 for ; Thu, 15 Jan 2009 11:47:59 -0800 (PST) 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 n0FJltsD027917 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 19:47:58 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 <0KDJ00D052ZWHX00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:47:56 -0800 (PST) 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 <0KDJ00KI42ZVQR70@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:47:55 -0800 (PST) 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 n0FJlt88003568 for ; Thu, 15 Jan 2009 11:47:55 -0800 (PST) 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 <0KDJ00F012YSMS00@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:47:55 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.18.182]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00AYG2ZI08D0@fe-sfbay-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:47:43 -0800 (PST) Date: Thu, 15 Jan 2009 11:47:49 -0800 From: Douglas Walls Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: Sender: Douglas.Walls@sun.com To: John Plocher Cc: Chris.Quenelle@sun.com, Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <496F92E5.7000205@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: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1638 Though this case is about bundling the Sun C and C++ compilers with Nevada, the case does note how the versions of the unbundled Sun Studio compilers coexist with the bundled compilers and each other. The case also notes how the unbundled Sun Studio compilers can override the links established by the bundled compiler in /usr/bin and links established by other versions of Sun Studio. Douglas John Plocher wrote: > On Thu, Jan 15, 2009 at 9:34 AM, Chris Quenelle wrote: >> In the latest proposal, the bundled compiler binaries are not versioned, >> and neither are the man pages. If you want multiple versions of the >> compilers, you can install as many different versions of the >> unbundled product as you want. This case is about choosing one >> version to bundle into the OS as the default compiler. > > > This case *should* be about setting up a structure that allows for > both the bundled and unbundled compilers to coexist and evolve in a > coordinated way. The customer doesn't care one bit about whether Sun > considers a particular version to be bundled or not; history shows > that Sun changes its mind often about this sort of thing. The > architecture shouldn't be tied to such marketing distinctions either. > > A scheme like the current studio compilers one would work well: > > /usr/suncc/$version/[bin, lib, man, ...] > > A separate should be used to manage the concept of > "default". Links to /usr/bin, management of a /usr/suncc/latest > symlink, whatever should all be architecturally independent from the > delivery of a versioned compiler instance. > > -John From Chris.Quenelle@sun.com Thu Jan 15 11:50:10 2009 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 n0FJo9VP026589 for ; Thu, 15 Jan 2009 11:50:10 -0800 (PST) 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 n0FJo8ku000306 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 11:50:09 -0800 (PST) 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 <0KDJ0001133KY600@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:50:08 -0800 (PST) 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 <0KDJ00HZJ33KQXE0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:50:08 -0800 (PST) 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 n0FJo8Wk027163 for ; Thu, 15 Jan 2009 11:50:08 -0800 (PST) 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 <0KDJ00F012YSMS00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:50:08 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00A1C33H08F0@fe-sfbay-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 15 Jan 2009 11:50:06 -0800 (PST) Date: Thu, 15 Jan 2009 11:47:22 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Sender: Chris.Quenelle@sun.com To: John Plocher Cc: Tom Childers , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Reply-to: Chris.Quenelle@sun.com Message-id: <496F92CA.70209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 1684 John, Do you see a specific need for having multiple compilers installed in /usr? (As opposed to having other compilers in /opt) Keep in mind, Sun also has an unbundled tool suite (Sun Studio) that includes lots of stuff beyond the compilers. The unbundled product is released on Solaris 10, OpenSolaris, and Linux. This makes it a very interesting challenge to deliver a subset of that product into Nevada on a regular basis. --chris John Plocher wrote: > On Thu, Jan 15, 2009 at 9:34 AM, Chris Quenelle wrote: >> In the latest proposal, the bundled compiler binaries are not versioned, >> and neither are the man pages. If you want multiple versions of the >> compilers, you can install as many different versions of the >> unbundled product as you want. This case is about choosing one >> version to bundle into the OS as the default compiler. > > > This case *should* be about setting up a structure that allows for > both the bundled and unbundled compilers to coexist and evolve in a > coordinated way. The customer doesn't care one bit about whether Sun > considers a particular version to be bundled or not; history shows > that Sun changes its mind often about this sort of thing. The > architecture shouldn't be tied to such marketing distinctions either. > > A scheme like the current studio compilers one would work well: > > /usr/suncc/$version/[bin, lib, man, ...] > > A separate should be used to manage the concept of > "default". Links to /usr/bin, management of a /usr/suncc/latest > symlink, whatever should all be architecturally independent from the > delivery of a versioned compiler instance. > > -John From Chris.Quenelle@Sun.COM Thu Jan 15 11:54:38 2009 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 n0FJscbV026885 for ; Thu, 15 Jan 2009 11:54:38 -0800 (PST) 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 n0FJsaTr061270 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 12:54:37 -0700 (MST) 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 <0KDJ0010D3B1GI00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:54:37 -0700 (MST) 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 <0KDJ007ZL3B0H5D0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 12:54:36 -0700 (MST) 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 n0FJsacT004565 for ; Thu, 15 Jan 2009 11:54:36 -0800 (PST) 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 <0KDJ00F012YSMS00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 11:54:36 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ001O23AW4500@fe-sfbay-10.sun.com>; Thu, 15 Jan 2009 11:54:32 -0800 (PST) Date: Thu, 15 Jan 2009 11:51:49 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <20090115193148.GY2706@mumak.SFBay.Sun.COM> Sender: Chris.Quenelle@Sun.COM To: Danek Duvall Cc: Douglas Walls , Raj Prakash , LSARC-ext@Sun.COM, David.Ford@Sun.COM Reply-to: Chris.Quenelle@Sun.COM Message-id: <496F93D5.5060805@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 1190 Danek Duvall wrote: > On Thu, Jan 15, 2009 at 11:22:29AM -0800, Douglas Walls wrote: > >>> Why /usr/compilers, then, rather than something under /usr/lib/? >> If ARC members recommend we install the bundled compilers in >> /usr/lib/ >> that is fine by us, it's just a name and a path. We chose /usr/compilers >> as it was not clear to us that we want another WOS in /usr/lib. > > I'm not sure that there's any real definition, but /usr/ seems to > be used for components which have Public interfaces beneath that directory > -- their own bin, man, lib, and so forth, which you'd actually put into > your $PATH, $MANPATH, -L, etc. If there are no user-serviceable parts > there, though (or all of the ones you'd want to use are linked into the > standard places) then /usr/lib/ seems like the place to go. But > others may have a different understanding. > > Danek I think this is a good guideline. Unfortunately, the current delivery is a strange mix of the two. Once we get our directory structure sorted out (for the unbundled product and the bundled compilers), then I think a lot of our files could go under a /usr/lib subdirectory. --chris From danek.duvall@sun.com Thu Jan 15 13:15:08 2009 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 n0FLF8fJ016478 for ; Thu, 15 Jan 2009 13:15:08 -0800 (PST) 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 n0FLF265035801 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 14:15:07 -0700 (MST) 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 <0KDJ006057162Z00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 13:15:06 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001P9716US40@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 13:15:06 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FLF6ri056413; Thu, 15 Jan 2009 13:15:06 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FLGsXM023336; Thu, 15 Jan 2009 13:16:54 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLGsWM023335; Thu, 15 Jan 2009 13:16:54 -0800 (PST) Date: Thu, 15 Jan 2009 13:16:54 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <496F9283.4050106@sun.com> To: Douglas Walls Cc: Raj Prakash , LSARC-ext@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <20090115211654.GZ2706@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: <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 479 On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: > Ah, yes thanks for that clarification. /usr/compilers has such public > interfaces, i.e. a bin, lib and man directory intended to be placed in > $PATH and $MANPATH when necessary to override whatever the current > defaults are in /usr/bin /usr/man. But if you're putting links for everything in /usr/bin and /usr/share/man, and there is only the single version, then why would you set PATH and MANPATH? Danek From Nicolas.Williams@sun.com Thu Jan 15 13:35:36 2009 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 n0FLZZt6016998 for ; Thu, 15 Jan 2009 13:35:36 -0800 (PST) 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 n0FLZSiZ018636; Fri, 16 Jan 2009 05:35:31 +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 <0KDJ004037Z66400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:35:30 -0800 (PST) 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 <0KDJ00KG07Z5QRD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:35:30 -0800 (PST) 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 n0FLYMr1016786; Thu, 15 Jan 2009 15:34:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLYMf8016785; Thu, 15 Jan 2009 15:34:22 -0600 (CST) Date: Thu, 15 Jan 2009 15:34:22 -0600 From: Nicolas Williams Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115211654.GZ2706@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Douglas Walls , Chris.Quenelle@sun.com, LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090115213422.GU884@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: <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.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: 620 On Thu, Jan 15, 2009 at 01:16:54PM -0800, Danek Duvall wrote: > On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: > > > Ah, yes thanks for that clarification. /usr/compilers has such public > > interfaces, i.e. a bin, lib and man directory intended to be placed in > > $PATH and $MANPATH when necessary to override whatever the current > > defaults are in /usr/bin /usr/man. > > But if you're putting links for everything in /usr/bin and /usr/share/man, > and there is only the single version, then why would you set PATH and > MANPATH? To pick one from multiple versions. Like we do with Perl5, say. From danek.duvall@Sun.COM Thu Jan 15 13:41:05 2009 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 n0FLf4ub017041 for ; Thu, 15 Jan 2009 13:41:05 -0800 (PST) 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 n0FLex08021088 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 16 Jan 2009 05:41:03 +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 <0KDJ0071188DMW00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 13:41:01 -0800 (PST) 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 <0KDJ001EM88BUO50@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 13:40:59 -0800 (PST) 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 n0FLexav061830; Thu, 15 Jan 2009 13:40:59 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FLgla4023739; Thu, 15 Jan 2009 13:42:47 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLglkW023738; Thu, 15 Jan 2009 13:42:47 -0800 (PST) Date: Thu, 15 Jan 2009 13:42:47 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115213422.GU884@Sun.COM> To: Nicolas Williams Cc: Douglas Walls , Chris.Quenelle@Sun.COM, LSARC-ext@Sun.COM, David.Ford@Sun.COM, Raj Prakash Message-id: <20090115214247.GB2706@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: <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <20090115213422.GU884@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 863 On Thu, Jan 15, 2009 at 03:34:22PM -0600, Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 01:16:54PM -0800, Danek Duvall wrote: > > On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: > > > > > Ah, yes thanks for that clarification. /usr/compilers has such public > > > interfaces, i.e. a bin, lib and man directory intended to be placed in > > > $PATH and $MANPATH when necessary to override whatever the current > > > defaults are in /usr/bin /usr/man. > > > > But if you're putting links for everything in /usr/bin and /usr/share/man, > > and there is only the single version, then why would you set PATH and > > MANPATH? > > To pick one from multiple versions. Like we do with Perl5, say. Yes, but to quote from the revised fast-track: There will not be multiple versions, there will only be one set of bundled compilers. Danek From Nicolas.Williams@sun.com Thu Jan 15 13:50:00 2009 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 n0FLnxrP017147 for ; Thu, 15 Jan 2009 13:49:59 -0800 (PST) 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 n0FLnr06007687; Thu, 15 Jan 2009 21:49:55 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 <0KDJ008098N57F00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 13:49:53 -0800 (PST) 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 <0KDJ001WR8N5V060@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 13:49:53 -0800 (PST) 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 n0FLmknO016899; Thu, 15 Jan 2009 15:48:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLmkxa016898; Thu, 15 Jan 2009 15:48:46 -0600 (CST) Date: Thu, 15 Jan 2009 15:48:46 -0600 From: Nicolas Williams Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115214247.GB2706@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Douglas Walls , Chris.Quenelle@sun.com, LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090115214846.GW884@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: <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <20090115213422.GU884@Sun.COM> <20090115214247.GB2706@mumak.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: 1325 On Thu, Jan 15, 2009 at 01:42:47PM -0800, Danek Duvall wrote: > On Thu, Jan 15, 2009 at 03:34:22PM -0600, Nicolas Williams wrote: > > > On Thu, Jan 15, 2009 at 01:16:54PM -0800, Danek Duvall wrote: > > > On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: > > > > > > > Ah, yes thanks for that clarification. /usr/compilers has such public > > > > interfaces, i.e. a bin, lib and man directory intended to be placed in > > > > $PATH and $MANPATH when necessary to override whatever the current > > > > defaults are in /usr/bin /usr/man. > > > > > > But if you're putting links for everything in /usr/bin and /usr/share/man, > > > and there is only the single version, then why would you set PATH and > > > MANPATH? > > > > To pick one from multiple versions. Like we do with Perl5, say. > > Yes, but to quote from the revised fast-track: > > There will not be multiple versions, there will only be one set of > bundled compilers. Oh, silly me, I thought that because LSARC/2008/776 proposed to deliver GNU compilers into /usr/compilers/gcc that this one would too. I guess I have to read the rest of this thread (or slink away -- it seems daunting). Our build machines have multiple versions of Sun Studio installed. Why would one not want the this case to allow the same??? Nico -- From john.plocher@gmail.com Thu Jan 15 14:17:43 2009 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 n0FMHglX017960 for ; Thu, 15 Jan 2009 14:17:43 -0800 (PST) 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 n0FMHU9G022544; Thu, 15 Jan 2009 22:17:39 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 <0KDJ0090T9XBWH00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:17:35 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001WW9X9UP70@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:17:33 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FMHXwX016269; Thu, 15 Jan 2009 22:17:33 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-1656893; Thu, 15 Jan 2009 22:17:33 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-46469950; Thu, 15 Jan 2009 22:17:32 +0000 (Z) Received: from rv-out-0506.google.com ([209.85.198.238] [209.85.198.238]) by relay4i.sun.com with ESMTP id BT-MMP-11384929; Thu, 15 Jan 2009 22:17:32 +0000 (Z) Received: by rv-out-0506.google.com with SMTP id f9so34291rvb.4 for ; Thu, 15 Jan 2009 14:16:41 -0800 (PST) Received: by 10.141.113.3 with SMTP id q3mr836133rvm.245.1232057801226; Thu, 15 Jan 2009 14:16:41 -0800 (PST) Date: Thu, 15 Jan 2009 14:16:41 -0800 From: John Plocher Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496F92CA.70209@Sun.COM> To: Chris.Quenelle@sun.com Cc: Tom Childers , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y3+thK+UEbjYsMfhQa0ww8+9FRSmjU7gtHUaHE5twNM=; b=WuqWBZwUNScZzyf6XRRFapisKkJzTM81k5S9ARMWxz2+qLcUwTUeANOOuSMYBWJXNT L74A6tzV+Xt7tOR/U6xYvdmbKyOqbowmLewavqRmNF/xxYBTcp/EGlSTIWGSczm6onWW 25aCUQDhRbs4z4svIk32dijk2GegJNSKzdZ8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ENKC/Zbt5qTCcQdhFc82lGHjm0LFsbHtCscCnkxQBI2pF0LLjUzkd+GIxk87X+bGPG ktqu/+GAZA+UPcX3QT9udaU0Nh8Nr/9dbs/rjdjhyDUHSQNWoElW8Rub3r7Z4/x07G42 p8SyARSW+XWHj+n9HmR0toTlc6yC2nl4uaqho= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.638sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> Status: RO Content-Length: 1486 On Thu, Jan 15, 2009 at 11:47 AM, Chris Quenelle wrote: > multiple compilers in /usr This thread suggested at least two, and I can see more: the bundled one and the express one; we also have the version that can be used to compile OpenSolaris -vs- the one shipped by the compiler team, ... > very interesting challenge to deliver a subset of that product > into Nevada on a regular basis. ... which is why I suggested coming up with an overarching architecture... It doesn't have to be an "interesting challenge". It *could* be as simple as choosing which packages to co-bundle and install. The whole bundled/unbundled, /usr -vs- /opt thing is not set in stone. You could come up with another, better scheme. The problem I see in this case is that it is built on a lot of history, it assumes that some things can and other things can't be changed, and it has some vision for a future that changes based on who is doing the talking. My suggestion is to take a step back and ask what the best possible result might look like. When /I/ do that, I get something that smells a lot more like the Java JDK mechanism (everything under /usr/jdk/$version, with /usr/java being a symlink to the default version) than this current "some stuff in /usr, but other stuff that is the same, but different in /opt, depending on what time of day it is in Sun's compiler marketing department" :-) Of course, /your/ mileage may vary, may contain nuts, etc... -John From Douglas.Walls@sun.com Thu Jan 15 14:25:44 2009 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 n0FMPhXv018260 for ; Thu, 15 Jan 2009 14:25:44 -0800 (PST) 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 n0FMPgU3022198 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 14:25:43 -0800 (PST) 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 <0KDJ00G0JAAVJ000@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 15:25:43 -0700 (MST) 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 <0KDJ00324AAU0RC0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 15:25:42 -0700 (MST) 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 n0FMPgQx018080 for ; Thu, 15 Jan 2009 14:25:42 -0800 (PST) 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 <0KDJ00F019VWGW00@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 14:25:42 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.18.182]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00GXRAAS5S30@fe-sfbay-10.sun.com>; Thu, 15 Jan 2009 14:25:42 -0800 (PST) Date: Thu, 15 Jan 2009 14:25:46 -0800 From: Douglas Walls Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115214846.GW884@Sun.COM> Sender: Douglas.Walls@sun.com To: Nicolas Williams Cc: Danek Duvall , Chris.Quenelle@sun.com, LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <496FB7EA.4090609@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: <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <20090115213422.GU884@Sun.COM> <20090115214247.GB2706@mumak.SFBay.Sun.COM> <20090115214846.GW884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 2675 Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 01:42:47PM -0800, Danek Duvall wrote: >> On Thu, Jan 15, 2009 at 03:34:22PM -0600, Nicolas Williams wrote: >> >>> On Thu, Jan 15, 2009 at 01:16:54PM -0800, Danek Duvall wrote: >>>> On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: >>>> >>>>> Ah, yes thanks for that clarification. /usr/compilers has such public >>>>> interfaces, i.e. a bin, lib and man directory intended to be placed in >>>>> $PATH and $MANPATH when necessary to override whatever the current >>>>> defaults are in /usr/bin /usr/man. >>>> But if you're putting links for everything in /usr/bin and /usr/share/man, >>>> and there is only the single version, then why would you set PATH and >>>> MANPATH? >>> To pick one from multiple versions. Like we do with Perl5, say. >> Yes, but to quote from the revised fast-track: >> >> There will not be multiple versions, there will only be one set of >> bundled compilers. > > Oh, silly me, I thought that because LSARC/2008/776 proposed to deliver > GNU compilers into /usr/compilers/gcc that this one would too. > I guess I have to read the rest of this thread (or slink away -- it > seems daunting). Yes. You'll find the case sponsor announced ... "Based on the valuable feedback, the two projects have agreed not to co-locate their files under /usr/compilers." > > Our build machines have multiple versions of Sun Studio installed. Why > would one not want the this case to allow the same??? It does allow the same ... this case says: 4. Technical Description: 4.1. Details: - The design of the Sun compilers precludes just installing them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components installed in /usr/bin and /usr/share/man. The delivery will install the bundled compiler collection components into /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'compilers' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There will not be multiple versions, there will only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/sunstudio13, /opt/sunstudio14, etc.. Note Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these would then override the links of this bundled compiler as it does previously installed versions of Sun Studio. > > Nico From Douglas.Walls@Sun.COM Thu Jan 15 14:26:00 2009 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 n0FMQ0fi018279 for ; Thu, 15 Jan 2009 14:26:00 -0800 (PST) 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 n0FMQ0Hi022304 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 14:26:00 -0800 (PST) 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 <0KDJ00A03ABBFD00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 14:25:59 -0800 (PST) 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 <0KDJ001GHABBUS80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 14:25:59 -0800 (PST) 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 n0FMPx1m023299 for ; Thu, 15 Jan 2009 14:25:59 -0800 (PST) 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 <0KDJ00F019ZO3E00@fe-sfbay-09.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 14:25:59 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.18.182]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00DE2AAP8IA0@fe-sfbay-09.sun.com>; Thu, 15 Jan 2009 14:25:38 -0800 (PST) Date: Thu, 15 Jan 2009 14:25:44 -0800 From: Douglas Walls Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090115211654.GZ2706@mumak.SFBay.Sun.COM> Sender: Douglas.Walls@Sun.COM To: Danek Duvall Cc: Raj Prakash , LSARC-ext@Sun.COM, Chris.Quenelle@Sun.COM, David.Ford@Sun.COM Message-id: <496FB7E8.2000504@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: <496B99E0.8020808@Sun.COM> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 904 Danek Duvall wrote: > On Thu, Jan 15, 2009 at 11:46:11AM -0800, Douglas Walls wrote: > >> Ah, yes thanks for that clarification. /usr/compilers has such public >> interfaces, i.e. a bin, lib and man directory intended to be placed in >> $PATH and $MANPATH when necessary to override whatever the current >> defaults are in /usr/bin /usr/man. > > But if you're putting links for everything in /usr/bin and /usr/share/man, > and there is only the single version, then why would you set PATH and > MANPATH? There is only one "bundled" version. There can be multiple versions of Sun compilers by installing a version of the unbundled Sun Studio also ... So, if you have installed the unbundled Sun Studio, like the upcoming Sun Studio 13, with its package that overrides the links in /usr/bin and /usr/share/man, and you have some reason you want the bundled compiler back on your path. > > Danek From Nicolas.Williams@sun.com Thu Jan 15 14:33:37 2009 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 n0FMXaQU018609 for ; Thu, 15 Jan 2009 14:33:37 -0800 (PST) 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 n0FMXUQK000745; Thu, 15 Jan 2009 22:33:33 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 <0KDJ00B05ANVPC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:33:31 -0800 (PST) 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 <0KDJ006WPANU78B0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:33:30 -0800 (PST) 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 n0FMWLDu017240; Thu, 15 Jan 2009 16:32:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FMWL2P017239; Thu, 15 Jan 2009 16:32:21 -0600 (CST) Date: Thu, 15 Jan 2009 16:32:21 -0600 From: Nicolas Williams Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <496FB7EA.4090609@sun.com> To: Douglas Walls Cc: Danek Duvall , Chris.Quenelle@sun.com, LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090115223221.GC884@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: <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <20090115213422.GU884@Sun.COM> <20090115214247.GB2706@mumak.SFBay.Sun.COM> <20090115214846.GW884@Sun.COM> <496FB7EA.4090609@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: 1267 On Thu, Jan 15, 2009 at 02:25:46PM -0800, Douglas Walls wrote: > Nicolas Williams wrote: > >Oh, silly me, I thought that because LSARC/2008/776 proposed to deliver > >GNU compilers into /usr/compilers/gcc that this one would too. > >I guess I have to read the rest of this thread (or slink away -- it > >seems daunting). > > Yes. You'll find the case sponsor announced ... > > "Based on the valuable feedback, the two projects have agreed not to > co-locate their files under /usr/compilers." That says nothing as to why have one version of the bundled compilers but N versions of gcc. > >Our build machines have multiple versions of Sun Studio installed. Why > >would one not want the this case to allow the same??? > > It does allow the same ... this case says: Well, OK, so other versions will be installed in /opt as unbundled products. Weird. That's not what we've done with other parts of the system, but I don't mind too much. > 4. Technical Description: > 4.1. Details: > > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant But only the /usr/bin parts are public interfaces, right? If so then we only need /usr/lib/compilers + links from /usr/bin into it. From Nicolas.Williams@sun.com Thu Jan 15 14:45:08 2009 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 n0FMj79k018711 for ; Thu, 15 Jan 2009 14:45:07 -0800 (PST) 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 n0FMj2Al013998; Thu, 15 Jan 2009 15:45:06 -0700 (MST) 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 <0KDJ00B09B76MQ00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:45:06 -0800 (PST) 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 <0KDJ001Q5B75UQ90@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:45:05 -0800 (PST) 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 n0FMaRmO017268; Thu, 15 Jan 2009 16:36:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FMaRvw017267; Thu, 15 Jan 2009 16:36:27 -0600 (CST) Date: Thu, 15 Jan 2009 16:36:27 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: To: John Plocher Cc: Chris.Quenelle@sun.com, Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090115223626.GD884@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: <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@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: 900 On Thu, Jan 15, 2009 at 02:16:41PM -0800, John Plocher wrote: > My suggestion is to take a step back and ask what the best possible > result might look like. > > When /I/ do that, I get something that smells a lot more like the Java > JDK mechanism (everything under /usr/jdk/$version, with /usr/java > being a symlink to the default version) than this current "some stuff > in /usr, but other stuff that is the same, but different in /opt, > depending on what time of day it is in Sun's compiler marketing > department" :-) Of course, /your/ mileage may vary, may contain nuts, > etc... +1. For N versions of the Sun Studio C/C++/dbx Collection deliver N sets of pkgs, all installing into distinct locations below /usr/lib. And also deliver pkgs for selecting the default version: one pkg installs links, or one pkg installs shell scripts that lookup which version to use using a config file. From daleg@elemental.org Thu Jan 15 14:58:16 2009 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 n0FMwFem019277 for ; Thu, 15 Jan 2009 14:58:16 -0800 (PST) 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 n0FMw80X025366; Fri, 16 Jan 2009 06:58:11 +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 <0KDJ00C2PBSZHI00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:58:11 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001CVBSYUNB0@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:58:10 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FMoFab015924; Thu, 15 Jan 2009 22:58:10 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay12i.sun.com with ESMTP id BT-MMP-414659; Thu, 15 Jan 2009 22:58:10 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-122580; Thu, 15 Jan 2009 22:58:09 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1ib.sun.com with ESMTP id BT-MMP-20429100; Thu, 15 Jan 2009 22:58:09 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0FMw8QA002313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Jan 2009 17:58:08 -0500 (EST) Date: Thu, 15 Jan 2009 17:58:07 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: To: John Plocher Cc: Chris.Quenelle@sun.com, Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <691B419B-971C-4729-87B3-9D34CE3E1631@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Thu, 15 Jan 2009 17:58:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.117sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> Status: RO Content-Length: 685 On Jan 15, 2009, at 5:16 PM, John Plocher wrote: > My suggestion is to take a step back and ask what the best possible > result might look like. > > When /I/ do that, I get something that smells a lot more like the Java > JDK mechanism (everything under /usr/jdk/$version, with /usr/java > being a symlink to the default version) than this current "some stuff > in /usr, but other stuff that is the same, but different in /opt, > depending on what time of day it is in Sun's compiler marketing > department" :-) Of course, /your/ mileage may vary, may contain nuts, > etc... I think I first suggested this... weeks ago? Nice to hear an echo in here. +1, not that it counts. /dale From Chris.Quenelle@sun.com Thu Jan 15 15:47:36 2009 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 n0FNlZuY020127 for ; Thu, 15 Jan 2009 15:47:35 -0800 (PST) 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 n0FNlMSp016767 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 16 Jan 2009 07:47:34 +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 <0KDJ0020TE384T00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 16:47:32 -0700 (MST) 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 <0KDJ000TYE37IT00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 16:47:32 -0700 (MST) 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 n0FNlVw2002475 for ; Thu, 15 Jan 2009 15:47:31 -0800 (PST) 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 <0KDJ00001E0EIN00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 15:47:31 -0800 (PST) Received: from [129.146.86.147] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ008PNE37HQ40@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 15:47:31 -0800 (PST) Date: Thu, 15 Jan 2009 15:44:47 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: Sender: Chris.Quenelle@sun.com To: John Plocher Cc: Tom Childers , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Reply-to: Chris.Quenelle@sun.com Message-id: <496FCA6F.3090909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 1157 John Plocher wrote: > On Thu, Jan 15, 2009 at 11:47 AM, Chris Quenelle wrote: >> multiple compilers in /usr > > This thread suggested at least two, and I can see more: the bundled > one and the express one; we also have the version that can be used to > compile OpenSolaris -vs- the one shipped by the compiler team, ... This case is not proposing to deliver multiple compilers into Nevada, and it's not proposing to create infrastructure in case we need to start delivering multiple versions later. If you can help us establish that this should be a requirement, then we can fill in the details of how to do it in a sane way. But the delivery of multiple versions doesn't seem to be required by the current business justification in the case: 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. Please back up a step and help me understand why we need to deliver parallel versions through Nevada, and not just through our existing channels. --chris From daleg@elemental.org Thu Jan 15 17:01:52 2009 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 n0G11ptI008985 for ; Thu, 15 Jan 2009 17:01:52 -0800 (PST) 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 n0G11U6E020976; Fri, 16 Jan 2009 09:01:47 +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 <0KDJ00805HIXYU00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 17:01:45 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00EKFHIWDL60@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 17:01:45 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0G0vtw5024727; Fri, 16 Jan 2009 01:01:44 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-1660740; Fri, 16 Jan 2009 01:01:44 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-46601635; Fri, 16 Jan 2009 01:01:43 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay4i.sun.com with ESMTP id BT-MMP-23365685; Fri, 16 Jan 2009 01:01:42 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0G11fpX009537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Jan 2009 20:01:41 -0500 (EST) Date: Thu, 15 Jan 2009 20:01:40 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496FCA6F.3090909@Sun.COM> To: Chris.Quenelle@sun.com Cc: John Plocher , Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <1288876A-B2B6-43DD-99A0-9EE463DB1510@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Thu, 15 Jan 2009 20:01:41 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.972sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496B714A.5040407@sun.com> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> <496FCA6F.3090909@Sun.COM> Status: RO Content-Length: 3071 On Jan 15, 2009, at 6:44 PM, Chris Quenelle wrote: > Please back up a step and help me understand why we need to deliver > parallel versions through Nevada, and not just through our existing > channels. I honestly don't know why I, myself, are taking such a interest in this case, but if I had an idea it might be because I and perhaps a few others are taking the long view based on past experience. But as you urge, let's put aside implementation details for a moment and focus on the concept. Hopefully I can articulate my argument well enough, so here goes: You know, compilers (or suites of them) are a menagerie in their own special way, different from programs such as 'ls', 'sed', 'dc', and 'vax'. Devs tend to stick to a specific Major version (and the more pedantic, a particular Minor version) and upgrade only when arbitrary circumstances require it. When it does come time move to a successive compiler version, the new version has to co-exist with the prior one for at least some amount of time. GCC's way of handling this is with appropriately-named executables, command-line flags, and version- specific directories. Unbundled Sun Studio's way is to keep all of a Major version in its own tree under /opt. This case requests to bundle a subset of the unbundled Sun Studio suite directly inside ON. Excellent. For C/C++, we would have arguably the best compilers readily present in the default $PATH. No neophyte users having to learn that they need to add /opt/whatever/bin to their $PATH and thus short-circuiting any "But in Linux..." quips. But! ...but what is the real utility and maintainability of doing this given the described culture that exists around compilers? Choosing what version of Sun Studio goes into ON might be easy now, but what about in the future when we will have to *replace it* (not supplement it) with Sun Studio 16? How will updates/patches be reconciled between the bundled and unbundled variants? Take these questions and pile the key one on top - "How would users react to that?" Okay, so the response would be "Well, then install the unbundled full version of Sun Studio." All well and good, and without question the user would definitely be getting the bits he/she desires. But then what of the bundled Sun Studio that continues to sit around in /usr/ bin and /usr/compilers ? It becomes a vestigial appendage sitting on prime realestate. The user could of course remove it, but then where's the win in that? The intent of this case would then cease to offer any benefit to the user and we're back to square 1. So I think that some of us are urging a little architectural and usability foresight to be applied here. Nothing irks users (myself included) more than having to do a package and $PATH dance to make things "right." Seasoned vets such as ourselves might roll our eyes and say "figure it out and fix your path, ya scab" but we must remember who we're trying to attract to OpenSolaris and what platforms they're coming from. /dale From danek.duvall@Sun.COM Thu Jan 15 17:10:58 2009 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 n0G1AwX8009081 for ; Thu, 15 Jan 2009 17:10:58 -0800 (PST) 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 n0G1Aqkl007632 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 15 Jan 2009 17:10:57 -0800 (PST) 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 <0KDJ00A1BHY8PN00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 18:10:56 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ000CVHY5IO50@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 15 Jan 2009 18:10:53 -0700 (MST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0G1ArHi023496; Thu, 15 Jan 2009 17:10:53 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0G1CfUV026716; Thu, 15 Jan 2009 17:12:41 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0G1Cfxg026715; Thu, 15 Jan 2009 17:12:41 -0800 (PST) Date: Thu, 15 Jan 2009 17:12:36 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <496FB7E8.2000504@sun.com> To: Douglas Walls Cc: Raj Prakash , LSARC-ext@Sun.COM, Chris.Quenelle@Sun.COM, David.Ford@Sun.COM Message-id: <20090116011236.GE2706@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: <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 833 On Thu, Jan 15, 2009 at 02:25:44PM -0800, Douglas Walls wrote: > So, if you have installed the unbundled Sun Studio, like the upcoming Sun > Studio 13, with its package that overrides the links in /usr/bin and > /usr/share/man, and you have some reason you want the bundled compiler > back on your path. Um. I think that's a "don't do that" scenario. It's not terribly clear to me why you'd not just uninstall the unbundled symlink package and reinstall the bundled symlink package (or however those links get rebuilt -- I don't recall you having a separate package for those, which would then preclude the unbundled symlink package from being installed on the system at the same time as the bundled compilers). If you really want to have ultimate flexibility with compiler versions, just don't install the bundled ones. Danek From Nicolas.Williams@sun.com Thu Jan 15 17:46:57 2009 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 n0G1kuhe009312 for ; Thu, 15 Jan 2009 17:46:57 -0800 (PST) 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 n0G1kp6U011250; Fri, 16 Jan 2009 01:46:52 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 <0KDJ00E03JM3PB00@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 18:46:51 -0700 (MST) 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 <0KDJ000D6JM3IO70@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 18:46:51 -0700 (MST) 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 n0G1cE2i018301; Thu, 15 Jan 2009 19:38:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0G1cDVt018300; Thu, 15 Jan 2009 19:38:13 -0600 (CST) Date: Thu, 15 Jan 2009 19:38:13 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <496FCA6F.3090909@Sun.COM> To: Chris Quenelle Cc: John Plocher , Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090116013813.GO884@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: <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> <496FCA6F.3090909@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: 1910 On Thu, Jan 15, 2009 at 03:44:47PM -0800, Chris Quenelle wrote: > This case is not proposing to deliver multiple compilers into Nevada, > and it's not proposing to create infrastructure in case we need to start > delivering multiple versions later. Er, "bundled" has heretofore meant "integral part of the larger product," and the larger product is "Nevada" in this case. > If you can help us establish that this should be a requirement, then > we can fill in the details of how to do it in a sane way. > But the delivery of multiple versions doesn't seem to be required > by the current business justification in the case: > > 3.3. Business Justification: > Encourage FOSS inclusion into OpenSolaris repositories by > minimizing compiler-related porting effort. > > Provide a bundled set of compilers for any distribution of Solaris. > > Please back up a step and help me understand why we need to deliver > parallel versions through Nevada, and not just through our existing channels. Typically a requirement for multiple versions results from a rate of incompatible change in the bundled product that is too fast relative to the larger products releases. If no part of the compilers are needed at runtime, or if those parts that are are very stable, then there's no need for multiple versions. The rate of incompatible changes to interfaces needed at compile time might still be a problem if too fast, but I also doubt that's the case here. So, looking at it from that point of view there's no need for multiple versions. Of course, looking at it from the point of view of how many Sun Studio versions we've used in Solaris 10 and Nevada development, we know that multiple versions are likely going to be needed. But at least for Solaris consolidations a single bundled version translates into: more build flag days or a need to use the unbunbled versions. Nico -- From Chris.Quenelle@sun.com Fri Jan 16 09:14:38 2009 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 n0GHEbYT003039 for ; Fri, 16 Jan 2009 09:14:38 -0800 (PST) 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 n0GHEVmo020714 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 17 Jan 2009 01:14:36 +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 <0KDK00G01QKB7300@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 09:14:35 -0800 (PST) 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 <0KDK005DJQJZ9DD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 09:14:35 -0800 (PST) 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 n0GHENYr029467 for ; Fri, 16 Jan 2009 09:14:23 -0800 (PST) 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 <0KDK00101PJOO400@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 09:14:23 -0800 (PST) Received: from [129.150.16.77] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK004C1QJELR20@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 09:14:04 -0800 (PST) Date: Fri, 16 Jan 2009 09:14:10 -0800 From: Chris Quenelle Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <1288876A-B2B6-43DD-99A0-9EE463DB1510@elemental.org> Sender: Chris.Quenelle@sun.com To: Dale Ghent Cc: John Plocher , Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <4970C062.30104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496B714A.5040407@sun.com> <18796.44344.585396.842019@manam.TechFak.Uni-Bielefeld.DE> <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> <496FCA6F.3090909@Sun.COM> <1288876A-B2B6-43DD-99A0-9EE463DB1510@elemental.org> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 5187 Dale, You make some assumptions about a group of people you call 'devs', and you are correctly describing a certain class of people, but your description doesn't cover all users of compilers. There are two different kinds of users in this discussion. Sometimes they are the same person wearing two hats at different times of the day, sometimes they are different people. Scenario 1: I download an open source package that I want to try out. I type "configure;make install". What happens? Ideally, you get some binaries and things work. In this scenario, I don't care if my compilers are the same as they were last week, as long as they work. I might not be a full-time software developer, I'm just a person with a Solaris box who wants to add some software to it that's not already in our repository. Scenario 2: I am a full time software developer working on a long-term one-person project or part of a larger group doing development on a software package. I will have clear opinions about whether I want my compiler updated or not. In some cases my software won't be very compiler-dependent, and I'll be happy taking whatever the latest default bundled compiler is. If I get burned by a compiler compatibility issue, or if I know a-priori that I need to use a specific version, or if there are CBE rules for my project, then I will have a specific version of the compiler that I want to use. In this case, I will want to control the version of the compiler separately from my control of the version of the Solaris OS that I am using. Perhaps we should have had more discussion in the one pager about the business justification for doing this, but our intent was clearly towards Scenario #1. Perhaps we should be trying to solve a different problem, but I really think that discussion is not an ARC discussion. If people think we're trying to solve the wrong problem, then let's collect a list of interested parties and take that discussion offline, because at that point we're no longer discussion ARC case that was submitted. Dale Ghent wrote: > On Jan 15, 2009, at 6:44 PM, Chris Quenelle wrote: > >> Please back up a step and help me understand why we need to deliver >> parallel versions through Nevada, and not just through our existing >> channels. > > I honestly don't know why I, myself, are taking such a interest in this > case, but if I had an idea it might be because I and perhaps a few > others are taking the long view based on past experience. > > But as you urge, let's put aside implementation details for a moment and > focus on the concept. Hopefully I can articulate my argument well > enough, so here goes: > > You know, compilers (or suites of them) are a menagerie in their own > special way, different from programs such as 'ls', 'sed', 'dc', and > 'vax'. Devs tend to stick to a specific Major version (and the more > pedantic, a particular Minor version) and upgrade only when arbitrary > circumstances require it. When it does come time move to a successive > compiler version, the new version has to co-exist with the prior one for > at least some amount of time. GCC's way of handling this is with > appropriately-named executables, command-line flags, and > version-specific directories. Unbundled Sun Studio's way is to keep all > of a Major version in its own tree under /opt. > > This case requests to bundle a subset of the unbundled Sun Studio suite > directly inside ON. Excellent. For C/C++, we would have arguably the > best compilers readily present in the default $PATH. No neophyte users > having to learn that they need to add /opt/whatever/bin to their $PATH > and thus short-circuiting any "But in Linux..." quips. But! > > ...but what is the real utility and maintainability of doing this given > the described culture that exists around compilers? Choosing what > version of Sun Studio goes into ON might be easy now, but what about in > the future when we will have to *replace it* (not supplement it) with > Sun Studio 16? How will updates/patches be reconciled between the > bundled and unbundled variants? Take these questions and pile the key > one on top - "How would users react to that?" > > Okay, so the response would be "Well, then install the unbundled full > version of Sun Studio." All well and good, and without question the user > would definitely be getting the bits he/she desires. But then what of > the bundled Sun Studio that continues to sit around in /usr/bin and > /usr/compilers ? It becomes a vestigial appendage sitting on prime > realestate. The user could of course remove it, but then where's the win > in that? The intent of this case would then cease to offer any benefit > to the user and we're back to square 1. > > So I think that some of us are urging a little architectural and > usability foresight to be applied here. Nothing irks users (myself > included) more than having to do a package and $PATH dance to make > things "right." Seasoned vets such as ourselves might roll our eyes and > say "figure it out and fix your path, ya scab" but we must remember who > we're trying to attract to OpenSolaris and what platforms they're coming > from. > > /dale > > > From Chris.Quenelle@sun.com Fri Jan 16 10:34:35 2009 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 n0GIYYIO005971 for ; Fri, 16 Jan 2009 10:34:35 -0800 (PST) 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 n0GIYUbe003090 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 17 Jan 2009 02:34:33 +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 <0KDK00109U9KP900@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 11:34:32 -0700 (MST) 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 <0KDK0003HU9J9650@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 11:34:32 -0700 (MST) 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 n0GIYVed010988 for ; Fri, 16 Jan 2009 10:34:31 -0800 (PST) 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 <0KDK00D01TO3VZ00@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 10:34:31 -0800 (PST) Received: from [129.150.16.77] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK002QZU9IBIA0@fe-sfbay-09.sun.com>; Fri, 16 Jan 2009 10:34:31 -0800 (PST) Date: Fri, 16 Jan 2009 10:34:43 -0800 From: Chris Quenelle Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090116011236.GE2706@mumak.SFBay.Sun.COM> Sender: Chris.Quenelle@sun.com To: Danek Duvall Cc: Douglas Walls , Raj Prakash , LSARC-ext@sun.com, David.Ford@sun.com Message-id: <4970D343.1030006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2196 Just for clarification: The existing SS12 installer uses a SYSV package with only links in it to optionally place links in /usr/bin for SS12. Solaris 10 packages will normally over-write files that are already on the system. The one-pager also describes a separate package for the symlinks. The existing unbundled SSX in OpenSolaris today doesn't have a separate package for the links, but it should. If this case is implemented, we'll need to deliver future unbundled Sun Studios to OpenSolaris with a separate package for the links. For OpenSolaris, if the bundled compilers install /usr/bin symlinks, then the unbundled compilers would need to stop installing the unbundled links package by default. One reason the user might want to add /usr/compilers/bin to their search path, is if they are on a shared machine that has a different set of links installed in /usr/bin. You can choose to use the bundled compilers, even if the links are not present. Presumably if they are on their own machine they could just install the links package that they want. But if they need to control the compiler selection differently for different projects, on their own machine, they still might want to have unbundled /usr/bin links and put /usr/compilers/bin on their search path at certain times. --chris Danek Duvall wrote: > On Thu, Jan 15, 2009 at 02:25:44PM -0800, Douglas Walls wrote: > >> So, if you have installed the unbundled Sun Studio, like the upcoming Sun >> Studio 13, with its package that overrides the links in /usr/bin and >> /usr/share/man, and you have some reason you want the bundled compiler >> back on your path. > > Um. I think that's a "don't do that" scenario. It's not terribly clear to > me why you'd not just uninstall the unbundled symlink package and reinstall > the bundled symlink package (or however those links get rebuilt -- I don't > recall you having a separate package for those, which would then preclude > the unbundled symlink package from being installed on the system at the > same time as the bundled compilers). > > If you really want to have ultimate flexibility with compiler versions, > just don't install the bundled ones. > > Danek From Chris.Quenelle@sun.com Fri Jan 16 10:46:36 2009 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 n0GIkZlY006215 for ; Fri, 16 Jan 2009 10:46:36 -0800 (PST) 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 n0GIj6rH008853 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 17 Jan 2009 02:46:34 +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 <0KDK00L0HUTITI00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 10:46:30 -0800 (PST) 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 <0KDK00GMXUTGX760@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 10:46:28 -0800 (PST) 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 n0GIkScf017473 for ; Fri, 16 Jan 2009 10:46:28 -0800 (PST) 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 <0KDK00H01UE29100@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 10:46:28 -0800 (PST) Received: from [129.150.16.77] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDK008IXUT8C300@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 16 Jan 2009 10:46:21 -0800 (PST) Date: Fri, 16 Jan 2009 10:46:32 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <20090116013813.GO884@Sun.COM> Sender: Chris.Quenelle@sun.com To: Nicolas Williams Cc: John Plocher , Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <4970D608.7030703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496D307E.4050006@sun.com> <18798.11984.482739.246623@manam.TechFak.Uni-Bielefeld.DE> <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> <496FCA6F.3090909@Sun.COM> <20090116013813.GO884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 582 Nicolas Williams wrote: > Of course, looking at it from the point of view of how many Sun Studio > versions we've used in Solaris 10 and Nevada development, we know that > multiple versions are likely going to be needed. But at least for > Solaris consolidations a single bundled version translates into: more > build flag days or a need to use the unbunbled versions. Since Solaris consolidations will not be using the bundled compiler, I don't see how it causes flag days for anyone. They have to use a specially patched version of SS12 that we deliver as a tarball. --chris From Nicolas.Williams@sun.com Fri Jan 16 11:00:47 2009 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 n0GJ0lST006815 for ; Fri, 16 Jan 2009 11:00:47 -0800 (PST) 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 n0GJ0kf4023890; Fri, 16 Jan 2009 11:00:46 -0800 (PST) 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 <0KDK00H0JVHA4L00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 11:00:46 -0800 (PST) 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 <0KDK00DA7VH9T030@nwk-avmta-1.sfbay.Sun.COM>; Fri, 16 Jan 2009 11:00:45 -0800 (PST) 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 n0GIq7Kr022179; Fri, 16 Jan 2009 12:52:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0GIq7Md022178; Fri, 16 Jan 2009 12:52:07 -0600 (CST) Date: Fri, 16 Jan 2009 12:52:07 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/19/2009] In-reply-to: <4970D608.7030703@sun.com> To: Chris Quenelle Cc: John Plocher , Douglas Walls , Tom Childers , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090116185206.GC884@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: <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <496F73BC.3050303@Sun.COM> <496F92CA.70209@Sun.COM> <496FCA6F.3090909@Sun.COM> <20090116013813.GO884@Sun.COM> <4970D608.7030703@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: 979 On Fri, Jan 16, 2009 at 10:46:32AM -0800, Chris Quenelle wrote: > Nicolas Williams wrote: > > Of course, looking at it from the point of view of how many Sun Studio > > versions we've used in Solaris 10 and Nevada development, we know that > > multiple versions are likely going to be needed. But at least for > > Solaris consolidations a single bundled version translates into: more > > build flag days or a need to use the unbunbled versions. > > Since Solaris consolidations will not be using the bundled > compiler, I don't see how it causes flag days for anyone. > They have to use a specially patched version of SS12 that > we deliver as a tarball. Thanks. I'm convinced that multiple versions of the bundled compilers are not needed (assuming that any relevant bits needed at runtime are stable enough to be Committed interfaces; compile-time interfaces can be Uncommitted I think). Of course, I'm not an ARC member, so my blessing is not necessarily meaningful :) From danek.duvall@sun.com Wed Jan 21 08:05:33 2009 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 n0LG5V7o027699 for ; Wed, 21 Jan 2009 08:05:32 -0800 (PST) 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 n0LG5Mvm004543 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 00:05:31 +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 <0KDT00KGVWP5RK10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 Jan 2009 08:05:29 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDT00HJGWNVL040@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 Jan 2009 08:04:43 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0LG4h7u009595; Wed, 21 Jan 2009 08:04:43 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0LG6XR0012995; Wed, 21 Jan 2009 08:06:33 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0LG6XmA012994; Wed, 21 Jan 2009 08:06:33 -0800 (PST) Date: Wed, 21 Jan 2009 08:06:33 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4970D343.1030006@sun.com> To: Chris Quenelle Cc: Douglas Walls , Raj Prakash , LSARC-ext@sun.com, David.Ford@sun.com Message-id: <20090121160633.GO2706@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: <496E5BCB.4060409@sun.com> <496E5E15.4090400@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1183 On Fri, Jan 16, 2009 at 10:34:43AM -0800, Chris Quenelle wrote: > The one-pager also describes a separate package for the symlinks. Ah, sorry; I missed that. > The existing unbundled SSX in OpenSolaris today doesn't have a separate > package for the links, but it should. Please file a bug on defect.opensolaris.org, under Distribution/opensolaris/packaging. > One reason the user might want to add /usr/compilers/bin to their search > path, is if they are on a shared machine that has a different set of > links installed in /usr/bin. You can choose to use the bundled > compilers, even if the links are not present. Presumably if they are on > their own machine they could just install the links package that they > want. But if they need to control the compiler selection differently for > different projects, on their own machine, they still might want to have > unbundled /usr/bin links and put /usr/compilers/bin on their search path > at certain times. Couldn't they just set their path to have /opt/xxx/bin before /usr/bin to use one of however many unbundled copies they have? That would allow /usr/bin to be the path to the bundled compilers all the time. Danek From john.plocher@gmail.com Wed Jan 21 10:42:11 2009 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 n0LIgBaX016134 for ; Wed, 21 Jan 2009 10:42:11 -0800 (PST) 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 n0LIg7Bp017498; Wed, 21 Jan 2009 11:42:10 -0700 (MST) 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 <0KDU00H0T3Y7CW00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 10:42:07 -0800 (PST) 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 <0KDU00FKV3Y6OE80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 10:42:06 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0LIcaWF010764; Wed, 21 Jan 2009 18:42:06 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-2840267; Wed, 21 Jan 2009 18:42:06 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-103552; Wed, 21 Jan 2009 18:42:05 +0000 (Z) Received: from rv-out-0708.google.com ([209.85.198.250] [209.85.198.250]) by relay1ib.sun.com with ESMTP id BT-MMP-28424146; Wed, 21 Jan 2009 18:42:05 +0000 (Z) Received: by rv-out-0708.google.com with SMTP id k29so3936957rvb.8 for ; Wed, 21 Jan 2009 10:41:59 -0800 (PST) Received: by 10.140.157.4 with SMTP id f4mr4089626rve.290.1232563319333; Wed, 21 Jan 2009 10:41:59 -0800 (PST) Date: Wed, 21 Jan 2009 10:41:59 -0800 From: John Plocher Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090121160633.GO2706@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Chris Quenelle , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RCeviht53PQCNsLWO2ypuzfe+xhSW1MOe/gv82ybXFo=; b=Ebk8SIIa9KiT8fV9GZpOGnLlrGZjSdgBl/yTmY25rkUw2cMoak/rSqJoi4Plo3hbeB Zio3B57vMLU5GcjJUmK2OuUe77p0gbVDBQp0VUM1vnuMqYnvKQDgA5vi6R5+uzJLAhMq ux4NyG36ZMqzVVt783NytePQcbV8q4mBHH5o4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fcUO40KwNnhVUQmJfbxxA8i1w3Q90x9BqeUkIFoDHrUWO0sS77s07xw0qmNlo0byMI tsEC7NZh1txhf/IBBC/uWXR2cNm+XAaFM5yTy6hqnTN2QZvJGlQv1/QQ+n/NnVFEXkEn MxcDSmrqGQDQjGbzwTwwW0DBk+ziHNqGJ6di0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496E5BCB.4060409@sun.com> <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> <20090121160633.GO2706@mumak.SFBay.Sun.COM> Status: RO Content-Length: 1056 On Wed, Jan 21, 2009 at 8:06 AM, Danek Duvall wrote: > Couldn't they just set their path to have /opt/xxx/bin before /usr/bin to > use one of however many unbundled copies they have? That would allow > /usr/bin to be the path to the bundled compilers all the time. In a situation like this (multiple installs of a complex component), it is best if each instance is installed in its own location, with RPATH set to that location (using $ORIGIN as needed). This divorces the concept of "will it work?" from that of "what is the default". Hardcoding one particular instance of a multi-install family to only work in /usr/bin (...) ends up being an architectural blunder. If /all/ the instances are self contained that way, then choosing one to be a default is as easy as mucking with symlinks or PATH. And changing that default is just as easy. (In this thread, it seems obvious to me that all the instances of the Sun compiler are architecturally related: bundled, unbundled, express, alpha, studio.old, studio.new...) -John From danek.duvall@sun.com Wed Jan 21 11:54:57 2009 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 n0LJsuNa015722 for ; Wed, 21 Jan 2009 11:54:57 -0800 (PST) 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 n0LJsmC8008073 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 03:54:55 +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 <0KDU0020H7BIY800@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 Jan 2009 11:54:54 -0800 (PST) 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 <0KDU00IHW7BHPS90@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 Jan 2009 11:54:53 -0800 (PST) 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 n0LJsqOI039016; Wed, 21 Jan 2009 11:54:52 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0LJug3Q002343; Wed, 21 Jan 2009 11:56:42 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0LJugC2002342; Wed, 21 Jan 2009 11:56:42 -0800 (PST) Date: Wed, 21 Jan 2009 11:56:42 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: To: John Plocher Cc: Chris Quenelle , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090121195642.GB1900@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: <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> <20090121160633.GO2706@mumak.SFBay.Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 784 On Wed, Jan 21, 2009 at 10:41:59AM -0800, John Plocher wrote: > In a situation like this (multiple installs of a complex component), > it is best if each instance is installed in its own location, with > RPATH set to that location (using $ORIGIN as needed). That's already happening. > Hardcoding one particular instance of a multi-install family to only > work in /usr/bin (...) ends up being an architectural blunder. No one's suggested that; I'm not sure why you're bringing this up. My suggestion was that exposing /usr/compilers (and /usr/compilers/bin) is unnecessary, since the project's interfaces will be delivered in /usr/bin, the need to choose another version of the product can be done by modifying $PATH to point first at one of the unbundled installations. Danek From john.plocher@gmail.com Wed Jan 21 12:26:09 2009 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 n0LKQ9nj023372 for ; Wed, 21 Jan 2009 12:26:09 -0800 (PST) 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 n0LKQ67v007341; Wed, 21 Jan 2009 13:26:07 -0700 (MST) 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 <0KDU007098RIBX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 12:26:06 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDU00IH48RIPSD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 12:26:06 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0LKER5V027475; Wed, 21 Jan 2009 20:26:05 +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-2848984; Wed, 21 Jan 2009 20:26:05 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-196537; Wed, 21 Jan 2009 20:26:05 +0000 (Z) Received: from rv-out-0708.google.com ([209.85.198.248] [209.85.198.248]) by relay1i.sun.com with ESMTP id BT-MMP-31189390; Wed, 21 Jan 2009 20:26:05 +0000 (Z) Received: by rv-out-0708.google.com with SMTP id k29so3977797rvb.8 for ; Wed, 21 Jan 2009 12:26:03 -0800 (PST) Received: by 10.141.168.2 with SMTP id v2mr4137372rvo.207.1232569563126; Wed, 21 Jan 2009 12:26:03 -0800 (PST) Date: Wed, 21 Jan 2009 12:26:03 -0800 From: John Plocher Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090121195642.GB1900@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Chris Quenelle , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HpBkOJt7UuhLMrWau6QegOBr0m7frXsQWw0tvLt6/Eo=; b=hHsrk+/3esQQjFOp8FjMC9xEX8KW0yrDroctZ4SzNam8J3R2KLy8xeXl8M9A0ziEwa O3dpsRkcqL2xQnAb6opdfx7ejq244ua3RTwpRCam5qmeJAHOP4d9F47NpAFS3HzubC79 F+PDTz7xTAUdBBqy1I2Pv2i2RKpywPMtaX1Nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WDaDtI/jKfg4yDP2hlDrefYfGKhb8t+eJyihLrHmHKw8AJDoAwL0pWYeYuF6qW4x8v f3maawINqcDlXUGVvJZgr0BswqTG8DqEu7V5RkeoceKuHgi0V0u33TV187O+Nfgi4Jlb lxl5fz5LKGB1gY8cVUCZ2p3sa1WS/Dq0+Ek4U= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.045sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20090115175203.GT2706@mumak.SFBay.Sun.COM> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> <20090121160633.GO2706@mumak.SFBay.Sun.COM> <20090121195642.GB1900@mumak.SFBay.Sun.COM> Status: RO Content-Length: 330 On Wed, Jan 21, 2009 at 11:56 AM, Danek Duvall wrote: > No one's suggested that; I'm not sure why you're bringing this up. Thanks for the clarification - I mistook your comment "That would allow /usr/bin to be the path to the bundled compilers all the time" to imply both PATH and RPATH. Sorry. -John From Raj.Prakash@sun.com Wed Jan 21 12:59:18 2009 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 n0LKxIZu007985 for ; Wed, 21 Jan 2009 12:59:18 -0800 (PST) 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 n0LKxHXM024603 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 21 Jan 2009 13:59:17 -0700 (MST) 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 <0KDU0090BAAS4T00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 21 Jan 2009 12:59:16 -0800 (PST) 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 <0KDU00MF0AAR66E0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 21 Jan 2009 12:59:15 -0800 (PST) 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 n0LKxFXp017333 for ; Wed, 21 Jan 2009 12:59:15 -0800 (PST) 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 <0KDU00D01A745L00@fe-sfbay-10.sun.com> (original mail from Raj.Prakash@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 21 Jan 2009 12:59:15 -0800 (PST) Received: from [192.168.0.5] ([24.6.208.196]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDU00B0KAAIJM10@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 21 Jan 2009 12:59:11 -0800 (PST) Date: Wed, 21 Jan 2009 12:59:12 -0800 From: Raj Prakash Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <496E8FCF.2030502@sun.com> Sender: Raj.Prakash@sun.com To: lsarc-ext@sun.com Cc: Douglas.Walls@sun.com, Chris.Quenelle@sun.com, David.Ford@sun.com Message-id: <49778CA0.6080403@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: <496E7162.5010107@sun.com> <496E8FCF.2030502@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 178 Hello, A reminder that this case times out today. If you think your concerns have fallen through the cracks and not adequately addressed, please speak up again. Thanks, Raj. From Chris.Quenelle@sun.com Thu Jan 22 10:40:49 2009 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 n0MIem8j027117 for ; Thu, 22 Jan 2009 10:40:48 -0800 (PST) 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 n0MIee2x024060 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 02:40:47 +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 <0KDV00L03YJZMZ00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 10:40:47 -0800 (PST) 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 <0KDV00EJWYJY3FD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 10:40:46 -0800 (PST) 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 n0MIekLe027212 for ; Thu, 22 Jan 2009 10:40:46 -0800 (PST) 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 <0KDV00D01Y9EFL00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 10:40:46 -0800 (PST) Received: from [129.150.19.43] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDV00GARYJNBD20@fe-sfbay-10.sun.com>; Thu, 22 Jan 2009 10:40:36 -0800 (PST) Date: Thu, 22 Jan 2009 10:40:44 -0800 From: Chris Quenelle Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090121195642.GB1900@mumak.SFBay.Sun.COM> Sender: Chris.Quenelle@sun.com To: Danek Duvall Cc: John Plocher , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <4978BDAC.5030102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20090115175203.GT2706@mumak.SFBay.Sun.COM> <496F8CF5.7090907@sun.com> <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> <20090121160633.GO2706@mumak.SFBay.Sun.COM> <20090121195642.GB1900@mumak.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1043 Danek Duvall wrote: > My suggestion was that exposing /usr/compilers (and /usr/compilers/bin) is > unnecessary, since the project's interfaces will be delivered in /usr/bin, > the need to choose another version of the product can be done by modifying > $PATH to point first at one of the unbundled installations. In theory you are correct. But these tools are (for now) living a dual life. There are utilities and executables that we make available in our unbundled product that are part of the packages we deliver for the core tools, but which might not appropriate for putting on the user's default path. (The 'version' command is the poster child for this.) So there might be things in /usr/compilers/bin that some people might want to run sometimes, but we wouldn't want to have symlinks for them in /usr/bin. This is a wart, and I don't expect many people will ever care enough to add /usr/compilers to their search path for this reason. But technically /usr/compilers/bin is not completely an internal directory. > > Danek From Danek.Duvall@sun.com Thu Jan 22 10:42:16 2009 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 n0MIgFpP027154 for ; Thu, 22 Jan 2009 10:42:15 -0800 (PST) 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 n0MIgCX6013074 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 11:42:15 -0700 (MST) 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 <0KDV00L0ZYMERY00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 10:42:14 -0800 (PST) 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 <0KDV00K0WYMDMO20@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 10:42:13 -0800 (PST) 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 n0MIgDjn058399; Thu, 22 Jan 2009 10:42:13 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0MIi4lY007475; Thu, 22 Jan 2009 10:44:04 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MIi4PO007474; Thu, 22 Jan 2009 10:44:04 -0800 (PST) Date: Thu, 22 Jan 2009 10:44:04 -0800 From: Danek Duvall Subject: Re: Bundled Compiler Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978BDAC.5030102@sun.com> To: Chris Quenelle Cc: John Plocher , Douglas Walls , LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090122184404.GL1900@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: <20090115193148.GY2706@mumak.SFBay.Sun.COM> <496F9283.4050106@sun.com> <20090115211654.GZ2706@mumak.SFBay.Sun.COM> <496FB7E8.2000504@sun.com> <20090116011236.GE2706@mumak.SFBay.Sun.COM> <4970D343.1030006@sun.com> <20090121160633.GO2706@mumak.SFBay.Sun.COM> <20090121195642.GB1900@mumak.SFBay.Sun.COM> <4978BDAC.5030102@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1217 On Thu, Jan 22, 2009 at 10:40:44AM -0800, Chris Quenelle wrote: > Danek Duvall wrote: > > My suggestion was that exposing /usr/compilers (and /usr/compilers/bin) > > is unnecessary, since the project's interfaces will be delivered in > > /usr/bin, the need to choose another version of the product can be done > > by modifying $PATH to point first at one of the unbundled > > installations. > > In theory you are correct. But these tools are (for now) living a dual > life. There are utilities and executables that we make available in our > unbundled product that are part of the packages we deliver for the core > tools, but which might not appropriate for putting on the user's default > path. (The 'version' command is the poster child for this.) So there > might be things in /usr/compilers/bin that some people might want to run > sometimes, but we wouldn't want to have symlinks for them in /usr/bin. > This is a wart, and I don't expect many people will ever care enough to > add /usr/compilers to their search path for this reason. But technically > /usr/compilers/bin is not completely an internal directory. Okay; I was expecting something along those lines, but hadn't heard it yet. Thanks, Danek From ro@techfak.uni-bielefeld.de Thu Jan 22 11:37:56 2009 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 n0MJbtQH028393 for ; Thu, 22 Jan 2009 11:37:56 -0800 (PST) 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 n0MJbnuB050305; Thu, 22 Jan 2009 12:37:54 -0700 (MST) 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 <0KDW0040L175B200@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 12:37:53 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDW003XU174GL00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 12:37:52 -0700 (MST) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0MJYcTY022930; Thu, 22 Jan 2009 19:37:52 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay24i.sun.com with ESMTP id BT-MMP-3459693; Thu, 22 Jan 2009 19:37:51 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-1992880; Thu, 22 Jan 2009 19:37:50 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay21i.sun.com with ESMTP id BT-MMP-17737156; Thu, 22 Jan 2009 19:37:50 +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 C48A1482A4; Thu, 22 Jan 2009 20:37:49 +0100 (CET) Date: Thu, 22 Jan 2009 20:37:49 +0100 From: Rainer Orth Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: Raj Prakash's message of "Wed, 14 Jan 2009 15:12:34 -0800" Sender: ro@techfak.uni-bielefeld.de To: Raj Prakash Cc: LSARC-ext@sun.com, Douglas.Walls@sun.com, Chris.Quenelle@sun.com, David.Ford@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 0.612sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 69 References: <496E7162.5010107@sun.com> Status: RO Content-Length: 3248 Raj Prakash writes: Sorry for commenting so late, it almost fell through the cracks, and some of my concerns have already been voiced by others, but not really adressed. > 4. Technical Description: > 4.1. Details: > > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant > redesign. We need a location into which to install the > compiler components, with symlinks to those components > installed in /usr/bin and /usr/share/man. The delivery will > install the bundled compiler collection components into > /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and Given that it seems that future GCC version will not be delivered into /usr/compilers, the name seems much too generic: this is not for all compilers, but exclusively for the Sun Studio (or whatever they are or will be called) compilers. > /usr/share/man. We chose the name 'compilers' to > intentionally indicate these are the > default|builtin|preferred|bundled compilers. There will not > be multiple versions, there will only be one set of bundled > compilers. Versions of the unbundled Sun Studio will > continue to install into /opt, i.e. /opt/sunstudio13, > /opt/sunstudio14, etc.. Note Sun Studio also provides an This is extremely unfortunate, since it puts the burden upon the users to install different compiler versions in parallel. While at least with SVr4 packaging, the compiler packages can be relocated via BASEDIR, AFAIK at least until now pkg(5) is incapable of doing so, leaving no way for the user to perform the relocation by himself. To me, ample evidence has been provided that the parallel installation of different compiler versions in parallel is necessary, so leaving this to the user is just incomplete architecture. Why is it so difficult to handle this requirement with the Studio compilers if many other packages manage just fine? To me, this feels like a hack instead of real architecture. > - The first delivery will be the C, C++ and dbx components of > Sun Studio Express 2008.11 release.. As I said before, I doubt this is wise: Studio Express is a fast-changing alpha/beta product which shouldn't be the default compiler set. I know that SXCE/Indiana are alpha (or whatever) themselves, but we don't provide beta versions of, say, apache or gcc either. > 4.5. Interfaces: > > The following soft links will be created in /usr/bin to point to > the appropriate binaries of /usr/compilers/suncc2008.11/bin. We This doesn't match what was specified earlier: to match, this should be /usr/compilers/bin. > 4.10. Packaging & Delivery: > Name Stability Notes > ==== ========= ===== > SUNWcompilers Committed Sun Studio C/C++/dbx core cluster > SUNWcompilerlinks Committed Sun Studio C/C++/dbx /usr/bin /usr/man links Same argument as before: SUNWcompilers is far too generic. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Chris.Quenelle@sun.com Thu Jan 22 12:17:31 2009 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 n0MKHUDV017181 for ; Thu, 22 Jan 2009 12:17:31 -0800 (PST) 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 n0MKHOE1019165 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 04:17:28 +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 <0KDW0091B312PN00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 12:17:26 -0800 (PST) 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 <0KDW008I7311EB10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 12:17:25 -0800 (PST) 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 n0MKHPvm014052 for ; Thu, 22 Jan 2009 12:17:25 -0800 (PST) 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 <0KDW00I012QZBX00@fe-sfbay-10.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 12:17:25 -0800 (PST) Received: from [129.150.19.43] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDW00A80310FDC0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 12:17:25 -0800 (PST) Date: Thu, 22 Jan 2009 12:17:33 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: Sender: Chris.Quenelle@sun.com To: Rainer Orth Cc: Raj Prakash , LSARC-ext@sun.com, Douglas.Walls@sun.com, David.Ford@sun.com Message-id: <4978D45D.8050005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496E7162.5010107@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 4854 So I hear two issues here: 1. /usr/compilers is a bad name because it is too generic Please suggest another name to give us an idea of what you're looking for. I consider any reference to "Sun Studio" to be inappropriate because we're not delivering all of Sun Studio, or even all of the compilers from Sun Studio. Do you have other ideas for a good name? 2. The project should anticipate delivering multiple versions of the compilers into Nevada, and/or the project should deliver multiple versions as part of this case. I think there has been a lot of discussion about this already, I really can't think of anything new to say on this topic, but I'll give it a try. > This is extremely unfortunate, since it puts the burden upon the users to > install different compiler versions in parallel. I don't anticipate any user ever needing to create a pkg "user-image" or use an alternate base directory to install any compilers. I don't see a big burden here. If you need different compilers for different projects you'll need to add them to the system (using the normal default install steps) and remember which one to use for which project. That hassle is not made any better or worse by this case. Caveat: Our current unbundled releases install into a common directory /opt/SUNWspro. So to get SS11 and SS12 on the same S10 system, you need to specify an alternate base directory to the installer. We're working on changing that so that the default install directories are different. This should never be an issue on an OpenSolaris distribution, but we haven't pushed an FCS release there yet. --chris Rainer Orth wrote: > Raj Prakash writes: > > Sorry for commenting so late, it almost fell through the cracks, and some > of my concerns have already been voiced by others, but not really adressed. > >> 4. Technical Description: >> 4.1. Details: >> >> - The design of the Sun compilers precludes just installing >> them into /usr/bin, /usr/lib, etc. without significant >> redesign. We need a location into which to install the >> compiler components, with symlinks to those components >> installed in /usr/bin and /usr/share/man. The delivery will >> install the bundled compiler collection components into >> /usr/compilers/{bin,lib,...}, with symlinks in /usr/bin and > > Given that it seems that future GCC version will not be delivered into > /usr/compilers, the name seems much too generic: this is not for all > compilers, but exclusively for the Sun Studio (or whatever they are or will > be called) compilers. > >> /usr/share/man. We chose the name 'compilers' to >> intentionally indicate these are the >> default|builtin|preferred|bundled compilers. There will not >> be multiple versions, there will only be one set of bundled >> compilers. Versions of the unbundled Sun Studio will >> continue to install into /opt, i.e. /opt/sunstudio13, >> /opt/sunstudio14, etc.. Note Sun Studio also provides an > > This is extremely unfortunate, since it puts the burden upon the users to > install different compiler versions in parallel. While at least with SVr4 > packaging, the compiler packages can be relocated via BASEDIR, AFAIK at > least until now pkg(5) is incapable of doing so, leaving no way for the > user to perform the relocation by himself. To me, ample evidence has been > provided that the parallel installation of different compiler versions in > parallel is necessary, so leaving this to the user is just incomplete > architecture. Why is it so difficult to handle this requirement with the > Studio compilers if many other packages manage just fine? To me, this > feels like a hack instead of real architecture. > >> - The first delivery will be the C, C++ and dbx components of >> Sun Studio Express 2008.11 release.. > > As I said before, I doubt this is wise: Studio Express is a fast-changing > alpha/beta product which shouldn't be the default compiler set. I know > that SXCE/Indiana are alpha (or whatever) themselves, but we don't provide > beta versions of, say, apache or gcc either. > >> 4.5. Interfaces: >> >> The following soft links will be created in /usr/bin to point to >> the appropriate binaries of /usr/compilers/suncc2008.11/bin. We > > This doesn't match what was specified earlier: to match, this should be > /usr/compilers/bin. > >> 4.10. Packaging & Delivery: >> Name Stability Notes >> ==== ========= ===== >> SUNWcompilers Committed Sun Studio C/C++/dbx core cluster >> SUNWcompilerlinks Committed Sun Studio C/C++/dbx /usr/bin /usr/man links > > Same argument as before: SUNWcompilers is far too generic. > > Rainer > From Nicolas.Williams@sun.com Thu Jan 22 12:37:12 2009 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 n0MKbCFj017371 for ; Thu, 22 Jan 2009 12:37:12 -0800 (PST) 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 n0MKbBB4020896; Thu, 22 Jan 2009 12:37:11 -0800 (PST) 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 <0KDW004093XZVV00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Jan 2009 12:37:11 -0800 (PST) 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 <0KDW00ME73XXOG70@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Jan 2009 12:37:09 -0800 (PST) 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 n0MKZwWV026506; Thu, 22 Jan 2009 14:35:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MKZrgI026505; Thu, 22 Jan 2009 14:35:53 -0600 (CST) Date: Thu, 22 Jan 2009 14:35:53 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978D45D.8050005@sun.com> To: Chris Quenelle Cc: Rainer Orth , Douglas.Walls@sun.com, LSARC-ext@sun.com, David.Ford@sun.com, Raj Prakash Message-id: <20090122203553.GT884@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: <496E7162.5010107@sun.com> <4978D45D.8050005@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: 1678 On Thu, Jan 22, 2009 at 12:17:33PM -0800, Chris Quenelle wrote: > So I hear two issues here: > > 1. /usr/compilers is a bad name because it is too generic > > Please suggest another name to give us an idea of what you're looking for. > I consider any reference to "Sun Studio" to be inappropriate because > we're not delivering all of Sun Studio, or even all of the compilers > from Sun Studio. Do you have other ideas for a good name? If there will be just one version, and that version will be invokable through /usr/bin, then just deliver into /usr/bin /usr/lib/sunstudio (or whatever) If we want the ability to use a "links package" to control what version is available through /usr/bin, then: a) wouldn't that also be true of GCC? and b) if the version can be selected via PATH, why bother with links packages? If we drop the multiple versions (multiple versions -> /opt) and links packages (there's only one version, after all) then we don't need /usr/compilers, or /usr/foo or /usr/. > 2. The project should anticipate delivering multiple versions > of the compilers into Nevada, and/or the project should deliver > multiple versions as part of this case. I'm happy with the "only one version in /usr, other versions in /opt" answer. I think that's a fine answer that simplifies other things. > I think there has been a lot of discussion about this already, > I really can't think of anything new to say on this topic, > but I'll give it a try. Well, I just did think of something new to add. Namely that "one version in /usr" should imply "no need for links pkgs" and "just install into /usr/bin and /usr/lib." I.e., no need for /usr/compilers. From David.Ford@sun.com Thu Jan 22 13:02:15 2009 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 n0ML2F92018162 for ; Thu, 22 Jan 2009 13:02:15 -0800 (PST) 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 n0ML2E0v012728 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 13:02:15 -0800 (PST) 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 <0KDW0064Z53QBF00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:02:14 -0800 (PST) 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 <0KDW00MMV53NOG80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:02:13 -0800 (PST) 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 n0ML2BNe020252 for ; Thu, 22 Jan 2009 13:02:11 -0800 (PST) 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 <0KDW00E014S60X00@fe-sfbay-10.sun.com> (original mail from David.Ford@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:02:11 -0800 (PST) Received: from [129.146.86.88] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDW00LGV53IWS10@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:02:07 -0800 (PST) Date: Thu, 22 Jan 2009 13:02:06 -0800 From: David.Ford@sun.com Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122203553.GT884@Sun.COM> Sender: David.Ford@sun.com To: Nicolas Williams Cc: Chris Quenelle , Rainer Orth , Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <4978DECE.30800@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 2312 /usr/bin links are proposed not for multiple versions, but to avoid re-architecting Sun Studio in the short term. Our compilers and dbx find other files via relative paths within the directory structure. We do not want to impose our present directory structure on /usr. We intend to re-architect at some future time, but until then, symlinks in /usr are our answer. Given that, the name of the directory we actually install in is almost irrelevant. We just want something descriptive to appear with "ls /usr". -- Dave F On 01/22/09 12:35, Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 12:17:33PM -0800, Chris Quenelle wrote: >> So I hear two issues here: >> >> 1. /usr/compilers is a bad name because it is too generic >> >> Please suggest another name to give us an idea of what you're looking for. >> I consider any reference to "Sun Studio" to be inappropriate because >> we're not delivering all of Sun Studio, or even all of the compilers >> from Sun Studio. Do you have other ideas for a good name? > > If there will be just one version, and that version will be invokable > through /usr/bin, then just deliver into > > /usr/bin > /usr/lib/sunstudio (or whatever) > > If we want the ability to use a "links package" to control what version > is available through /usr/bin, then: a) wouldn't that also be true of > GCC? and b) if the version can be selected via PATH, why bother with > links packages? > > If we drop the multiple versions (multiple versions -> /opt) and links > packages (there's only one version, after all) then we don't need > /usr/compilers, or /usr/foo or /usr/. > >> 2. The project should anticipate delivering multiple versions >> of the compilers into Nevada, and/or the project should deliver >> multiple versions as part of this case. > > I'm happy with the "only one version in /usr, other versions in /opt" > answer. I think that's a fine answer that simplifies other things. > >> I think there has been a lot of discussion about this already, >> I really can't think of anything new to say on this topic, >> but I'll give it a try. > > Well, I just did think of something new to add. Namely that "one > version in /usr" should imply "no need for links pkgs" and "just install > into /usr/bin and /usr/lib." I.e., no need for /usr/compilers. From daleg@elemental.org Thu Jan 22 13:08:12 2009 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 n0ML8Aa8018263 for ; Thu, 22 Jan 2009 13:08:11 -0800 (PST) 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 n0ML7mHZ016069; Fri, 23 Jan 2009 05:08:03 +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 <0KDW00D075DD4F00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 14:08:01 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDW003BX5DCGH70@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 14:08:00 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0ML0f2K027378; Thu, 22 Jan 2009 21:08:00 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-1933165; Thu, 22 Jan 2009 21:08:00 +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-1155141; Thu, 22 Jan 2009 21:08:00 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay4i.sun.com with ESMTP id BT-MMP-27181150; Thu, 22 Jan 2009 21:08:00 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-150-rvo.net.salesforce.com [204.14.233.150]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0ML7xdD017563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jan 2009 16:07:59 -0500 (EST) Date: Thu, 22 Jan 2009 16:07:59 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978DECE.30800@Sun.COM> To: David.Ford@sun.com Cc: Nicolas Williams , Douglas.Walls@sun.com, Raj Prakash , Chris Quenelle , LSARC-ext@sun.com Message-id: <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Thu, 22 Jan 2009 16:07:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.049sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> Status: RO Content-Length: 415 On Jan 22, 2009, at 4:02 PM, David.Ford@sun.com wrote: > Given that, the name of the directory we actually install in is almost > irrelevant. We just want something descriptive to appear with "ls / > usr". Then name it something more relevant and specific to Sun Studio, such as /usr/sunstudio. "/usr/compilers" implies too much if all that is going to live in there is one version of Sun Studio. /dale From Chris.Quenelle@sun.com Thu Jan 22 13:13:25 2009 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 n0MLDPMX018376 for ; Thu, 22 Jan 2009 13:13:25 -0800 (PST) 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 n0MLDPtS008687 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 13:13:25 -0800 (PST) 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 <0KDW00D0L5MBOO00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 14:13:23 -0700 (MST) 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 <0KDW003SZ5MAGH70@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 14:13:22 -0700 (MST) 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 n0MLDMlf021861 for ; Thu, 22 Jan 2009 13:13:22 -0800 (PST) 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 <0KDW00F0151XD600@fe-sfbay-09.sun.com> (original mail from Chris.Quenelle@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:13:22 -0800 (PST) Received: from [129.150.19.43] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDW00E945M8K460@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:13:21 -0800 (PST) Date: Thu, 22 Jan 2009 13:13:29 -0800 From: Chris Quenelle Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> Sender: Chris.Quenelle@sun.com To: Dale Ghent Cc: David.Ford@sun.com, Nicolas Williams , Douglas.Walls@sun.com, Raj Prakash , LSARC-ext@sun.com Message-id: <4978E179.9060707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 501 Dale Ghent wrote: > Then name it something more relevant and specific to Sun Studio, such as > /usr/sunstudio. "/usr/compilers" implies too much if all that is going > to live in there is one version of Sun Studio. Please suggest another name to give us an idea of what you're looking for. I consider any reference to "Sun Studio" to be inappropriate because we're not delivering all of Sun Studio, or even all of the compilers from Sun Studio. Do you have other ideas for a good name? --chris From David.Ford@Sun.COM Thu Jan 22 13:17:15 2009 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 n0MLHEuT018455 for ; Thu, 22 Jan 2009 13:17:14 -0800 (PST) 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 n0MLHCPu020986 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 05:17:13 +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 <0KDW007035SM7S00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:17:10 -0800 (PST) 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 <0KDW00MDF5SLOCA0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:17:09 -0800 (PST) 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 n0MLH940022400 for ; Thu, 22 Jan 2009 13:17:09 -0800 (PST) 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 <0KDW00H015PJFK00@fe-sfbay-09.sun.com> (original mail from David.Ford@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:17:09 -0800 (PST) Received: from [129.146.86.88] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDW009UZ5SLHS20@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:17:09 -0800 (PST) Date: Thu, 22 Jan 2009 13:17:09 -0800 From: David.Ford@Sun.COM Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> Sender: David.Ford@Sun.COM To: Dale Ghent Cc: Nicolas Williams , Douglas.Walls@Sun.COM, Raj Prakash , Chris Quenelle , LSARC-ext@Sun.COM Message-id: <4978E255.9080502@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 732 On 01/22/09 13:07, Dale Ghent wrote: > On Jan 22, 2009, at 4:02 PM, David.Ford@sun.com wrote: > >> Given that, the name of the directory we actually install in is almost >> irrelevant. We just want something descriptive to appear with "ls /usr". > > Then name it something more relevant and specific to Sun Studio, such as > /usr/sunstudio. "/usr/compilers" implies too much if all that is going > to live in there is one version of Sun Studio. > > /dale > But it is not Sun Studio. We went to some effort to point that out when we resubmitted the case. In fact, we tried (unsuccessfully) to alter the email subject line too. It is C/C++/dbx. May I suggest /usr/suncc (short for Sun Compiler Collection). -- Dave F From Nicolas.Williams@sun.com Thu Jan 22 13:39:42 2009 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 n0MLdfSN018777 for ; Thu, 22 Jan 2009 13:39:42 -0800 (PST) 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 n0MLdblT010501; Thu, 22 Jan 2009 21:39:37 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 <0KDW00K016U15M00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Jan 2009 13:39:37 -0800 (PST) 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 <0KDW008Q16U0EDA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Jan 2009 13:39:36 -0800 (PST) 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 n0MLcQC7026619; Thu, 22 Jan 2009 15:38:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MLcQOL026618; Thu, 22 Jan 2009 15:38:26 -0600 (CST) Date: Thu, 22 Jan 2009 15:38:26 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978DECE.30800@Sun.COM> To: David.Ford@sun.com Cc: Chris Quenelle , Rainer Orth , Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <20090122213825.GY884@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@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: 952 On Thu, Jan 22, 2009 at 01:02:06PM -0800, David.Ford@Sun.COM wrote: > /usr/bin links are proposed not for multiple versions, but to avoid > re-architecting Sun Studio in the short term. Our compilers and dbx find > other files via relative paths within the directory structure. Interesting. That should be an easy fix, no? > We do not > want to impose our present directory structure on /usr. We intend to > re-architect at some future time, but until then, symlinks in /usr are > our answer. So put the compilers in /usr/lib/compilers, and make /usr/lib/compilers directory and structure beneath not-a-public-interface. > Given that, the name of the directory we actually install in is almost > irrelevant. We just want something descriptive to appear with "ls /usr". I'd rather *nothing* specific to this case show up in "ls /usr". I think that's the right answer. Nico -- From David.Ford@sun.com Thu Jan 22 13:52:54 2009 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 n0MLqrqU018889 for ; Thu, 22 Jan 2009 13:52:54 -0800 (PST) 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 n0MLqnp2008277 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 05:52:52 +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 <0KDW009057G3MT00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:52:51 -0800 (PST) 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 <0KDW00M777G3OJC0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:52:51 -0800 (PST) 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 n0MLqpsI016356 for ; Thu, 22 Jan 2009 13:52:51 -0800 (PST) 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 <0KDW00M016X9VL00@fe-sfbay-10.sun.com> (original mail from David.Ford@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:52:51 -0800 (PST) Received: from [129.146.86.88] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDW00LP27G2WS50@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 13:52:50 -0800 (PST) Date: Thu, 22 Jan 2009 13:52:50 -0800 From: David.Ford@sun.com Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122213825.GY884@Sun.COM> Sender: David.Ford@sun.com To: Nicolas Williams Cc: Chris Quenelle , Rainer Orth , Douglas.Walls@sun.com, LSARC-ext@sun.com, Raj Prakash Message-id: <4978EAB2.7070102@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <20090122213825.GY884@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1164 On 01/22/09 13:38, Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 01:02:06PM -0800, David.Ford@Sun.COM wrote: >> /usr/bin links are proposed not for multiple versions, but to avoid >> re-architecting Sun Studio in the short term. Our compilers and dbx find >> other files via relative paths within the directory structure. > > Interesting. That should be an easy fix, no? No. >> We do not >> want to impose our present directory structure on /usr. We intend to >> re-architect at some future time, but until then, symlinks in /usr are >> our answer. > > So put the compilers in /usr/lib/compilers, and make /usr/lib/compilers > directory and structure beneath not-a-public-interface. Works for me. I think others have objected to "compilers" as being too generic, which is why Chris asked for suggestions. -- Dave F >> Given that, the name of the directory we actually install in is almost >> irrelevant. We just want something descriptive to appear with "ls /usr". > > I'd rather *nothing* specific to this case show up in "ls /usr". I > think that's the right answer. > > Nico From john.plocher@gmail.com Thu Jan 22 15:24:04 2009 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 n0MNO4Wd020890 for ; Thu, 22 Jan 2009 15:24:04 -0800 (PST) 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 n0MNO3Rv043531; Thu, 22 Jan 2009 16:24:03 -0700 (MST) 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 <0KDW00303BO2WG00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:24:02 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDW001PFBNZRB10@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:24:00 -0700 (MST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0MNK9HD001283; Thu, 22 Jan 2009 23:23:59 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-991290; Thu, 22 Jan 2009 23:23:59 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-1248286; Thu, 22 Jan 2009 23:23:59 +0000 (Z) Received: from rv-out-0506.google.com ([209.85.198.225] [209.85.198.225]) by relay1ib.sun.com with ESMTP id BT-MMP-29004765; Thu, 22 Jan 2009 23:23:59 +0000 (Z) Received: by rv-out-0506.google.com with SMTP id f9so124714rvb.0 for ; Thu, 22 Jan 2009 15:23:56 -0800 (PST) Received: by 10.141.136.4 with SMTP id o4mr2831903rvn.13.1232666636097; Thu, 22 Jan 2009 15:23:56 -0800 (PST) Date: Thu, 22 Jan 2009 15:23:56 -0800 From: John Plocher Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978E255.9080502@Sun.COM> To: David.Ford@sun.com Cc: Dale Ghent , LSARC-ext@sun.com, Douglas.Walls@sun.com, Chris Quenelle , Nicolas Williams , Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=na3PXWDRpi1thL4eHMpPkRtip1kuvaSzbM8R7Al67Fo=; b=HKCPF28PeUm7xp27FiFKzOVe36Qhcyb3yh2fBUOAkCpQAnQh+/UgHYngsQveoYY436 wdoR/qtsgY5m1jmKJVrYktIdjU9HM97i88PHU7SDvZDXyJAJH8Mze1KDw/C92Pkri+gV OkoPgDClY4W8c3PyLBF/t07pp7Naox70aB0BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CZJFj8NiSFMtCKOVLnV6U8jgWboC+8lUd5o18T7PU3rN8TkAAlrRMis/dp0ipyeZyD +w4EhFXUuO+W4yfXFCFViDrkpEXoW5wYMCy0tEb5BkZFJAQQeycBdYOsFEQhX1p7HK0M 3ZP0393e9N57ztkRhj50FZs0rAdwmo2FqKwGc= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> Status: RO Content-Length: 822 On Thu, Jan 22, 2009 at 1:17 PM, wrote: > May I suggest /usr/suncc (short for Sun > Compiler Collection). This works for me, though a better long term answer might be /usr/suncc/$VERSION/, which would allow one to install other unbundled releases alongside AND for you to be able to gracefully support the transition from 2008.11 to 2009.xx and 2009.yy going forward, not to mention providing an architecture for installing Express and full Studio releases there as well. Taking a step back, all that posturing about how bundling makes it different and special doesn't ring true to me - it more like the unstated focus is on "how do we do this quickly without wasting engineering resources on it and without being forced to change the status quo elsewhere in the compiler/studio world." -John From daleg@elemental.org Thu Jan 22 15:28:36 2009 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 n0MNSaiB021003 for ; Thu, 22 Jan 2009 15:28:36 -0800 (PST) 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 n0MNSYG7019617; Thu, 22 Jan 2009 15:28:35 -0800 (PST) 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 <0KDW00407BVMFS00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:28:35 -0700 (MST) 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 <0KDW0010BBVMRB20@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:28:34 -0700 (MST) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0MNDQb9005715; Thu, 22 Jan 2009 23:28:33 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay21i.sun.com with ESMTP id BT-MMP-3475336; Thu, 22 Jan 2009 23:28:33 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-2310722; Thu, 22 Jan 2009 23:28:33 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay22i.sun.com with ESMTP id BT-MMP-17937663; Thu, 22 Jan 2009 23:28:33 +0000 (Z) Received: from [10.75.10.116] (nat-204-14-233-150-rvo.net.salesforce.com [204.14.233.150]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n0MNSWtN029195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jan 2009 18:28:32 -0500 (EST) Date: Thu, 22 Jan 2009 18:28:32 -0500 From: Dale Ghent Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <4978E255.9080502@Sun.COM> To: David.Ford@sun.com Cc: Nicolas Williams , Douglas.Walls@sun.com, Raj Prakash , Chris Quenelle , LSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Thu, 22 Jan 2009 18:28:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.139sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> Status: RO Content-Length: 144 On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: > May I suggest /usr/suncc (short for Sun > Compiler Collection). I like that. /dale From Nicolas.Williams@Sun.COM Thu Jan 22 15:42:52 2009 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 n0MNgpgh021066 for ; Thu, 22 Jan 2009 15:42:52 -0800 (PST) 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 n0MNgemb000757; Fri, 23 Jan 2009 07:42:46 +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 <0KDW00509CJ7SN00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:42:43 -0700 (MST) 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 <0KDW001T3CJ6RM10@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 16:42:42 -0700 (MST) 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 n0MNXsS4001277; Thu, 22 Jan 2009 17:33:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MNXjtL001276; Thu, 22 Jan 2009 17:33:45 -0600 (CST) Date: Thu, 22 Jan 2009 17:33:45 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: To: Dale Ghent Cc: David.Ford@Sun.COM, Douglas.Walls@Sun.COM, Raj Prakash , Chris Quenelle , LSARC-ext@Sun.COM Message-id: <20090122233345.GG1044@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@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: 446 On Thu, Jan 22, 2009 at 06:28:32PM -0500, Dale Ghent wrote: > On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: > > > May I suggest /usr/suncc (short for Sun > >Compiler Collection). > > I like that. I think I just wrested a concession, that a directory under /usr is not needed. A directory under /usr/lib, with symlinks from /usr/bin, should do until the i-team is able to spread the bundled bits into the correct locations. Nico -- From danek.duvall@sun.com Thu Jan 22 15:45:44 2009 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 n0MNjiwU021115 for ; Thu, 22 Jan 2009 15:45:44 -0800 (PST) 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 n0MNjh26017828 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 22 Jan 2009 15:45:43 -0800 (PST) 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 <0KDW00D05CO7QD00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 15:45:43 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDW006WQCO7BSC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 22 Jan 2009 15:45:43 -0800 (PST) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0MNjgCM011313; Thu, 22 Jan 2009 15:45:42 -0800 (PST) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0MNlYBW013286; Thu, 22 Jan 2009 15:47:34 -0800 (PST) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MNlYvT013285; Thu, 22 Jan 2009 15:47:34 -0800 (PST) Date: Thu, 22 Jan 2009 15:47:34 -0800 From: Danek Duvall Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122233345.GG1044@Sun.COM> To: Nicolas Williams Cc: Dale Ghent , David.Ford@sun.com, Douglas.Walls@sun.com, Raj Prakash , Chris Quenelle , LSARC-ext@sun.com Message-id: <20090122234734.GO1900@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> <20090122233345.GG1044@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 809 On Thu, Jan 22, 2009 at 05:33:45PM -0600, Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 06:28:32PM -0500, Dale Ghent wrote: > > On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: > > > > > May I suggest /usr/suncc (short for Sun > > >Compiler Collection). > > > > I like that. > > I think I just wrested a concession, that a directory under /usr is not > needed. A directory under /usr/lib, with symlinks from /usr/bin, should > do until the i-team is able to spread the bundled bits into the correct > locations. Except that in a parallel thread, Chris told us that there's a bin directory that users will have to access, as not all things that are there will have symlinks in /usr/bin (such as "version"). Yes, that could be /usr/lib/suncc/bin, but is that better than /usr/suncc/bin? Danek From Nicolas.Williams@sun.com Thu Jan 22 16:03:39 2009 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 n0N03dqv020643 for ; Thu, 22 Jan 2009 16:03:39 -0800 (PST) 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 n0N03aGW023669; Thu, 22 Jan 2009 16:03:39 -0800 (PST) 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 <0KDW0070KDI0UC00@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 17:03:36 -0700 (MST) 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 <0KDW001DGDHZRD40@brm-avmta-1.central.sun.com>; Thu, 22 Jan 2009 17:03:36 -0700 (MST) 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 n0MNssI0001301; Thu, 22 Jan 2009 17:54:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0MNsseD001300; Thu, 22 Jan 2009 17:54:54 -0600 (CST) Date: Thu, 22 Jan 2009 17:54:54 -0600 From: Nicolas Williams Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122234734.GO1900@mumak.SFBay.Sun.COM> To: Danek Duvall Cc: Dale Ghent , David.Ford@sun.com, Douglas.Walls@sun.com, Raj Prakash , Chris Quenelle , LSARC-ext@sun.com Message-id: <20090122235453.GH1044@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> <20090122233345.GG1044@Sun.COM> <20090122234734.GO1900@mumak.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: 961 On Thu, Jan 22, 2009 at 03:47:34PM -0800, Danek Duvall wrote: > On Thu, Jan 22, 2009 at 05:33:45PM -0600, Nicolas Williams wrote: > > > On Thu, Jan 22, 2009 at 06:28:32PM -0500, Dale Ghent wrote: > > > On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: > > > > > > > May I suggest /usr/suncc (short for Sun > > > >Compiler Collection). > > > > > > I like that. > > > > I think I just wrested a concession, that a directory under /usr is not > > needed. A directory under /usr/lib, with symlinks from /usr/bin, should > > do until the i-team is able to spread the bundled bits into the correct > > locations. > > Except that in a parallel thread, Chris told us that there's a bin > directory that users will have to access, as not all things that are there > will have symlinks in /usr/bin (such as "version"). Yes, that could be > /usr/lib/suncc/bin, but is that better than /usr/suncc/bin? Oh well. I tried :) So count me in favor of /usr/suncc. From Darren.Moffat@sun.com Fri Jan 23 02:36:48 2009 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 n0NAaluj023213 for ; Fri, 23 Jan 2009 02:36:48 -0800 (PST) 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 n0NAagU6001408 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 10:36:46 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 <0KDX00E0P6T95C00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 02:36:45 -0800 (PST) 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 <0KDX0072O6T7P970@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 02:36:44 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0NAahN6001507 for ; Fri, 23 Jan 2009 10:36:43 +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 <0KDX0050160HM200@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 10:36:43 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX0050H6SPD5E0@fe-emea-10.sun.com>; Fri, 23 Jan 2009 10:36:25 +0000 (GMT) Date: Fri, 23 Jan 2009 10:36:25 +0000 From: Darren J Moffat Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122235453.GH1044@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Danek Duvall , Chris Quenelle , David.Ford@sun.com, LSARC-ext@sun.com, Douglas.Walls@sun.com, Raj Prakash Message-id: <49799DA9.1090507@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: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> <20090122233345.GG1044@Sun.COM> <20090122234734.GO1900@mumak.SFBay.Sun.COM> <20090122235453.GH1044@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 1665 Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 03:47:34PM -0800, Danek Duvall wrote: >> On Thu, Jan 22, 2009 at 05:33:45PM -0600, Nicolas Williams wrote: >> >>> On Thu, Jan 22, 2009 at 06:28:32PM -0500, Dale Ghent wrote: >>>> On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: >>>> >>>>> May I suggest /usr/suncc (short for Sun >>>>> Compiler Collection). >>>> I like that. >>> I think I just wrested a concession, that a directory under /usr is not >>> needed. A directory under /usr/lib, with symlinks from /usr/bin, should >>> do until the i-team is able to spread the bundled bits into the correct >>> locations. >> Except that in a parallel thread, Chris told us that there's a bin >> directory that users will have to access, as not all things that are there >> will have symlinks in /usr/bin (such as "version"). Yes, that could be >> /usr/lib/suncc/bin, but is that better than /usr/suncc/bin? > > Oh well. I tried :) So count me in favor of /usr/suncc. I'm also happy with /usr/suncc, except that the opposite argument to not using studio comes into play in the future when more rest of what is now Sun Studio does get bundled into /usr. Naming is hard, in particular because marketing names change over time (as the compilers team(s) know all too well!). Why not simply /usr/spro/$VERSION yes it isn't the full thing but even in /opt/SUNWspro/$VERSION it is common not to have a "full" install (or at least it used to be when the components each cost money and were licensed separately). Or /usr/lib/spro/. As long as it isn't /usr/compilers and at least hints that is is the Sun developed compiler I'm happy. -- Darren J Moffat From Arieh.Markel@sun.com Fri Jan 23 06:06:13 2009 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 n0NE6CeT014294 for ; Fri, 23 Jan 2009 06:06:13 -0800 (PST) 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 n0NE66bk025997 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 14:06:11 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 <0KDX00F0RGIAUV00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 06:06:10 -0800 (PST) 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 <0KDX0071UGI9CR50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 06:06:10 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0NE69Oa012823 for ; Fri, 23 Jan 2009 14:06:09 +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 <0KDX00A01G0CZ200@mail-amer.sun.com> (original mail from Arieh.Markel@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 07:06:09 -0700 (MST) Received: from [192.168.20.7] ([79.181.9.207]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX00CZ9GHS6730@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 07:05:57 -0700 (MST) Date: Fri, 23 Jan 2009 16:05:51 +0200 From: Arieh Markel Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <20090122235453.GH1044@Sun.COM> Sender: Arieh.Markel@sun.com To: Nicolas Williams , LSARC-ext@sun.com Cc: Dale Ghent , David.Ford@sun.com, Douglas.Walls@sun.com, Raj Prakash , Chris Quenelle Message-id: <871737BC-FF4E-45B6-A41E-6F761DF1FCDF@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <496E7162.5010107@sun.com> <4978D45D.8050005@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> <20090122233345.GG1044@Sun.COM> <20090122234734.GO1900@mumak.SFBay.Sun.COM> <20090122235453.GH1044@Sun.COM> Status: RO Content-Length: 2378 Having lurked following this discussion, here are my $0.02. I don't understand why a solution similar to the multiple jdks would not be applicable and appropriate here. What John P stated in a previous follow up was the closest to that. /usr/suncc/ [version1]/ bin/ lib/ [version2] bin/ lib/ All binaries in bin/ would be compiled with a relative RPATH pointing at items in their respective lib/. Users wanting access to a specific version would just have to point at the specific one. We could even accomodate SPRO, GCC 'latest' links in the same manner that the jdk deals with. /usr/suncc/ gcc-latest ---> ./[version2] spro-latest ---> ./[version1] [version1]/ bin/ lib/ [version2] bin/ lib/ Arieh On Jan 23, 2009, at 1:54 AM, Nicolas Williams wrote: > On Thu, Jan 22, 2009 at 03:47:34PM -0800, Danek Duvall wrote: >> On Thu, Jan 22, 2009 at 05:33:45PM -0600, Nicolas Williams wrote: >> >>> On Thu, Jan 22, 2009 at 06:28:32PM -0500, Dale Ghent wrote: >>>> On Jan 22, 2009, at 4:17 PM, David.Ford@sun.com wrote: >>>> >>>>> May I suggest /usr/suncc (short for Sun >>>>> Compiler Collection). >>>> >>>> I like that. >>> >>> I think I just wrested a concession, that a directory under /usr >>> is not >>> needed. A directory under /usr/lib, with symlinks from /usr/bin, >>> should >>> do until the i-team is able to spread the bundled bits into the >>> correct >>> locations. >> >> Except that in a parallel thread, Chris told us that there's a bin >> directory that users will have to access, as not all things that >> are there >> will have symlinks in /usr/bin (such as "version"). Yes, that >> could be >> /usr/lib/suncc/bin, but is that better than /usr/suncc/bin? > > Oh well. I tried :) So count me in favor of /usr/suncc. Arieh Markel Sun Microsystems, Inc. xVM - Virtualization Management 9 Hamenofim St. 8th Floor. MS ETLV04 e-mail: arieh.markel@sun.COM Herzliya Pituach, Israel http://blogs.sun.com/arieh Phone: +972-9-971-1291 (70) x12291 Mobile: +972-54-238-2771 From john.plocher@gmail.com Fri Jan 23 07:47:04 2009 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 n0NFl3QB017555 for ; Fri, 23 Jan 2009 07:47:03 -0800 (PST) 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 n0NFl1oX011474; Fri, 23 Jan 2009 07:47:02 -0800 (PST) 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 <0KDX0050JL6ECT00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Jan 2009 07:47:02 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDX0078VL6DCVE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Jan 2009 07:47:01 -0800 (PST) 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 n0NFiDA0028711; Fri, 23 Jan 2009 15:47:00 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-3185908; Fri, 23 Jan 2009 15:47:00 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-41169; Fri, 23 Jan 2009 15:46:57 +0000 (Z) Received: from rv-out-0708.google.com ([209.85.198.244] [209.85.198.244]) by relay1ib.sun.com with ESMTP id BT-MMP-24458009; Fri, 23 Jan 2009 15:46:57 +0000 (Z) Received: by rv-out-0708.google.com with SMTP id k29so5011392rvb.8 for ; Fri, 23 Jan 2009 07:46:55 -0800 (PST) Received: by 10.140.136.6 with SMTP id j6mr471067rvd.126.1232725615442; Fri, 23 Jan 2009 07:46:55 -0800 (PST) Date: Fri, 23 Jan 2009 07:46:55 -0800 From: John Plocher Subject: Re: Sun Studio C/C++/dbx Collection [LSARC/2009/017 FastTrack timeout 01/21/2009] In-reply-to: <871737BC-FF4E-45B6-A41E-6F761DF1FCDF@sun.com> To: Arieh Markel Cc: Nicolas Williams , LSARC-ext@sun.com, Douglas.Walls@sun.com, Chris Quenelle , David.Ford@sun.com, Raj Prakash Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yZK6+VN3A1gtqtDICoKJbQ5EHQWn67vAk20ko8rrq5I=; b=N6/uaAtSTy+f6q/foib2XSGdyExUluaXpZgJhmb/QgDj9YVU9qbrmKRODB7b6BC3jM OFiUiPJ4USS05s/y9LkbpcsZJ1ayU+sC3UgziW+2wVcI11BVAaqaZkm22k1YlfeLkUon ugIR7sZpNOuSeFNWlSW9Oaks+IyQcD6m98FYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rr0XRsrBjGCYJLXlDZ0PyCkXCCiM0NJ/uxup9Te7Ats14wRKxY6C9CPLQwmRmY5/bT WoH3B3fUdhfScE562/xuagk2n2ekSaNPnC0GtiISgullmJaGHuSfu2b5+k+uB7a5KkLT WszSVTbg4LV6uZAyzNpwqXNh6eKiEYUSYLkEc= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.050sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <496E7162.5010107@sun.com> <20090122203553.GT884@Sun.COM> <4978DECE.30800@Sun.COM> <8876D3C2-8F4C-4B07-8D22-A6AED8FD9523@elemental.org> <4978E255.9080502@Sun.COM> <20090122233345.GG1044@Sun.COM> <20090122234734.GO1900@mumak.SFBay.Sun.COM> <20090122235453.GH1044@Sun.COM> <871737BC-FF4E-45B6-A41E-6F761DF1FCDF@sun.com> Status: RO Content-Length: 302 On Fri, Jan 23, 2009 at 6:05 AM, Arieh Markel wrote: > I don't understand why a solution > similar to the multiple jdks would not be applicable and appropriate > here. Neither do the rest of us. It was suggested several times in this thread - and not always by me :-) -John From Douglas.Walls@sun.com Fri Jan 23 11:26:11 2009 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 n0NJQA2q010931 for ; Fri, 23 Jan 2009 11:26:11 -0800 (PST) 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 n0NJQ1Kr016128 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 24 Jan 2009 03:26:09 +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 <0KDX00B1BVBK9400@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 12:26:08 -0700 (MST) 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 <0KDX008XEVBKLE10@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 12:26:08 -0700 (MST) 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 n0NJQ7st012037 for ; Fri, 23 Jan 2009 11:26:07 -0800 (PST) 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 <0KDX00601TP09F00@fe-sfbay-09.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 11:26:07 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.20.251]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX003ZGVAUQ7A0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 11:25:47 -0800 (PST) Date: Fri, 23 Jan 2009 11:25:55 -0800 From: Douglas Walls Subject: Bundled Compiler Collection [LSARC/2009/017] Sender: Douglas.Walls@sun.com To: Raj Prakash , LSARC-ext@sun.com Cc: Chris Quenelle , David Ford Message-id: <497A19C3.6090802@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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 11660 Raj, Here is the updated case for: Bundled Compiler Collection [LSARC/2009/017]. I believe all the issues relevant to the proposal have been addresses. Thanks, Douglas ------------------ There is only one change in this revision of the case, the name of the directory into which the bundled compiler collection components are installed has been changed to "/usr/suncc". As noted with the last update of the the proposal, this project is to bundle the Sun C and C++ compilers and dbx into Nevada so to make them available as the default set of compilers for any distribution of Solaris. Their relationship to the unbundled compilers of Sun Studio, how Sun Studio compilers install into versioned directories and how the Sun Studio compilers can install links to override the default compilers is explained. How to manipulate $PATH to specify a default compiler is well known and not discussed in the proposal. ============================================ Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bundled Compiler Collection 1.2. Name of Document Author/Supplier: Douglas Walls (Douglas.Walls@Sun.COM> 1.3. Date of This Document: 1/14/2009 1.3.1. Date this project was conceived: 10/2008 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com 1.4.4. The name of your business unit: CODE (C/C++ Compilers, Optimization, and Debugger) 1.5. Email Aliases: 1.5.1. Responsible Manager: Kurt Goebel 1.5.2. Responsible Engineer: Douglas Walls 1.5.3. Marketing Manager: Ikroop Dhillon 1.5.4. Interest List: tools-compilers@opensolaris.org 2. Project Summary 2.1. Project Description: The project will deliver C, C++ and dbx from the current Sun Studio Express release into Nevada through the devpro consolidation. The intent is to bundle Sun compilers into /usr. We are not bundling all of Sun Studio. This collection only contains C and C++ compilers along with their debugger, dbx. 2.2. Risks and Assumptions: No known risks or assumptions at this time. 3. Business Summary 3.1. Problem Area: Default compilers on OpenSolaris Default compilers bundled with all distribution of Solaris 3.2. Market/Requester: OpenSolaris 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. 3.4. Competitive Analysis: Main competitors: Platforms & Tool Suite Offerings - Red Hat: GCC (bundled and supported) - Windows: Microsoft Visual Studio (unbundled) - MacOS: Xcode (gcc-based), LLVM effort 3.5. Opportunity Window/Exposure: 04/2009 to coincide with the next release of OpenSolaris. 3.6. How will you know when you are done?: The project will be on-going always tracking the latest express release of Sun Studio C, C++ and dbx 4. Technical Description: 4.1. Details: - The design of the Sun compilers precludes just installing them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components installed in /usr/bin and /usr/share/man. The delivery will install the bundled compiler collection components into /usr/suncc/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'suncc' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There will not be multiple versions of the bundled compilers, there will only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/SSXYYYY.MM, /opt/sunstudio13, /opt/sunstudio14, etc.. Note Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these would then override the links of this bundled compiler as it does previously installed versions of Sun Studio. - The first delivery will be the C, C++ and dbx components of Sun Studio Express 2008.11 release.. - Links will be created in /usr/bin, e.g. /usr/bin/cc, /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate binaries /usr/suncc. - Links will be created in /usr/man, e.g. /usr/man/man1/cc, /usr/man/man1/CC, /usr/man/man1/dbx, etc., to point to man pages in /usr/suncc/man/man1. 4.2. Bug/RFE Number(s): Not applicable. 4.3. In Scope: - C, C++ compilers and dbx 4.4. Out of Scope: 4.5. Interfaces: The following soft links will be created in /usr/bin to point to the appropriate binaries of /usr/suncc/bin. We may choose to omit some of these links which do not contribute to minimizing compiler-related porting efforts to encourage FOSS inclusion into OpenSolaris repositories. /usr/bin/bcheck /usr/bin/c++filt /usr/bin/c89 /usr/bin/c99 /usr/bin/cb /usr/bin/cc /usr/bin/CC /usr/bin/CCadmin /usr/bin/cflow /usr/bin/cscope /usr/bin/ctcr /usr/bin/ctrace /usr/bin/cxref /usr/bin/dbx /usr/bin/dem /usr/bin/dumpstabs /usr/bin/dwarfdump /usr/bin/fbe /usr/bin/fpversion /usr/bin/indent /usr/bin/lint /usr/bin/rtc_patch_area /usr/bin/sunc89 /usr/bin/sunc99 /usr/bin/suncc /usr/bin/sunCC /usr/bin/tcov 4.6. Doc Impact: Links will be created in /usr/share/man/* for the following man pages: /usr/compilers/man1/CC.1 /usr/compilers/man1/CCadmin.1 /usr/compilers/man1/bcheck.1 /usr/compilers/man1/binopt.1 /usr/compilers/man1/c++filt.1 /usr/compilers/man1/c89.1 /usr/compilers/man1/c99.1 /usr/compilers/man1/cb.1 /usr/compilers/man1/cc.1 /usr/compilers/man1/cflow.1 /usr/compilers/man1/cscope.1 /usr/compilers/man1/ctrace.1 /usr/compilers/man1/cxref.1 /usr/compilers/man1/dbx.1 /usr/compilers/man1/dem.1 /usr/compilers/man1/fbe.1 /usr/compilers/man1/fpversion.1 /usr/compilers/man1/indent.1 /usr/compilers/man1/inline.1 /usr/compilers/man1/lint.1 /usr/compilers/man1/rtc_patch_area.1 /usr/compilers/man1/ss_attach.1 /usr/compilers/man3/gcFixPrematureFrees.3 /usr/compilers/man3/gcInitialize.3 /usr/compilers/man3cc4/cartpol.3 /usr/compilers/man3cc4/cplx.intro.3 /usr/compilers/man3cc4/cplxerr.3 /usr/compilers/man3cc4/cplxexp.3 /usr/compilers/man3cc4/cplxops.3 /usr/compilers/man3cc4/cplxtrig.3 /usr/compilers/man3cc4/filebuf.3 /usr/compilers/man3cc4/fstream.3 /usr/compilers/man3cc4/interrupt.3 /usr/compilers/man3cc4/ios.3 /usr/compilers/man3cc4/ios.intro.3 /usr/compilers/man3cc4/istream.3 /usr/compilers/man3cc4/manip.3 /usr/compilers/man3cc4/ostream.3 /usr/compilers/man3cc4/queue.3 /usr/compilers/man3cc4/sbufprot.3 /usr/compilers/man3cc4/sbufpub.3 /usr/compilers/man3cc4/ssbuf.3 /usr/compilers/man3cc4/stdiobuf.3 /usr/compilers/man3cc4/stream_MT.3 /usr/compilers/man3cc4/stream_locker.3 /usr/compilers/man3cc4/strstream.3 /usr/compilers/man3cc4/task.3 /usr/compilers/man3cc4/task.intro.3 /usr/compilers/man3cc4/tasksim.3 /usr/compilers/man3x/_rtc_check_free.3x /usr/compilers/man3x/_rtc_check_malloc.3x /usr/compilers/man3x/_rtc_check_malloc_result.3x /usr/compilers/man3x/_rtc_check_realloc.3x /usr/compilers/man3x/_rtc_check_realloc_result.3x /usr/compilers/man3x/_rtc_hide_region.3x /usr/compilers/man3x/_rtc_off.3x /usr/compilers/man3x/_rtc_on.3x /usr/compilers/man3x/_rtc_record_free.3x /usr/compilers/man3x/_rtc_record_malloc.3x /usr/compilers/man3x/_rtc_record_realloc.3x /usr/compilers/man3x/_rtc_report_error.3x /usr/compilers/man3x/rtc_api.3x /usr/compilers/man4/dbxrc.4 4.7. Admin/Config Impact: No change. 4.8. HA Impact: No change. 4.9. I18N/L10N Impact: Sun Studio C/C++/dbx Collection is I18N L10N to be coordinated with Nevada L10N 4.10. Packaging & Delivery: Name Stability Notes ==== ========= ===== SUNWcompilers Committed C/C++/dbx core cluster SUNWcompilerlinks Committed C/C++/dbx /usr/bin /usr/man links 4.11. Security Impact: No impact. 4.12. Dependencies: SUNWlibC C++ stdlibs SUNWlibms limtsk, etc. SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWesu Extended System Utilities SUNWhea Header files SUNWkvm Core Architecture, (Kvm) SUNWtoo Programming Tools 5. Reference Documents: LSARC/2008/776 GNU Developer Collection LSARC/2006/280 Tools DVD for S10u2 PSARC/2007/074 /usr/gnu Established precedent of having program visible by multiple names. 6. Resources and Schedule: 6.1. Projected Availability: April 2009 to coincide with OpenSolaris 2009.04 6.2. Cost of Effort: .5 developers. 6.3. Cost of Capital Resources: No additional capital resources were required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Devpro 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: TBD 6.4.8. Target Code Design Review Date: Completed 6.4.9. Update approval addition: - SPDE PAC scheduling in progress - Solaris PAC scheduling in progress 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Not applicable. 7. Prototype Availability: 7.1. Prototype Availability: Not applicable. 7.2. Prototype Cost: Not Applicable. From Douglas.Walls@sun.com Fri Jan 23 14:07:03 2009 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 n0NM72Cn001782 for ; Fri, 23 Jan 2009 14:07:03 -0800 (PST) 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 n0NM6xuK011282 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 23 Jan 2009 22:07:01 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 <0KDY008032RO7J00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 14:07:00 -0800 (PST) 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 <0KDY0081J2RNQ7E0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 14:06:59 -0800 (PST) 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 n0NM6xLV023666 for ; Fri, 23 Jan 2009 14:06:59 -0800 (PST) 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 <0KDY001010JK4600@fe-sfbay-10.sun.com> (original mail from Douglas.Walls@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 14:06:59 -0800 (PST) Received: from Douglas-Wallss-Computer.local ([129.150.20.251]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDY00K8B2RFEGF0@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 23 Jan 2009 14:06:55 -0800 (PST) Date: Fri, 23 Jan 2009 14:07:04 -0800 From: Douglas Walls Subject: Re: Bundled Compiler Collection [LSARC/2009/017] In-reply-to: <497A19C3.6090802@sun.com> Sender: Douglas.Walls@sun.com To: Raj Prakash , LSARC-ext@sun.com Cc: Chris Quenelle , David Ford Message-id: <497A3F88.7020905@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: <497A19C3.6090802@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 11626 Obviously I can't do a global search and replace very well :-( Resend with all occurrences of /usr/compilers replaced with /usr/suncc. Douglas Douglas Walls wrote: > Raj, > > Here is the updated case for: Bundled Compiler Collection > [LSARC/2009/017]. I believe all the issues relevant to the proposal have > been addresses. > > Thanks, Douglas > > ------------------ > > There is only one change in this revision of the case, the name of the > directory into which the bundled compiler collection components are > installed has been changed to "/usr/suncc". > > As noted with the last update of the the proposal, this project is to > bundle the Sun C and C++ compilers and dbx into Nevada so to make them > available as the default set of compilers for any distribution of > Solaris. Their relationship to the unbundled compilers of Sun Studio, > how Sun Studio compilers install into versioned directories and how the > Sun Studio compilers can install links to override the default compilers > is explained. How to manipulate $PATH to specify a default compiler is > well > known and not discussed in the proposal. > > ============================================ > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bundled Compiler Collection 1.2. Name of Document Author/Supplier: Douglas Walls (Douglas.Walls@Sun.COM> 1.3. Date of This Document: 1/14/2009 1.3.1. Date this project was conceived: 10/2008 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kurt.Goebel@Sun.Com 1.4.4. The name of your business unit: CODE (C/C++ Compilers, Optimization, and Debugger) 1.5. Email Aliases: 1.5.1. Responsible Manager: Kurt Goebel 1.5.2. Responsible Engineer: Douglas Walls 1.5.3. Marketing Manager: Ikroop Dhillon 1.5.4. Interest List: tools-compilers@opensolaris.org 2. Project Summary 2.1. Project Description: The project will deliver C, C++ and dbx from the current Sun Studio Express release into Nevada through the devpro consolidation. The intent is to bundle Sun compilers into /usr. We are not bundling all of Sun Studio. This collection only contains C and C++ compilers along with their debugger, dbx. 2.2. Risks and Assumptions: No known risks or assumptions at this time. 3. Business Summary 3.1. Problem Area: Default compilers on OpenSolaris Default compilers bundled with all distribution of Solaris 3.2. Market/Requester: OpenSolaris 3.3. Business Justification: Encourage FOSS inclusion into OpenSolaris repositories by minimizing compiler-related porting effort. Provide a bundled set of compilers for any distribution of Solaris. The target customers are people building software on Solaris Nevada derived distributions. Not necessarily people building Solaris itself. The culture of Nevada is for consolidations to deliver the latest semi-stable development builds, which are periodically updated. This closely matches the Sun Studio Express release cycle. 3.4. Competitive Analysis: Main competitors: Platforms & Tool Suite Offerings - Red Hat: GCC (bundled and supported) - Windows: Microsoft Visual Studio (unbundled) - MacOS: Xcode (gcc-based), LLVM effort 3.5. Opportunity Window/Exposure: 04/2009 to coincide with the next release of OpenSolaris. 3.6. How will you know when you are done?: The project will be on-going always tracking the latest express release of Sun Studio C, C++ and dbx 4. Technical Description: 4.1. Details: - The design of the Sun compilers precludes just installing them into /usr/bin, /usr/lib, etc. without significant redesign. We need a location into which to install the compiler components, with symlinks to those components installed in /usr/bin and /usr/share/man. The delivery will install the bundled compiler collection components into /usr/suncc/{bin,lib,...}, with symlinks in /usr/bin and /usr/share/man. We chose the name 'suncc' to intentionally indicate these are the default|builtin|preferred|bundled compilers. There will not be multiple versions of the bundled compilers, there will only be one set of bundled compilers. Versions of the unbundled Sun Studio will continue to install into /opt, i.e. /opt/SSXYYYY.MM, /opt/sunstudio13, /opt/sunstudio14, etc.. Note Sun Studio also provides an optional package for installing links in /usr/bin and /usr/share/man, these would then override the links of this bundled compiler as it does previously installed versions of Sun Studio. - The first delivery will be the C, C++ and dbx components of Sun Studio Express 2008.11 release.. - Links will be created in /usr/bin, e.g. /usr/bin/cc, /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate binaries /usr/suncc. - Links will be created in /usr/man, e.g. /usr/man/man1/cc, /usr/man/man1/CC, /usr/man/man1/dbx, etc., to point to man pages in /usr/suncc/man/man1. 4.2. Bug/RFE Number(s): Not applicable. 4.3. In Scope: - C, C++ compilers and dbx 4.4. Out of Scope: 4.5. Interfaces: The following soft links will be created in /usr/bin to point to the appropriate binaries of /usr/suncc/bin. We may choose to omit some of these links which do not contribute to minimizing compiler-related porting efforts to encourage FOSS inclusion into OpenSolaris repositories. /usr/bin/bcheck /usr/bin/c++filt /usr/bin/c89 /usr/bin/c99 /usr/bin/cb /usr/bin/cc /usr/bin/CC /usr/bin/CCadmin /usr/bin/cflow /usr/bin/cscope /usr/bin/ctcr /usr/bin/ctrace /usr/bin/cxref /usr/bin/dbx /usr/bin/dem /usr/bin/dumpstabs /usr/bin/dwarfdump /usr/bin/fbe /usr/bin/fpversion /usr/bin/indent /usr/bin/lint /usr/bin/rtc_patch_area /usr/bin/sunc89 /usr/bin/sunc99 /usr/bin/suncc /usr/bin/sunCC /usr/bin/tcov 4.6. Doc Impact: Links will be created in /usr/share/man/* for the following man pages: /usr/suncc/man1/CC.1 /usr/suncc/man1/CCadmin.1 /usr/suncc/man1/bcheck.1 /usr/suncc/man1/binopt.1 /usr/suncc/man1/c++filt.1 /usr/suncc/man1/c89.1 /usr/suncc/man1/c99.1 /usr/suncc/man1/cb.1 /usr/suncc/man1/cc.1 /usr/suncc/man1/cflow.1 /usr/suncc/man1/cscope.1 /usr/suncc/man1/ctrace.1 /usr/suncc/man1/cxref.1 /usr/suncc/man1/dbx.1 /usr/suncc/man1/dem.1 /usr/suncc/man1/fbe.1 /usr/suncc/man1/fpversion.1 /usr/suncc/man1/indent.1 /usr/suncc/man1/inline.1 /usr/suncc/man1/lint.1 /usr/suncc/man1/rtc_patch_area.1 /usr/suncc/man1/ss_attach.1 /usr/suncc/man3/gcFixPrematureFrees.3 /usr/suncc/man3/gcInitialize.3 /usr/suncc/man3cc4/cartpol.3 /usr/suncc/man3cc4/cplx.intro.3 /usr/suncc/man3cc4/cplxerr.3 /usr/suncc/man3cc4/cplxexp.3 /usr/suncc/man3cc4/cplxops.3 /usr/suncc/man3cc4/cplxtrig.3 /usr/suncc/man3cc4/filebuf.3 /usr/suncc/man3cc4/fstream.3 /usr/suncc/man3cc4/interrupt.3 /usr/suncc/man3cc4/ios.3 /usr/suncc/man3cc4/ios.intro.3 /usr/suncc/man3cc4/istream.3 /usr/suncc/man3cc4/manip.3 /usr/suncc/man3cc4/ostream.3 /usr/suncc/man3cc4/queue.3 /usr/suncc/man3cc4/sbufprot.3 /usr/suncc/man3cc4/sbufpub.3 /usr/suncc/man3cc4/ssbuf.3 /usr/suncc/man3cc4/stdiobuf.3 /usr/suncc/man3cc4/stream_MT.3 /usr/suncc/man3cc4/stream_locker.3 /usr/suncc/man3cc4/strstream.3 /usr/suncc/man3cc4/task.3 /usr/suncc/man3cc4/task.intro.3 /usr/suncc/man3cc4/tasksim.3 /usr/suncc/man3x/_rtc_check_free.3x /usr/suncc/man3x/_rtc_check_malloc.3x /usr/suncc/man3x/_rtc_check_malloc_result.3x /usr/suncc/man3x/_rtc_check_realloc.3x /usr/suncc/man3x/_rtc_check_realloc_result.3x /usr/suncc/man3x/_rtc_hide_region.3x /usr/suncc/man3x/_rtc_off.3x /usr/suncc/man3x/_rtc_on.3x /usr/suncc/man3x/_rtc_record_free.3x /usr/suncc/man3x/_rtc_record_malloc.3x /usr/suncc/man3x/_rtc_record_realloc.3x /usr/suncc/man3x/_rtc_report_error.3x /usr/suncc/man3x/rtc_api.3x /usr/suncc/man4/dbxrc.4 4.7. Admin/Config Impact: No change. 4.8. HA Impact: No change. 4.9. I18N/L10N Impact: Sun Studio C/C++/dbx Collection is I18N L10N to be coordinated with Nevada L10N 4.10. Packaging & Delivery: Name Stability Notes ==== ========= ===== SUNWcompilers Committed C/C++/dbx core cluster SUNWcompilerlinks Committed C/C++/dbx /usr/bin /usr/man links 4.11. Security Impact: No impact. 4.12. Dependencies: SUNWlibC C++ stdlibs SUNWlibms limtsk, etc. SUNWcar Core Architecture, (Root) SUNWcsd Core Solaris Devices SUNWcsr Core Solaris, (Root) SUNWcsu Core Solaris, (Usr) SUNWesu Extended System Utilities SUNWhea Header files SUNWkvm Core Architecture, (Kvm) SUNWtoo Programming Tools 5. Reference Documents: LSARC/2008/776 GNU Developer Collection LSARC/2006/280 Tools DVD for S10u2 PSARC/2007/074 /usr/gnu Established precedent of having program visible by multiple names. 6. Resources and Schedule: 6.1. Projected Availability: April 2009 to coincide with OpenSolaris 2009.04 6.2. Cost of Effort: .5 developers. 6.3. Cost of Capital Resources: No additional capital resources were required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Devpro 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: TBD 6.4.8. Target Code Design Review Date: Completed 6.4.9. Update approval addition: - SPDE PAC scheduling in progress - Solaris PAC scheduling in progress 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Not applicable. 7. Prototype Availability: 7.1. Prototype Availability: Not applicable. 7.2. Prototype Cost: Not Applicable. From Raj.Prakash@sun.com Tue Jan 27 08:57:38 2009 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 n0RGvc8c012438 for ; Tue, 27 Jan 2009 08:57:38 -0800 (PST) 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 n0RGvXgU011432 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 27 Jan 2009 08:57:38 -0800 (PST) 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 <0KE500I01341VX00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 27 Jan 2009 09:57:37 -0700 (MST) 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 <0KE5007W9340IL90@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 27 Jan 2009 09:57:36 -0700 (MST) 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 n0RGvaeg021193 for ; Tue, 27 Jan 2009 08:57:36 -0800 (PST) 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 <0KE5005012PFR600@fe-sfbay-10.sun.com> (original mail from Raj.Prakash@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 27 Jan 2009 08:57:36 -0800 (PST) Received: from [129.145.154.104] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE500I1633QUT10@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 27 Jan 2009 08:57:35 -0800 (PST) Date: Tue, 27 Jan 2009 08:57:26 -0800 From: Raj Prakash Subject: Re: Bundled Compiler Collection [LSARC/2009/017] In-reply-to: <497A3F88.7020905@sun.com> Sender: Raj.Prakash@sun.com To: Douglas Walls , LSARC-ext@sun.com Cc: Chris Quenelle , David Ford Message-id: <497F3CF6.1060902@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: <497A19C3.6090802@sun.com> <497A3F88.7020905@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 12267 All outstanding issues for this case have now been resolved. The case is now approved. Thanks, Raj On 01/23/09 02:07 PM, Douglas Walls wrote: > Obviously I can't do a global search and replace very well :-( > Resend with all occurrences of /usr/compilers replaced with /usr/suncc. > > Douglas > > Douglas Walls wrote: >> Raj, >> >> Here is the updated case for: Bundled Compiler Collection >> [LSARC/2009/017]. I believe all the issues relevant to the proposal >> have >> been addresses. >> >> Thanks, Douglas >> >> ------------------ >> >> There is only one change in this revision of the case, the name of the >> directory into which the bundled compiler collection components are >> installed has been changed to "/usr/suncc". >> >> As noted with the last update of the the proposal, this project is to >> bundle the Sun C and C++ compilers and dbx into Nevada so to make them >> available as the default set of compilers for any distribution of >> Solaris. Their relationship to the unbundled compilers of Sun Studio, >> how Sun Studio compilers install into versioned directories and how the >> Sun Studio compilers can install links to override the default compilers >> is explained. How to manipulate $PATH to specify a default compiler >> is well >> known and not discussed in the proposal. >> >> ============================================ >> > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: Bundled Compiler Collection > > 1.2. Name of Document Author/Supplier: > Douglas Walls (Douglas.Walls@Sun.COM> > > 1.3. Date of This Document: 1/14/2009 > 1.3.1. Date this project was conceived: 10/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): OpenSolaris > 1.4.1. The PAC or CPT you expect to review your project: SPDE PAC > 1.4.2. The ARC(s) you expect to review your project: LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: > Kurt.Goebel@Sun.Com > 1.4.4. The name of your business unit: CODE (C/C++ Compilers, > Optimization, and Debugger) > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Kurt Goebel > 1.5.2. Responsible Engineer: Douglas Walls > > 1.5.3. Marketing Manager: Ikroop Dhillon > 1.5.4. Interest List: tools-compilers@opensolaris.org > > 2. Project Summary > 2.1. Project Description: > > The project will deliver C, C++ and dbx from the current Sun > Studio Express release into Nevada through the devpro > consolidation. The intent is to bundle Sun compilers into > /usr. We are not bundling all of Sun Studio. This collection > only contains C and C++ compilers along with their debugger, > dbx. > > 2.2. Risks and Assumptions: > No known risks or assumptions at this time. > > 3. Business Summary > 3.1. Problem Area: > Default compilers on OpenSolaris > Default compilers bundled with all distribution of Solaris > > 3.2. Market/Requester: > OpenSolaris > > 3.3. Business Justification: > Encourage FOSS inclusion into OpenSolaris repositories by > minimizing compiler-related porting effort. > > Provide a bundled set of compilers for any distribution of > Solaris. > > The target customers are people building software on Solaris > Nevada derived distributions. Not necessarily people building > Solaris itself. The culture of Nevada is for consolidations to > deliver the latest semi-stable development builds, which are > periodically updated. This closely matches the Sun Studio > Express release cycle. > > 3.4. Competitive Analysis: > Main competitors: Platforms & Tool Suite Offerings > - Red Hat: GCC (bundled and supported) > - Windows: Microsoft Visual Studio (unbundled) > - MacOS: Xcode (gcc-based), LLVM effort > > 3.5. Opportunity Window/Exposure: > 04/2009 to coincide with the next release of OpenSolaris. > > 3.6. How will you know when you are done?: > The project will be on-going always tracking the latest express > release of Sun Studio C, C++ and dbx > > 4. Technical Description: > 4.1. Details: > > - The design of the Sun compilers precludes just installing > them into /usr/bin, /usr/lib, etc. without significant > redesign. We need a location into which to install the > compiler components, with symlinks to those components > installed in /usr/bin and /usr/share/man. The delivery will > install the bundled compiler collection components into > /usr/suncc/{bin,lib,...}, with symlinks in /usr/bin and > /usr/share/man. We chose the name 'suncc' to intentionally > indicate these are the default|builtin|preferred|bundled > compilers. There will not be multiple versions of the bundled > compilers, there will only be one set of bundled compilers. > Versions of the unbundled Sun Studio will continue to install > into /opt, i.e. /opt/SSXYYYY.MM, /opt/sunstudio13, > /opt/sunstudio14, etc.. Note Sun Studio also provides an > optional package for installing links in /usr/bin and > /usr/share/man, these would then override the links of this > bundled compiler as it does previously installed versions of > Sun Studio. > > - The first delivery will be the C, C++ and dbx components of > Sun Studio Express 2008.11 release.. > > - Links will be created in /usr/bin, e.g. /usr/bin/cc, > /usr/bin/CC, /usr/bin/dbx, etc., to point to the appropriate > binaries /usr/suncc. > > - Links will be created in /usr/man, e.g. /usr/man/man1/cc, > /usr/man/man1/CC, /usr/man/man1/dbx, etc., to > point to man pages in /usr/suncc/man/man1. > > 4.2. Bug/RFE Number(s): > Not applicable. > > 4.3. In Scope: > - C, C++ compilers and dbx > > 4.4. Out of Scope: > > > 4.5. Interfaces: > > The following soft links will be created in /usr/bin to point to > the appropriate binaries of /usr/suncc/bin. We > may choose to omit some of these links which do not contribute > to minimizing compiler-related porting efforts to encourage FOSS > inclusion into OpenSolaris repositories. > > /usr/bin/bcheck > /usr/bin/c++filt > /usr/bin/c89 > /usr/bin/c99 > /usr/bin/cb > /usr/bin/cc > /usr/bin/CC > /usr/bin/CCadmin > /usr/bin/cflow > /usr/bin/cscope > /usr/bin/ctcr > /usr/bin/ctrace > /usr/bin/cxref > /usr/bin/dbx > /usr/bin/dem > /usr/bin/dumpstabs > /usr/bin/dwarfdump > /usr/bin/fbe > /usr/bin/fpversion > /usr/bin/indent > /usr/bin/lint > /usr/bin/rtc_patch_area > /usr/bin/sunc89 > /usr/bin/sunc99 > /usr/bin/suncc > /usr/bin/sunCC > /usr/bin/tcov > > 4.6. Doc Impact: > > Links will be created in /usr/share/man/* for the following > man pages: > > /usr/suncc/man1/CC.1 > /usr/suncc/man1/CCadmin.1 > /usr/suncc/man1/bcheck.1 > /usr/suncc/man1/binopt.1 > /usr/suncc/man1/c++filt.1 > /usr/suncc/man1/c89.1 > /usr/suncc/man1/c99.1 > /usr/suncc/man1/cb.1 > /usr/suncc/man1/cc.1 > /usr/suncc/man1/cflow.1 > /usr/suncc/man1/cscope.1 > /usr/suncc/man1/ctrace.1 > /usr/suncc/man1/cxref.1 > /usr/suncc/man1/dbx.1 > /usr/suncc/man1/dem.1 > /usr/suncc/man1/fbe.1 > /usr/suncc/man1/fpversion.1 > /usr/suncc/man1/indent.1 > /usr/suncc/man1/inline.1 > /usr/suncc/man1/lint.1 > /usr/suncc/man1/rtc_patch_area.1 > /usr/suncc/man1/ss_attach.1 > /usr/suncc/man3/gcFixPrematureFrees.3 > /usr/suncc/man3/gcInitialize.3 > /usr/suncc/man3cc4/cartpol.3 > /usr/suncc/man3cc4/cplx.intro.3 > /usr/suncc/man3cc4/cplxerr.3 > /usr/suncc/man3cc4/cplxexp.3 > /usr/suncc/man3cc4/cplxops.3 > /usr/suncc/man3cc4/cplxtrig.3 > /usr/suncc/man3cc4/filebuf.3 > /usr/suncc/man3cc4/fstream.3 > /usr/suncc/man3cc4/interrupt.3 > /usr/suncc/man3cc4/ios.3 > /usr/suncc/man3cc4/ios.intro.3 > /usr/suncc/man3cc4/istream.3 > /usr/suncc/man3cc4/manip.3 > /usr/suncc/man3cc4/ostream.3 > /usr/suncc/man3cc4/queue.3 > /usr/suncc/man3cc4/sbufprot.3 > /usr/suncc/man3cc4/sbufpub.3 > /usr/suncc/man3cc4/ssbuf.3 > /usr/suncc/man3cc4/stdiobuf.3 > /usr/suncc/man3cc4/stream_MT.3 > /usr/suncc/man3cc4/stream_locker.3 > /usr/suncc/man3cc4/strstream.3 > /usr/suncc/man3cc4/task.3 > /usr/suncc/man3cc4/task.intro.3 > /usr/suncc/man3cc4/tasksim.3 > /usr/suncc/man3x/_rtc_check_free.3x > /usr/suncc/man3x/_rtc_check_malloc.3x > /usr/suncc/man3x/_rtc_check_malloc_result.3x > /usr/suncc/man3x/_rtc_check_realloc.3x > /usr/suncc/man3x/_rtc_check_realloc_result.3x > /usr/suncc/man3x/_rtc_hide_region.3x > /usr/suncc/man3x/_rtc_off.3x > /usr/suncc/man3x/_rtc_on.3x > /usr/suncc/man3x/_rtc_record_free.3x > /usr/suncc/man3x/_rtc_record_malloc.3x > /usr/suncc/man3x/_rtc_record_realloc.3x > /usr/suncc/man3x/_rtc_report_error.3x > /usr/suncc/man3x/rtc_api.3x > /usr/suncc/man4/dbxrc.4 > > 4.7. Admin/Config Impact: > No change. > > 4.8. HA Impact: > No change. > > 4.9. I18N/L10N Impact: > Sun Studio C/C++/dbx Collection is I18N > L10N to be coordinated with Nevada L10N > > 4.10. Packaging & Delivery: > Name Stability Notes > ==== ========= ===== > SUNWcompilers Committed C/C++/dbx core > cluster > SUNWcompilerlinks Committed C/C++/dbx > /usr/bin /usr/man links > > 4.11. Security Impact: > No impact. > > 4.12. Dependencies: > SUNWlibC C++ stdlibs > SUNWlibms limtsk, etc. > SUNWcar Core Architecture, (Root) > SUNWcsd Core Solaris Devices > SUNWcsr Core Solaris, (Root) > SUNWcsu Core Solaris, (Usr) > SUNWesu Extended System Utilities > SUNWhea Header files > SUNWkvm Core Architecture, (Kvm) > SUNWtoo Programming Tools > > 5. Reference Documents: > LSARC/2008/776 GNU Developer Collection > LSARC/2006/280 Tools DVD for S10u2 > PSARC/2007/074 /usr/gnu > Established precedent of having program visible by multiple > names. > > 6. Resources and Schedule: > 6.1. Projected Availability: > April 2009 to coincide with OpenSolaris 2009.04 > > 6.2. Cost of Effort: > .5 developers. > > 6.3. Cost of Capital Resources: > No additional capital resources were required. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > Devpro > 6.4.3. Type of CPT Review and Approval expected: > FastTrack > 6.4.4. Project Boundary Conditions: > > 6.4.5. Is this a necessary project for OEM agreements: > No > 6.4.6. Notes: > > 6.4.7. Target RTI Date/Release: > TBD > 6.4.8. Target Code Design Review Date: > Completed > > 6.4.9. Update approval addition: > - SPDE PAC scheduling in progress > - Solaris PAC scheduling in progress > > 6.5. ARC review type: > FastTrack > > 6.6. ARC Exposure: > open > 6.6.1. Rationale: > Not applicable. > > 7. Prototype Availability: > 7.1. Prototype Availability: > Not applicable. > > 7.2. Prototype Cost: > Not Applicable.