X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Message-ID: <4BAE1A65.9080908@cwilson.fastmail.fm>
Date: Sat, 27 Mar 2010 10:47:01 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: "svn --version" halts in 1.7.2-2
References: <e22ab97b1003252340j350a606ah41b5663802ed098c AT mail DOT gmail DOT com>  <20100326093204 DOT GS7718 AT calimero DOT vinschen DOT de>  <4BACF903 DOT 70304 AT acm DOT org> <20100326210701 DOT GY7718 AT calimero DOT vinschen DOT de> <4BAD401C DOT 8000504 AT acm DOT org> <4BAD5803 DOT 3020509 AT cs DOT umass DOT edu> <4BAD69A4 DOT 6090605 AT acm DOT org> <4BAD6A59 DOT 5060604 AT cs DOT umass DOT edu> <4BAD6D4F DOT 1070109 AT acm DOT org> <4BAD759B DOT 2000204 AT cs DOT umass DOT edu> <4BAD7978 DOT 7060008 AT acm DOT org> <4BAD8540 DOT 4010909 AT cs DOT umass DOT edu>
In-Reply-To: <4BAD8540.4010909@cs.umass.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 3/27/2010 12:10 AM, Eliot Moss wrote:
> On 3/26/2010 11:20 PM, David Rothenberger wrote: 
>> I think the .la files are causing the problems. I believe they come from
>> libsasl2-devel. You said you removed that package, but maybe something
>> went wrong.
> 
> Perhaps ... so I changed the directory name back to sasl2, but
> added .disabled at the end of the .la files' names, and now
> svn -- version continues to work correctly.

Well, this sounds like something in the svn stack is using libltdl's
portable dynamic loading facilities (e.g. libtool's replacement/wrapper
for dlopen()).  That implementation first loads .la files, and uses them
to determine where the .dll/.so is, before using platform specific
functions (LoadLibrary() on native win32, dlopen() on cygwin and most
unices) to load the actual shared library.

Obviously, something is going wrong there.  What happens when the .la
file isn't found, is that libltdl falls back on cygwin's dlopen(), which
simply looks in the normal search path for the DLL -- and that
apparently works.

What's really interesting, is that neither svn.exe nor any of the DLLs
that it is directly linked to actually depend on cygltdl*.dll.  This
tells me that, whichever member of the stack is calling lt_dlopen(), it
was built by linking in a static (local) copy of libltdl.a.  There have
been any number of bugs fixed in that library over the past N years.

I suspect the best solution here is to find out what component:

C:\cygwin-1.7\bin\svn.exe
  C:\cygwin-1.7\bin\cygsvn_client-1-0.dll
    C:\cygwin-1.7\bin\cygsvn_ra-1-0.dll
      C:\cygwin-1.7\bin\cygsvn_ra_local-1-0.dll
        C:\cygwin-1.7\bin\cygsvn_repos-1-0.dll
          C:\cygwin-1.7\bin\cygsvn_fs-1-0.dll
            C:\cygwin-1.7\bin\cygsvn_fs_base-1-0.dll
              C:\cygwin-1.7\bin\cygsvn_delta-1-0.dll
                C:\cygwin-1.7\bin\cygsvn_subr-1-0.dll
                  C:\cygwin-1.7\bin\cyggcc_s-1.dll
                    C:\cygwin-1.7\bin\cygwin1.dll
                      C:\Windows\system32\ADVAPI32.DLL
                        C:\Windows\system32\ntdll.dll
                        C:\Windows\system32\KERNEL32.dll
                        C:\Windows\system32\RPCRT4.dll
                  C:\cygwin-1.7\bin\cygapr-1-0.dll
                  C:\cygwin-1.7\bin\cygaprutil-1-0.dll
                    C:\cygwin-1.7\bin\cygcrypt-0.dll
                    C:\cygwin-1.7\bin\cygexpat-1.dll
                    C:\cygwin-1.7\bin\cygiconv-2.dll
                  C:\cygwin-1.7\bin\cygintl-8.dll
                  C:\cygwin-1.7\bin\cygsqlite3-0.dll
                  C:\cygwin-1.7\bin\cygz.dll
                  C:\Windows\system32\CRYPT32.DLL
                    C:\Windows\system32\msvcrt.dll
                    C:\Windows\system32\USER32.dll
                      C:\Windows\system32\GDI32.dll
                    C:\Windows\system32\MSASN1.dll
                    C:\Windows\system32\USERENV.dll
                      C:\Windows\system32\Secur32.dll
              C:\cygwin-1.7\bin\cygsvn_fs_util-1-0.dll
              C:\cygwin-1.7\bin\cygdb-4.2.dll
            C:\cygwin-1.7\bin\cygsvn_fs_fs-1-0.dll
      C:\cygwin-1.7\bin\cygsvn_ra_neon-1-0.dll
        C:\cygwin-1.7\bin\cygneon-27.dll
          C:\cygwin-1.7\bin\cygcrypto-0.9.8.dll
          C:\cygwin-1.7\bin\cygssl-0.9.8.dll
      C:\cygwin-1.7\bin\cygsvn_ra_serf-1-0.dll
        C:\cygwin-1.7\bin\cygserf-0-0.dll
      C:\cygwin-1.7\bin\cygsvn_ra_svn-1-0.dll
        C:\cygwin-1.7\bin\cygsasl2-2.dll
    C:\cygwin-1.7\bin\cygsvn_wc-1-0.dll
      C:\cygwin-1.7\bin\cygsvn_diff-1-0.dll

is actually opening the .la file (e.g. is compiled against a static
libltdl) and recompile it against a newer version of that library.
Preferably against the "official" shared DLL version cygltdl-N.dll
(which should happen automatically if you libtoolize --force before
rebuiling).

--
Chuck

--
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