X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Message-ID: <4F336BB0.3020508@gmail.com> Date: Thu, 09 Feb 2012 07:46:08 +0100 From: marco atzeri User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Tcl/tk dll's References: <4F32FC8A DOT 4040602 AT gmail DOT com> <1328753679 DOT 2032 DOT 12 DOT camel AT YAAKOV04> In-Reply-To: <1328753679.2032.12.camel@YAAKOV04> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 2/9/2012 3:14 AM, Yaakov (Cygwin/X) wrote: > On Wed, 2012-02-08 at 23:51 +0100, marco atzeri wrote: >> curiosity, any reason why the tcl/tk dll's are >> not using the cyg prefix ? > > In fact, there is. The point of the "cyg" prefix is to avoid possible > mismatches with MinGW DLLs using the "lib" prefix. In this case, > however, forcing a "cyg" prefix with Tcl's unique build system would be > a lot of work for no gain, since Tcl already has its own way of > distinguishing between the two (tclXY.dll vs. libtclX.Y.dll). Note that > python and R (in Ports) do the same thing for the same reason. > > For the record, I did patch Tcl to also recognize the "cyg" prefix for > those extensions which are built with other build systems. > > > Yaakov > Thanks. I was in fact thinking about the ITP of R starting from your version and I was just wondering if I could live with libR.dll or hack it in cygR.dll. I was waiting the TCL/TK transition for a final check Specially as the dll's are on a dedicate directory, out of the PATH usr/lib/R/lib/libR.dll usr/lib/R/lib/libRblas.dll usr/lib/R/lib/libRlapack.dll staying with libR.dll should be fine in any case. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple