Re: latest cygwin patches

[Bob Friesenhahn]

I am not having much luck with this patch under Cygwin.  In my test
build, even though configure says that shared libraries are enabled,
libtool doesn't provide the --shared option to gcc when it builds the
library.

The output from 'libtool --config' is the same as it was for a
successful build on October 14.  I find this to be most peculiar since
the file_magic_cmd option should have changed.  The new code which
should assign it the value 'win32_libid' is quite clearly in the
configure script I am running.  How odd.

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