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
