[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: latest cygwin patches
Re: latest cygwin patches
Mon, 28 Oct 2002 23:48:04 -0600 (CST)
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
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.
On Mon, 28 Oct 2002, Charles Wilson wrote:
> Against CVS-20021028.
> This includes the small patch I posted earlier here:
> as well as parts of the patch posted by Marius Vollmer from the Guile
> team here:
> 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...)
> 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