GNU bug report logs - #64723
load-foreign-library has incomplete support for libtool-generated DLLs

Previous Next

Full log

Message #11 received at 64723 <at> debbugs.gnu.org (full text, mbox):

From: Mike Gran <spk121 <at> yahoo.com>
To: "64723 <at> debbugs.gnu.org" <64723 <at> debbugs.gnu.org>
Subject: Re: [PATCH] Improve DLL search strategy for load-foreign-library
Date: Thu, 7 Sep 2023 15:33:55 +0000 (UTC)

> The new non-libltdl foreign library loading algorithm from 3.0.6
> fails to cover common cases regarding how libtool names and installs
> DLL files.  Notably, it fails to recognize when libtool has added the
> major version number into the filename itself, such as libfoo-1.dll
> Also, it does not search in binary directories and the PATH for DLL
> files, where libtool is likely to install DLLs.

Hi All-

This is the first of a dozen patches to make Win32 minimally viable
again. This patch specifically removes a regression introduced in 3.0.6
described above.

If I hear no objection, I'm going to rebase and push
in a week or two.

There are only a couple things in here to which one might find
interesting (aka objectionable).  One is the renaming of the "#:rename-on-cygwin?
option of `load-foreign-library` to "#:host-type-rename?" to
indicate that it handles both msys and cygwin libraries.

The other is the code itself, which could be a lot shorter
if I pulled in other modules. I'm
never comfortable pulling in modules into other modules in
Guile's core itself, for fear of creating spaghetti.  As a consequence,
some of the string handling is comically verbose.

Regards,
Mike Gran

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.