DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F1708382E06A
MIME-Version: 1.0
References: <CAOTD34bQzhw6Vv+8Aeh9hZ1oNO8L_H7h1Jne0mkTWCH5vLAH1A@mail.gmail.com>
In-Reply-To: <CAOTD34bQzhw6Vv+8Aeh9hZ1oNO8L_H7h1Jne0mkTWCH5vLAH1A@mail.gmail.com>
Date: Fri, 17 Jul 2020 09:33:52 +0200
Message-ID: <CAO1jNwuDQXMT7pzkZxLnZnTa4pUnhmutMByMu_8tnhZ3DX546Q@mail.gmail.com>
Subject: Re: Cygwin's sqlite3 modifies DLL search order
To: "E. Madison Bray" <erik.m.bray@gmail.com>
From: Jan Nijtmans via Cygwin <cygwin@cygwin.com>
Reply-To: Jan Nijtmans <jan.nijtmans@gmail.com>
Cc: cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces@cygwin.com>

Op do 16 jul. 2020 om 18:48 schreef E. Madison Bray via Cygwin:
>
> Hi all,
>
> After some significant headache I discovered a problem introduced by
> the Cygwin patches for sqlite3.  The effect of this patch is that it
> modifies the DLL search order for all subsequent DLL loads (by
> filename instead of absolute path) in the application.

Thanks for bringing this to my attention. I'm open to suggestions how
to fix this. Yes, this code is already in for a long time. It even contains
an experimental part (the part within #ifdef _WIN32), when I was
trying to make a Win32 build of SQLite work in a Cygwin environment,
oviously a bad idea ......

Thinking about it, I have an idea how to fix it:  Currently extensions
(when using the win32 vfs) are loaded using the Win32 function
LoadLibrary().  Changing that to use dlopen() might already have
the desired effect, then this section can simply be removed
completely.

Thanks!
       Jan Nijtmans
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple