public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "E. Madison Bray" <erik.m.bray@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin's sqlite3 modifies DLL search order
Date: Wed, 29 Jul 2020 13:22:10 +0200	[thread overview]
Message-ID: <CAOTD34ajvxakYC+ymszv5yYkop1efzev5AA0qibrsw3ZF+S5pg@mail.gmail.com> (raw)
In-Reply-To: <CAO1jNwuDQXMT7pzkZxLnZnTa4pUnhmutMByMu_8tnhZ3DX546Q@mail.gmail.com>

(Oops, resending this upon realizing I didn't reply to the list)

On Fri, Jul 17, 2020, 09:34 Jan Nijtmans  wrote:
>
> 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


Hi Jan,

Thanks for commenting on this, and thank you for all the work you've
done maintaining this port!

Yes, the original patch you came up with made sense to me so I was
still a little confused by why the SetDllDirectory stuff was added.
But I'm sure it fixed something at the time.

As long as we're patching it for Cygwin anyways I think your idea to
use dlopen() makes sense. Cygwin's dlopen should do all the path
management properly anyways :)

      reply	other threads:[~2020-07-29 11:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 16:46 E. Madison Bray
2020-07-17  7:33 ` Jan Nijtmans
2020-07-29 11:22   ` E. Madison Bray [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOTD34ajvxakYC+ymszv5yYkop1efzev5AA0qibrsw3ZF+S5pg@mail.gmail.com \
    --to=erik.m.bray@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).