From sacadmin Thu May 25 12:29:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PJTgtr009407 for ; Thu, 25 May 2006 12:29:42 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PJTg0f966603; Thu, 25 May 2006 12:29:42 -0700 (PDT) Message-ID: <44760590.6060400@eng.sun.com> Date: Thu, 25 May 2006 12:29:20 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, Ali Bahrami CC: Rod.Evans@sun.com Subject: 2006/353: ld(1) output file removal - change default behavior Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5236 I'm sponsoring the following case for Ali Bahrami. Timeout 06/01/06. ----------------------------------------------------------------------- I would like to change the policy used by the Solaris linker when creating a new sharable library output file. The current policy is described in the ld(1) man page: If the file being created by ld already exists, the file is truncated after all input files have been processed. The existing file is overridden with the new file contents. ld does not create a temporary file as part of the link-edit, since multiple instances of large output files frequently exhaust system resources. The drawback of overriding an existing file occurs if the file is in use by a running pro- cess. In this case, the process might be prematurely ter- minated as the output files image is created. This situation can be avoided by removing the output file before performing the link-edit. This removal is not detrimental to the run- ning process. The removal frees up the file system namespace, not the actual disk space, for the new output file creation. The disk space of a removed file is freed when the last process referencing the file terminates. Most developers have experienced the situation where they rebuild a sharable library, and a currently running program suddenly crashes and dumps core. This is usually a minor issue, and quickly diagnosed, although sometimes it can take a while to understand. It seems odd to have a policy that causes running programs to die in an uncontrolled way. Such a policy might make sense if there was a significant benefit to counterbalance the negatives, but I do not think that is the case here. The current policy has two user visible aspects that might be construed in a positive light: - Disk space conservation - Inode number of the existing output file remains unchanged. I question the assumption that this policy helps with the problem of exhausting system resources when generating large output files. The resource likely to be exhausted is available virtual memory, not disk space to hold the results. The same amount of memory is required by ld whether you create a new file or overwrite the existing one. The only resource the current policy conserves is disk space. Perhaps disk space was a realistic constraint on linker output 20+ years ago, in the world of 20MB disks, but it seems unlikely that this could be the case today. The amount of disk space consumed by even the largest library pales in comparison to the smallest available disk, and the extra space only remains in use while a program is running against it. It may be possible that there is a situation in which the inode number remaining unchanged is important. However, in my discussions with others, I have yet to see what that situation would be. This seems to be more of an implementation detail than a feature. I am very interested to hear if others have encountered a scenario where this mattered. It can be interesting to see how our competitors handle this issue. Before joining Sun, I worked on highly portable software that uses sharable libraries. I called a friend who still works there and asked him to carry out the following experiment for me under Solaris, Linux, and Mac OS X, using his development workspace: 1) Check the inode number of the main sharable library (/bin/ls -i). 2) Start the program running. 3) Rebuild the sharable library, by removing one of the .o files used to build it, and then running make(1). 4) Check the inode number of the new version of the sharable library. Did it change? 5) Did the running program crash? It turns out that Linux and Mac OS X unlink the output file before generating the new one: The inode changed, and the program did not crash. Under Solaris, as we would expect, the inode did not change and the program did crash. Both Linux and the Macintosh have large development communities. If there was a significant problem with having the linker remove the existing file before creating the new one, it would be well known. My friend also checked how MS Windows handles this case: Windows prevents write access to a file that is in use by a running program. The linker therefore fails with an error. This is less elegant, but does prevent a change to the library (DLL) from corrupting a running program. Absent a convincing counter argument, I propose that we modify ld so that the work around suggested in the man page becomes standard behavior. ld should unlink the existing file, and create a new one in its place. It has been suggested that we could add an ld option to offer this new behavior, while retaining the old behavior as the default. I think that is the wrong way to go: This change will have little benefit unless it is the default, and it presents little or no end user impact. If it is felt that the existing behavior should be retained, I believe that a better approach is to change the default, and provide a command line option to re-enable the old behavior. ----------------------------------------------------------------------- -- Rod. From sacadmin Thu May 25 12:55:05 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PJt5Wd010815 for ; Thu, 25 May 2006 12:55:05 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PJt2O2002936; Thu, 25 May 2006 15:55:02 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PJt2Uo015741; Thu, 25 May 2006 15:55:02 -0400 (EDT) Subject: Re: 2006/353: ld(1) output file removal - change default behavior From: Bill Sommerfeld To: Rod.Evans@sun.com Cc: psarc@sac.sfbay.sun.com, Ali Bahrami In-Reply-To: <44760590.6060400@eng.sun.com> References: <44760590.6060400@eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1148586901.14234.21.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 25 May 2006 15:55:02 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 364 On Thu, 2006-05-25 at 15:29, Rod Evans wrote: > I would like to change the policy used by the Solaris > linker when creating a new sharable library output file. I agree that unlink-before-create is the sensible thing to do here -- but why only change this for shared libraries? Shouldn't the linker be consistent about this for all output types? - Bill From sacadmin Thu May 25 13:49:30 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PKnUQh012916 for ; Thu, 25 May 2006 13:49:30 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PKnUbD017147 for ; Thu, 25 May 2006 13:49:30 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4PKnTmO005963 for ; Thu, 25 May 2006 14:49:29 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZU00C019Q3AQ00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 25 May 2006 14:49:29 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZU00CB09UGBNS2@mail-amer.sun.com>; Thu, 25 May 2006 14:49:29 -0600 (MDT) Date: Thu, 25 May 2006 14:49:07 -0600 From: Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-reply-to: <1148586901.14234.21.camel@thunk> Sender: Ali.Bahrami@Sun.COM To: Bill Sommerfeld Cc: Rod.Evans@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <44761843.9010904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <44760590.6060400@eng.sun.com> <1148586901.14234.21.camel@thunk> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 769 Bill Sommerfeld wrote: > On Thu, 2006-05-25 at 15:29, Rod Evans wrote: > >>I would like to change the policy used by the Solaris >>linker when creating a new sharable library output file. > > > I agree that unlink-before-create is the sensible thing to do here -- > but why only change this for shared libraries? > > Shouldn't the linker be consistent about this for all output types? > > - Bill > > Yes, that is my intent. I should have said "when creating a new output file". In my experience, sharable libraries are the most likely to get into this particular type of trouble, hence my focus on them in the description. However, executable files can also get into the same situation, and it makes sense to treat all output files the same way. - Ali From sacadmin Thu May 25 13:57:22 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PKvMTf013674 for ; Thu, 25 May 2006 13:57:22 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id k4PKvMDP011704; Thu, 25 May 2006 13:57:22 -0700 (PDT) Message-Id: <200605252057.k4PKvMDP011704@spartan.SFBay.Sun.COM> Date: Thu, 25 May 2006 13:57:22 -0700 (PDT) From: Don Cragun Reply-To: Don Cragun Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: ali.bahrami@Sun.COM Cc: psarc@sac.sfbay.sun.com, Rod.Evans@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8wWkt94vfSDkFd63I0TJ9Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1970 >Date: Thu, 25 May 2006 12:29:20 -0700 >From: Rod Evans > >The current policy has two user visible aspects that might be >construed in a positive light: > > - Disk space conservation > - Inode number of the existing output file remains > unchanged. > ... ... ... > >It may be possible that there is a situation in which the inode >number remaining unchanged is important. However, in my discussions >with others, I have yet to see what that situation would be. This >seems to be more of an implementation detail than a feature. >I am very interested to hear if others have encountered >a scenario where this mattered. > The case where it matters that the inode number doesn't change is if you have hard links to the file that is being updated. If you remove the file, the links are broken and only one of the formerly linked files is updated. This may not be important on shared libraries, but it is (or at least used to be) very important on some executables. ... ... ... > >Absent a convincing counter argument, I propose that we modify ld so that >the work around suggested in the man page becomes standard behavior. >ld should unlink the existing file, and create a new one in its place. I have no problem with this as long as their is only one link to the file being removed. > >It has been suggested that we could add an ld option to offer this >new behavior, while retaining the old behavior as the default. >I think that is the wrong way to go: This change will have little >benefit unless it is the default, and it presents little or no >end user impact. If it is felt that the existing behavior should >be retained, I believe that a better approach is to change the >default, and provide a command line option to re-enable the old >behavior. > If there are multiple hard links to the file in question, I believe it would be much better to give an error, or require an option or user interaction before breaking the links. - Don From sacadmin Thu May 25 14:05:28 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PL5RJj014220 for ; Thu, 25 May 2006 14:05:28 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4PL5RKX020503; Thu, 25 May 2006 16:05:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4PL5RKI020502; Thu, 25 May 2006 16:05:27 -0500 (CDT) Date: Thu, 25 May 2006 16:05:26 -0500 From: Nicolas Williams To: Don Cragun Cc: Ali.Bahrami@sun.com, psarc@sac.sfbay.sun.com, Rod.Evans@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior Message-ID: <20060525210526.GG11607@binky.Central.Sun.COM> References: <200605252057.k4PKvMDP011704@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605252057.k4PKvMDP011704@spartan.SFBay.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 991 On Thu, May 25, 2006 at 01:57:22PM -0700, Don Cragun wrote: > The case where it matters that the inode number doesn't change is if > you have hard links to the file that is being updated. If you remove > the file, the links are broken and only one of the formerly linked > files is updated. This may not be important on shared libraries, but > it is (or at least used to be) very important on some executables. But that should be an install issue, not a build issue. In any case, ld could warn about this, or revert to old behaviour in the link count on the output file is >1. Or give it an option, or never mind. > If there are multiple hard links to the file in question, I believe it > would be much better to give an error, or require an option or user > interaction before breaking the links. Either way ld would be breaking something: either by breaking the links or by stepping all over the contents of a file that may be in use. I think the former is better than the latter. From sacadmin Thu May 25 14:35:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PLZCrD015403 for ; Thu, 25 May 2006 14:35:13 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4PLZ2tS202918; Thu, 25 May 2006 14:35:11 -0700 (PDT) Message-Id: <200605252135.k4PLZ2tS202918@jurassic.eng.sun.com> Date: Thu, 25 May 2006 11:34:41 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: ali.bahrami@sun.com, don.cragun@sun.com Cc: psarc@sac.sfbay.sun.com, Rod.Evans@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lyGUyViKWY2H9zJBQiYE9g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 638 > From: Don Cragun ... > The case where it matters that the inode number doesn't change is if > you have hard links to the file that is being updated. If you remove > the file, the links are broken and only one of the formerly linked > files is updated. This may not be important on shared libraries, but > it is (or at least used to be) very important on some executables. Don might know for sure (and it's just irrelevant history), but I think at one time on AT&T (SVr3?) the links between the aliases for shared objects were hardlinks. Perhaps this behavior has its root there. Its so long ago .... - jek3 From sacadmin Thu May 25 14:36:44 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PLahSb015416 for ; Thu, 25 May 2006 14:36:43 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4PLaYJ0206251; Thu, 25 May 2006 14:36:42 -0700 (PDT) Message-Id: <200605252136.k4PLaYJ0206251@jurassic.eng.sun.com> Date: Thu, 25 May 2006 11:36:12 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: don.cragun@sun.com, Nicolas.Williams@sun.com Cc: ali.bahrami@sun.com, psarc@sac.sfbay.sun.com, Rod.Evans@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IRB4fioxD500LnSvE0mCww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 160 > But that should be an install issue, not a build issue. Some people build in place. Go figure. The whole AT&T build worked this way at one time. - jek3 From sacadmin Thu May 25 14:55:53 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PLtrSZ016361 for ; Thu, 25 May 2006 14:55:53 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id k4PLtrPG011766; Thu, 25 May 2006 14:55:53 -0700 (PDT) Message-Id: <200605252155.k4PLtrPG011766@spartan.SFBay.Sun.COM> Date: Thu, 25 May 2006 14:55:53 -0700 (PDT) From: Don Cragun Reply-To: Don Cragun Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: ali.bahrami@Sun.COM Cc: psarc@sac.sfbay.sun.com, Rod.Evans@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zzYH8pFYYISIJ7HICvQVQA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 509 >Date: Thu, 25 May 2006 11:34:41 -1000 (HST) >From: Joseph Kowalski > >Don might know for sure (and it's just irrelevant history), but I think >at one time on AT&T (SVr3?) the links between the aliases for shared objects >were hardlinks. Perhaps this behavior has its root there. This behavior had its roots long before shared objects existed. It had its roots in things like cp, ln, and mv being hardlinks to a single a.out file. - Don > >Its so long ago .... > >- jek3 From sacadmin Thu May 25 15:10:53 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PMApaW016935 for ; Thu, 25 May 2006 15:10:53 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4PMAI6c247522; Thu, 25 May 2006 15:10:39 -0700 (PDT) Message-Id: <200605252210.k4PMAI6c247522@jurassic.eng.sun.com> Date: Thu, 25 May 2006 12:10:08 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: psarc@sac.sfbay.sun.com, ali.bahrami@sun.com, Rod.Evans@sun.com Cc: Rod.Evans@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 08F9Hj2lw8H2fHQtDDXg3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 424 I didn't see a release binding in the specification. Given the potential incompatibilities mentioned, I tend to think a Minor release binding is appropriate. Ali? Rod? What is the requested release binding? Also: I believe that a better approach is to change the default, and provide a command line option to re-enable the old behavior. Is that option part of this case? If so, it needs to be specified. - jek3 From sacadmin Thu May 25 15:40:05 2006 Received: from norton.SFBay.Sun.COM (norton.SFBay.Sun.COM [129.146.228.124]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PMe5eL018184 for ; Thu, 25 May 2006 15:40:05 -0700 (PDT) Received: from norton.SFBay.Sun.COM (localhost [127.0.0.1]) by norton.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4PMe4VB124127; Thu, 25 May 2006 15:40:04 -0700 (PDT) Received: (from jwadams@localhost) by norton.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4PMe4eF124126; Thu, 25 May 2006 15:40:04 -0700 (PDT) Date: Thu, 25 May 2006 15:40:03 -0700 From: Jonathan Adams To: Rod.Evans@sun.com Cc: psarc@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior Message-ID: <20060525224003.GA124097@eng.sun.com> References: <44760590.6060400@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44760590.6060400@eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 994 On Thu, May 25, 2006 at 12:29:20PM -0700, Rod Evans wrote: > It turns out that Linux and Mac OS X unlink the output file > before generating the new one: The inode changed, and the program > did not crash. Under Solaris, as we would expect, the inode did not > change and the program did crash. > > Both Linux and the Macintosh have large development communities. > If there was a significant problem with having the linker remove > the existing file before creating the new one, it would be well known. > > My friend also checked how MS Windows handles this case: Windows > prevents write access to a file that is in use by a running program. > The linker therefore fails with an error. This is less elegant, > but does prevent a change to the library (DLL) from corrupting > a running program. Actually, Linux does this as well; trying to overwrite a file which has been mapped executable somewhere will return ETXTBSY. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development From sacadmin Thu May 25 16:02:31 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PN2UqE020280 for ; Thu, 25 May 2006 16:02:30 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PN2U8R023169 for ; Thu, 25 May 2006 16:02:30 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4PN2UmO010805 for ; Thu, 25 May 2006 17:02:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZU00501EZB8T00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.SFBay.Sun.COM; Thu, 25 May 2006 17:02:30 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZU00C2ZG04BNW2@mail-amer.sun.com>; Thu, 25 May 2006 17:02:30 -0600 (MDT) Date: Thu, 25 May 2006 17:02:08 -0600 From: Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-reply-to: <200605252155.k4PLtrPG011766@spartan.SFBay.Sun.COM> Sender: Ali.Bahrami@Sun.COM To: Don Cragun Cc: psarc@sac.sfbay.sun.com, Rod.Evans@Sun.COM Message-id: <44763770.5090907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200605252155.k4PLtrPG011766@spartan.SFBay.Sun.COM> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 1783 Don points out that this proposal will break hard links if the output file has a link count > 1. The specified name will get the new file (and a new inode), while the aliases end up with the old one. This is true. I went back to my friend and asked him to do the experiment on Linux and MacOSX and let me know what they do. The answer is that they both quietly (no warning) break the hard link and create the new file with a new inode. Since both of these systems use the same linker (GNU ld), it isn't surprising that both do the same thing. Some observations: - It can't be that common to build executables in place, because all those Linux/OSX/GnuLD people would be running into this issue. The fact that they don't suggests that it will be OK. - When I was developing IDL (the portable software I referred to in the original description), our makefile would explicitly remove the "alias" links after the link, and then recreate them. I think this is probably pretty common in multi-platform software. - It is historically true (ATT, old SunOS) that in place building occurred, but it hasn't been the case for a long time. It's hard to imagine that we would move away from the use of a staging "proto" area and back to in-place. - If portable software doesn't have this problem (their makefiles handle it), and Sun developed software doesn't have it (we use a proto area, and installers), then that leaves 3rd parties who only develop for Solaris, create executables directly into their final installed locations, and use hard links to give those executables multiple names (without recreating the links each time). That can't be a very large group. - Ali From sacadmin Thu May 25 16:13:08 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PND71G020516 for ; Thu, 25 May 2006 16:13:08 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PND6cD021115; Thu, 25 May 2006 19:13:06 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PND6Bo017116; Thu, 25 May 2006 19:13:06 -0400 (EDT) Subject: Re: 2006/353: ld(1) output file removal - change default behavior From: Bill Sommerfeld To: Jonathan Adams Cc: Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali Bahrami In-Reply-To: <20060525224003.GA124097@eng.sun.com> References: <44760590.6060400@eng.sun.com> <20060525224003.GA124097@eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1148598785.14234.400.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 25 May 2006 19:13:06 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 669 On Thu, 2006-05-25 at 18:40, Jonathan Adams wrote: > Actually, Linux does this as well; trying to overwrite a file which has been > mapped executable somewhere will return ETXTBSY. it's not just linux; I've also verified that you also get ETXTBSY on netbsd, aix, and hpux. Solaris appears to be the outlier. netbsd's linker unlinks before opening the output file. hp-ux's does not: # cc -o foo foo.c /usr/ccs/bin/ld: Can't create foo /usr/ccs/bin/ld: Text file busy The aix system I found didn't have a compiler on it, but I managed to provoke: ld: 0711-851 SEVERE ERROR: Output file: foo The file is in use and cannot be overwritten. - Bill From sacadmin Thu May 25 16:15:17 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PNFGLF020530 for ; Thu, 25 May 2006 16:15:16 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PNFDMk006310; Thu, 25 May 2006 19:15:13 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PNF8st017123; Thu, 25 May 2006 19:15:10 -0400 (EDT) Subject: Re: 2006/353: ld(1) output file removal - change default behavior From: Bill Sommerfeld To: Joseph Kowalski Cc: don.cragun@sun.com, Nicolas.Williams@sun.com, Ali.Bahrami@sun.com, psarc@sac.sfbay.sun.com, Rod.Evans@sun.com In-Reply-To: <200605252136.k4PLaYJ0206251@jurassic.eng.sun.com> References: <200605252136.k4PLaYJ0206251@jurassic.eng.sun.com> Content-Type: text/plain Message-Id: <1148598907.14234.406.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Thu, 25 May 2006 19:15:08 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 535 On Thu, 2006-05-25 at 17:36, Joseph Kowalski wrote: > Some people build in place. Go figure. The whole AT&T build worked this > way at one time. on the other hand, the makefiles of every unix-based build system I've worked on since circa 1984 has pointed cc/ld at either the source tree or a parallel object tree rather than at the "live" installed system. when it comes to interacting with the live system the behavior of the "install" command (as well as any packaging tools) is generally more interesting.. - Bill From sacadmin Thu May 25 16:17:08 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PNH83a020544 for ; Thu, 25 May 2006 16:17:08 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4PNH5tx010269; Thu, 25 May 2006 16:17:06 -0700 (PDT) Message-ID: <44763AF1.2030005@sun.com> Date: Thu, 25 May 2006 16:17:05 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.2 (X11/20060427) MIME-Version: 1.0 To: Ali Bahrami CC: Don Cragun , psarc@sac.sfbay.sun.com, Rod.Evans@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior References: <200605252155.k4PLtrPG011766@spartan.SFBay.Sun.COM> <44763770.5090907@sun.com> In-Reply-To: <44763770.5090907@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 664 Ali Bahrami wrote: > I went back to my friend and asked him to do the experiment > on Linux and MacOSX and let me know what they do. The answer > is that they both quietly (no warning) break the hard link > and create the new file with a new inode. Since both of these > systems use the same linker (GNU ld), it isn't surprising > that both do the same thing. In a conversation today with someone working on Linux, they couldn't overwrite a running program because they kept getting ETEXT, so ld on Linux may have had no choice but to do unlink(). -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu May 25 17:54:00 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q0rxAr022045 for ; Thu, 25 May 2006 17:54:00 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k4Q0rwE06022; Thu, 25 May 2006 17:53:58 -0700 (PDT) Message-ID: <447651A6.7030908@sun.com> Date: Thu, 25 May 2006 17:53:58 -0700 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: Jonathan Adams , Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior References: <44760590.6060400@eng.sun.com> <20060525224003.GA124097@eng.sun.com> <1148598785.14234.400.camel@thunk> In-Reply-To: <1148598785.14234.400.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 460 Bill Sommerfeld wrote: > On Thu, 2006-05-25 at 18:40, Jonathan Adams wrote: > >>Actually, Linux does this as well; trying to overwrite a file which has been >>mapped executable somewhere will return ETXTBSY. > > > it's not just linux; I've also verified that you also get ETXTBSY on > netbsd, aix, and hpux. Solaris appears to be the outlier. I believe the "outlier" is any SVR4-based system, not just Solaris. SVR3 and BSD will return ETXTBSY. Scott From sacadmin Thu May 25 18:00:35 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q10ZkI022690 for ; Thu, 25 May 2006 18:00:35 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4Q10QL3420241; Thu, 25 May 2006 18:00:34 -0700 (PDT) Message-Id: <200605260100.k4Q10QL3420241@jurassic.eng.sun.com> Date: Thu, 25 May 2006 15:00:03 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: sommerfeld@sun.com, scott.rotondo@sun.com Cc: jonathan.adams@sun.com, Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali.Bahrami@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 88HnEMApjceOt4nSg62W0w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 464 > I believe the "outlier" is any SVR4-based system, not just Solaris. SVR3 > and BSD will return ETXTBSY. I fear I contributed to this, but unless somebody wants to add a requirement to this case that we must return ETXBSY, I think we should stop. Personally, I was surprized to be educated by this discussion that we don't return ETXBSY and would welcome to see such a case, but I don't think its a requirement for this case. Your mileage may vary. - jek3 From sacadmin Thu May 25 18:07:27 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q17R2f022734 for ; Thu, 25 May 2006 18:07:27 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k4Q17QE06215; Thu, 25 May 2006 18:07:26 -0700 (PDT) Message-ID: <447654CE.6050400@sun.com> Date: Thu, 25 May 2006 18:07:26 -0700 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Kowalski CC: sommerfeld@sun.com, jonathan.adams@sun.com, Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali.Bahrami@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior References: <200605260100.k4Q10QL3420241@jurassic.eng.sun.com> In-Reply-To: <200605260100.k4Q10QL3420241@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 839 Joseph Kowalski wrote: >>I believe the "outlier" is any SVR4-based system, not just Solaris. SVR3 >>and BSD will return ETXTBSY. > > > I fear I contributed to this, but unless somebody wants to add a requirement > to this case that we must return ETXBSY, I think we should stop. > > Personally, I was surprized to be educated by this discussion that we > don't return ETXBSY and would welcome to see such a case, but I don't > think its a requirement for this case. Your mileage may vary. No, adding ETXTBSY certainly shouldn't be a requirement for this case. I think that whole discussion was just a tangent to rationalize why the linker currently behaves the way it does. My point was that Solaris isn't as unusual as it seemed from the rest of the email thread. All SVR4 systems behave the same way, as far as I know. Scott From sacadmin Thu May 25 21:34:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q4YHcD026726 for ; Thu, 25 May 2006 21:34:17 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4Q4YGtx019014 for ; Thu, 25 May 2006 21:34:17 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4Q4YGH1009190 for ; Thu, 25 May 2006 22:34:16 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZU00501V4AUN00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Thu, 25 May 2006 22:34:16 -0600 (MDT) Received: from [198.182.198.2] ([199.45.162.234]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZU008M2VD3GGO4@mail-amer.sun.com>; Thu, 25 May 2006 22:34:16 -0600 (MDT) Date: Thu, 25 May 2006 22:34:24 -0600 From: Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-reply-to: <200605252210.k4PMAI6c247522@jurassic.eng.sun.com> Sender: Ali.Bahrami@Sun.COM To: Joseph Kowalski Cc: psarc@sac.sfbay.sun.com, Rod.Evans@Sun.COM Message-id: <44768550.4040405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200605252210.k4PMAI6c247522@jurassic.eng.sun.com> User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) Status: RO Content-Length: 2044 Joseph Kowalski wrote: > I didn't see a release binding in the specification. > > Given the potential incompatibilities mentioned, I tend to think a > Minor release binding is appropriate. > > Ali? Rod? What is the requested release binding? I believe that minor is the right release binding for this. > Also: > > I believe that a better approach is to change the > default, and provide a command line option to re-enable the old > behavior. > > Is that option part of this case? If so, it needs to be specified. I think that the important thing is to change the default behavior. The need for the command line option to re-enable the old behavior is less obvious to me. Hence, the purposely vague comment about it in the original description. I was hoping to hear some other opinions. The case for the command line option is that it provides an easy workaround that we can offer if someone runs into a problem with it later. The case against: [Rarely Needed] It seems that the number of cases in which it would be useful is very small, limited to times where the following conditions hold: (1) The executable is used from the location where ld writes it, without copying it to an installed location, (2) There are multiple hard links to the executable, and (3) The links are not explicitly refreshed by the makefile when the program is built. [Other Alternatives Exist] Given that the workaround requires the user to edit their makefile, they can achieve the desired effect by using rm to remove the other hard links and ln to relink them to the new file. An option to ld might be more succinct, but it isn't necessary to solve this problem. The one thing that an ld option can do that manually removing and relinking the aliases cannot, is to preserve the specific inode used by the original file. This doesn't seem necessary. I'm happy to go with the consensus opinion on this one. Do you think the option is needed? - Ali From sacadmin Fri May 26 00:22:49 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q7Ml9S011966 for ; Fri, 26 May 2006 00:22:49 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k4Q7MgFP016112; Fri, 26 May 2006 09:22:42 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k4Q7Mg8f015984; Fri, 26 May 2006 09:22:42 +0200 (MEST) Message-Id: <200605260722.k4Q7Mg8f015984@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Jonathan Adams cc: Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-Reply-To: <20060525224003.GA124097@eng.sun.com> References: <44760590.6060400@eng.sun.com> <20060525224003.GA124097@eng.sun.com> Date: Fri, 26 May 2006 09:22:42 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 1259 >On Thu, May 25, 2006 at 12:29:20PM -0700, Rod Evans wrote: >> It turns out that Linux and Mac OS X unlink the output file >> before generating the new one: The inode changed, and the program >> did not crash. Under Solaris, as we would expect, the inode did not >> change and the program did crash. >> >> Both Linux and the Macintosh have large development communities. >> If there was a significant problem with having the linker remove >> the existing file before creating the new one, it would be well known. >> >> My friend also checked how MS Windows handles this case: Windows >> prevents write access to a file that is in use by a running program. >> The linker therefore fails with an error. This is less elegant, >> but does prevent a change to the library (DLL) from corrupting >> a running program. > >Actually, Linux does this as well; trying to overwrite a file which has been >mapped executable somewhere will return ETXTBSY. That is traditional SysV behaviour (I remember the annoying DG/UX behaviour; you weren't even allowed to unlink such files) Which probably works to the point it's an NFS shared executable at which points it all falls apart. We had it in SunOS 4.x or 3.x but removed it with the unified page/file cache. Casper From sacadmin Fri May 26 00:29:45 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4Q7TdYO018931 for ; Fri, 26 May 2006 00:29:39 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k4Q7TXY1018902; Fri, 26 May 2006 09:29:33 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k4Q7TXOn017239; Fri, 26 May 2006 09:29:33 +0200 (MEST) Message-Id: <200605260729.k4Q7TXOn017239@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Scott Rotondo cc: Joseph Kowalski , sommerfeld@sun.com, jonathan.adams@sun.com, Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali.Bahrami@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-Reply-To: <447654CE.6050400@sun.com> References: <200605260100.k4Q10QL3420241@jurassic.eng.sun.com> <447654CE.6050400@sun.com> Date: Fri, 26 May 2006 09:29:33 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 263 >My point was that Solaris isn't as unusual as it seemed from the rest of >the email thread. All SVR4 systems behave the same way, as far as I know. Sun changed this in SunOS 4.0 with the new unified VM system and this carried forward to SVR4/Solaris. Casper From sacadmin Fri May 26 03:15:19 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4QAFHhP025560 for ; Fri, 26 May 2006 03:15:19 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4QAFFtx023577 for ; Fri, 26 May 2006 03:15:16 -0700 (PDT) Received: from d1-emea-01.sun.com ([192.18.2.111]) by gmpea-pix-1.sun.com (8.12.9/8.12.9) with ESMTP id k4QAF94x007338 for ; Fri, 26 May 2006 11:15:09 +0100 (BST) Received: from conversion-daemon.d1-emea-01.sun.com by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZV007019QGME00@d1-emea-01.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 26 May 2006 11:15:09 +0100 (BST) Received: from [129.156.173.21] by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZV007DLB586A00@d1-emea-01.sun.com>; Fri, 26 May 2006 11:15:09 +0100 (BST) Date: Fri, 26 May 2006 11:15:08 +0100 From: Darren J Moffat Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-reply-to: <44760590.6060400@eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Rod.Evans@Sun.COM Cc: psarc@sac.sfbay.sun.com, Ali Bahrami Message-id: <4476D52C.3050602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44760590.6060400@eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 389 Rod Evans wrote: > end user impact. If it is felt that the existing behavior should > be retained, I believe that a better approach is to change the > default, and provide a command line option to re-enable the old > behavior. I don't see it as necessary to have the old data corrupting method available at all. For the record, I've been bitten by this on Solaris. -- Darren J Moffat From sacadmin Fri May 26 10:35:59 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4QHZnu6004580 for ; Fri, 26 May 2006 10:35:59 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k4QHUgGh420620; Fri, 26 May 2006 10:30:47 -0700 (PDT) Message-Id: <200605261730.k4QHUgGh420620@jurassic.eng.sun.com> Date: Fri, 26 May 2006 07:30:44 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: Joseph.Kowalski@eng.sun.com, Ali.Bahrami@sun.com Cc: psarc@sac.sfbay.sun.com, Rod.Evans@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RbFn5RbXF7Ft701Ypv5gBQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 189 > From: Ali Bahrami ... > I'm happy to go with the consensus opinion on this one. Do you > think the option is needed? Like you, I'm on the fence about it. - jek3 From sacadmin Fri May 26 10:39:43 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4QHdhJV004598 for ; Fri, 26 May 2006 10:39:43 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id k4QHctH2013202; Fri, 26 May 2006 10:39:09 -0700 (PDT) Message-Id: <200605261739.k4QHctH2013202@spartan.SFBay.Sun.COM> Date: Fri, 26 May 2006 10:38:55 -0700 (PDT) From: Don Cragun Reply-To: Don Cragun Subject: Re: 2006/353: ld(1) output file removal - change default behavior To: Darren.Moffat@Sun.COM Cc: Rod.Evans@Sun.COM, psarc@sac.sfbay.sun.com, Ali.Bahrami@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kleXAIbvA/cc0C+hmlvTCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1331 >Date: Fri, 26 May 2006 11:15:08 +0100 >From: Darren J Moffat > >Rod Evans wrote: >> end user impact. If it is felt that the existing behavior should >> be retained, I believe that a better approach is to change the >> default, and provide a command line option to re-enable the old >> behavior. > >I don't see it as necessary to have the old data corrupting method >available at all. > >For the record, I've been bitten by this on Solaris. The data corruption is caused by Solaris systems letting you overwrite binaries while they are being executed. As has already been stated this happens only on Solaris systems; Linux, AIX, HP/UX, BSD, and NetBSD all give ETXTBSY instead of corrupting running executables. While breaking links is common on BSD derivatives, it is not the way things work on UNIX-based (AIX, HP/UX, and Solaris) systems. We no longer build in-place (thank goodness). But that doesn't mean that if we change ld to break links we won't cause 3rd party Makefiles to silently stop working correctly. It may also make it harder to port from AIX and HP/UX to Solaris systems. I'm not sure where to draw the line yet between embracing Linux compatibility and maintaining backwards compatibility, but I don't think this is as clear as Darren suggests. - Don > >-- >Darren J Moffat From sacadmin Fri May 26 14:15:31 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4QLFUJm012719 for ; Fri, 26 May 2006 14:15:30 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4QL4Gop620425 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 May 2006 14:04:16 -0700 (PDT) Received: (from tpm@localhost) by jurassic.eng.sun.com (8.13.6+Sun/8.13.5/Submit) id k4QL4Gfn620423; Fri, 26 May 2006 14:04:16 -0700 (PDT) Date: Fri, 26 May 2006 14:04:16 -0700 From: Tim Marsland To: Joseph Kowalski Cc: Ali.Bahrami@sun.com, psarc@sac.sfbay.sun.com, Rod.Evans@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior Message-ID: <20060526210416.GE325284@eng.sun.com> Reply-To: Tim Marsland References: <200605261730.k4QHUgGh420620@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605261730.k4QHUgGh420620@jurassic.eng.sun.com> User-Agent: Mutt/1.4.2.1i Organization: Operating Platforms Group; Sun Microsystems, Inc. Status: RO Content-Length: 348 * Joseph Kowalski [2006-05-26 12:27]: > > > From: Ali Bahrami > ... > > I'm happy to go with the consensus opinion on this one. Do you > > think the option is needed? > > Like you, I'm on the fence about it. You can always add it if and when it becomes necessary. Please, let's move on. tim From sacadmin Fri May 26 17:46:14 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4R0kEQq018601 for ; Fri, 26 May 2006 17:46:14 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4R0kDRF873555 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 May 2006 17:46:13 -0700 (PDT) Received: (from tpm@localhost) by jurassic.eng.sun.com (8.13.6+Sun/8.13.5/Submit) id k4R0kDVW873548; Fri, 26 May 2006 17:46:13 -0700 (PDT) Date: Fri, 26 May 2006 17:46:11 -0700 From: Tim Marsland To: Don Cragun Cc: Darren.Moffat@sun.com, Rod.Evans@sun.com, psarc@sac.sfbay.sun.com, Ali.Bahrami@sun.com Subject: Re: 2006/353: ld(1) output file removal - change default behavior Message-ID: <20060527004610.GF675688@eng.sun.com> Reply-To: Tim Marsland References: <200605261739.k4QHctH2013202@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605261739.k4QHctH2013202@spartan.SFBay.Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: Operating Platforms Group; Sun Microsystems, Inc. Status: RO Content-Length: 306 * Don Cragun [2006-05-26 16:50]: > > I'm not sure where to draw the line yet between embracing Linux > compatibility and maintaining backwards compatibility, but I don't > think this is as clear as Darren suggests. This has minor release binding. Embrace Linux compatibility. tim From sacadmin Tue May 30 17:29:31 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4V0TV0k013586 for ; Tue, 30 May 2006 17:29:31 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k4V0TV27002123 for ; Tue, 30 May 2006 17:29:31 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4V0TUmO013467 for ; Tue, 30 May 2006 18:29:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0300601RODED00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 30 May 2006 18:29:30 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0300CWATD6BN34@mail-amer.sun.com>; Tue, 30 May 2006 18:29:30 -0600 (MDT) Date: Tue, 30 May 2006 18:29:12 -0600 From: Ali Bahrami Subject: Re: 2006/353: ld(1) output file removal - change default behavior In-reply-to: <20060527004610.GF675688@eng.sun.com> Sender: Ali.Bahrami@Sun.COM Cc: Rod.Evans@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <447CE358.9040703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200605261739.k4QHctH2013202@spartan.SFBay.Sun.COM> <20060527004610.GF675688@eng.sun.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 808 This case generated a fair amount of discussion, during which some alternative ideas were discussed. Now that things have quieted down, I would like to head off any potential confusion, by quickly restating what I am (and am not) asking for. I would like to change the behavior of ld(1) regarding file creation, such that existing files are unlinked before the new file is created. The reasons pro and con have been covered in detail, so I won't repeat them here. I am not asking to add a backward compatibility command line option to ld to enable the old behavior. Existing commands (unlink and relink) suffice to achieve the same effect. I do not consider the ETXTBSY response to attempts to modify a mapped file to be part of this case. The scope of this request is limited to ld. Thank you... - Ali From sacadmin Fri Jun 2 09:18:23 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k52GINtx012030 for ; Fri, 2 Jun 2006 09:18:23 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k52GIKEc534763; Fri, 2 Jun 2006 09:18:21 -0700 (PDT) Message-ID: <448064B6.9030306@eng.sun.com> Date: Fri, 02 Jun 2006 09:17:58 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com CC: Ali Bahrami Subject: 2006/353: ld(1) output file removal - change default behavior Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 57 Case has been marked as closed and approved. -- Rod.