Re: latest cygwin patches

[Bob Friesenhahn]

Thanks.  I will apply and test these patches.

I notice that Autoconf is planning to introduce shell functions in the
next release, so I assume that shell functions will be ok for use
provided that we put our toe in the water before we jump in.

Bob

On Mon, 28 Oct 2002, Charles Wilson wrote:

> Against CVS-20021028.
>
> This includes the small patch I posted earlier here:
> http://mail.gnu.org/pipermail/libtool-patches/2002-October/002129.html
>
> as well as parts of the patch posted by Marius Vollmer from the Guile
> team here:
> http://mail.gnu.org/pipermail/libtool/2002-October/007115.html
> I've eliminated the parts of the Guile patch that were already in HEAD,
> as well as those portions that are not exercised on the cygwin platform.
>   The rest, I've updated to apply cleanly to current CVS.
>
> In a followup, I will post the "rest" of Marius' patch (e.g. the portion
> that is NOT already in CVS and NOT included in the patch here) for
> others to review.
>
> A note about the changes in this latest cygwin patch.  Shared libs on
> cygwin, pw, mingw, consist of two parts: the DLL itself which contains
> the shared code, and an import library used at link time.
> $file_magic_cmd needs to identify both types as "shared libraries" so
> that relink commands work properly.  Unfortunately, you use objdump to
> identify DLLs, but you need nm to identify archives (and test whether a
> given archive contains import pointers for a DLL)
>
> Since $file_magic_cmd is called with different arguments
> ($file_magic_test_file in one place, \"\$potlib\" in another), we need
> some construct that can take an argument, and then run a sequence of
> shell commands on it.  The only choices I see are a shell function, or
> use a HERE document to generate an ancillary script.
>
> Seems like a shell function is the obvious choice -- but I notice that
> libtool doesn't seem to use them.  Is there a policy against shell
> functions? (I hope not...)
>
> --Chuck
>
> 2002-10-28  Charles Wilson  <address@hidden>
>
>       * libtool.m4 (AC_LIBTOOL_PROG_CC_C_O): use printf,
>       not echo.
>       (AC_DEPLIBS_CHECK_METHOD): use new shell function
>       win32_libid on w32 platforms
>       * ltmain.in: add new section for shell functions.
>       Add win32_libid() shell function.
>       * f77demo/Makefile.am: add -no-undefined flag
>
> 2002-10-04  Rob Browning  <address@hidden>
>
>       * ltdl.c (realloc): Remove custom realloc. (#define
>       rpl_realloc realloc) and comment out later code for
>       custom realloc.  You can't define your own malloc
>       unless you know enough about the malloc in use to
>       be able to tell how big the src ptr is.  The disabled
>       code incorrectly used the *destination* ptr to decide
>       how much to copy.  This sometimes results in out-of-bound
>       accesses which cause segfaults.  This is a quick hack for
>       now; we may want something cleaner later.
>       (tryall_dlopen_module): check to be sure (dirname_len > 0)
>       before testing first character against '/'.
>       (try_dlopen): check for feof(file) in read loop -- otherwise
>       infloop?
>
>
>

======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen