Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: Spot checked some regression tests on cygwin (all passed). Running full regression suite on mingw. OK to push, pending testsuite results? No regressions on msys/mingw from the last time I ran the testsuite on that platform (2.2.5a). IOW: Old testsuite results: 5 of 106 tests failed (18 tests were not run) Please report to bug-libt...@gnu.org FAIL: tests/mdemo-dryrun.test FAIL: tests/demo-exec.test (after demo-shared [*]) FAIL: tests/f77demo-static.test FAIL: tests/f77demo-conf.test FAIL: tests/f77demo-shared.test [*] probably fixed by my other patch New testsuite results: ERROR: 77 tests were run, 6 failed (3 expected failures). 4 tests were skipped. 65: compiling softlinked libltdl FAILED (recursive.at:71) 66: compiling copied libltdl FAILED (recursive.at:91) 67: installable libltdlFAILED (recursive.at:113) 80: Run tests with low max_cmd_len (ctrl-C'ed, so not incl. in tally) OK to push? -- Chuck
[PATCH] [cygwin]: Add cross-compile support to cwrapper
libltdl/config/ltmain.m4sh: (func_cygpath): New function.
(func_wine_to_win32_path): New function. Refactored from...
(func_msys_to_win32): New function supports converting both
paths and pathlists. Refactored from...
(func_to_host_path): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_path.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_path + func_cygpath.
(func_wine_to_win32_pathlist): New function. Refactored from...
(func_to_host_pathlist): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_pathlist.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_pathlist + func_cygpath.
---
Just as unix - mingw cross builds need special support when
creating the cwrapper source code in order for the cwrapper
to work properly under the wine environment, so too do unix -
cygwin cross builds. However, this led to a lot of duplicated
code, so I refactored a bit.
Now, native cygwin and native mingw both still work ok. What I
can't test is whether I've broken the existing unix - mingw
support. Nor can I actually test the new unix - cygwin
support. I *think* it all should work, but I'd like for
somebody to verify that for me. Please?
NOTE: At present, to use the unix - cygwin support, you *MUST*
have the LT_CYGPATH environment variable exported, containing
the *unix* (that is, $build) path to the cygpath.exe you want
to use. In the final patch, I'll prepare some documentation
to that effect, but right now the implementation is probably
in flux pending feedback.
Here's the comment block in ltmain.m4sh describing this:
# [*] The full *nix path to the cygpath program must be
# specified in the LT_CYGPATH environment variable. This
# is because (a) cygpath shouldn't be in $PATH, because it
# usually lives in cygwin's bin/ directory -- along with
# *cygwin* versions of sed, id, cp. If the unix build
# environment had those programs in its $PATH, many bad
# things could happen. (b) especially in cygwin-1.7, multiple
# installations (with separate mount tables in
# CYGROOT-N/etc/fstab) can coexist on the same Win32
# instance. The cygpath.exe for cygwin installation #N in
# CYGROOT-N/bin automatically deduces the appropriate
# ../etc/fstab file. Therefore, it matters which cygpath.exe
# is used. LT_CYGPATH may be replaced or supplemented by an
# LT_INIT-activated configure option in the future.
In re: LT_INIT, I was thinking maybe LT_INIT([win32-dll cygcross])
where the developers of client packages could enable a configure
option, so that end users could do:
configure \
--host=cygwin \
--cygpath=/opt/cygwin-1.7-unstable/bin/cygpath.exe \
other args
Then, func_cygpath would default to using the specified
cygpath, unless LT_CYGPATH overrides. But I haven't worked
out all the details...eventually I need to set up my own
cygwin-under-wine installation. g Anyway, if cygcross did
not appear as an LT_INIT option, then --cygpath wouldn't
be available (but setting LT_CYGPATH would always work).
Comments? Reviews? *Test Results*?
Oh: one other thing. I know using 'win32' is frowned
upon by the FSF/RMS. But I somehow need to distinguish
between cygwin paths, msys paths, and actual win32
paths. I have several functions now named
func_*_to_win32*(). Got any suggestions? mingw is
actually ambiguous, as it could also refer to unix-style
msys paths. mingw_native might be okay, but it's rather
wordy.
==
Chuck
libltdl/config/ltmain.m4sh | 259 +++-
1 files changed, 209 insertions(+), 50 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..7677846 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2557,6 +2557,73 @@ func_emit_wrapper ()
func_emit_wrapper_part2 ${1-no}
}
+# func_wine_to_win32_path arg
+# helper function used by func_to_host_path
+# when $build is neither mingw/msys nor cygwin, and
+# arg must be converted to win32 ($host is mingw or
+# cygwin).
+#
+# result is available in $func_wine_to_win32_path_result
+# result is empty on error (or when arg is empty)
+func_wine_to_win32_path ()
+{
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ func_wine_to_win32_path_result=$1
+ if test -n $1; then
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check the contents of
+# stdout. On the other hand, if the command is not
+# found, the shell will set an exit code of 127 and print
+# *an error message* to stdout. So we must check for both
+# error code of zero AND non-empty stdout, which explains
+# the odd construction:
+
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Hi Chuck, I'm primarily trying to determine what impact this has on my MSVC branch... Den 2009-01-03 02:39 skrev Charles Wilson: *snip* + *cygwin* | *mingw* | *cegcc* ) We should strive to have fewer of these in ltmain.m4sh, not more... + func_warn Using fallback code to determine dllname for $1; consider updating binutils to version 2.20 (2.19.50.20081115), or newer. I fail to find that version of binutils in Cygwin setup, so I guess the fallback code will get exercised. The comments say that gcc adds the dll name in .idata$7, and the fallback code makes use of this fact. How stable is that? What happens if you generate an import library late (if you only have the dll) with something that is not gcc? What if you have an import library created by e.g. MSVC? Looking at a few import libs in the Platform SDK suggests that MSVC uses .idata$6 instead. To me it seems as if the dllname is in the last .idata segment, can't that be scripted for a better fallback? Hmm, looking at the the --identify patch for binutils, it seems that it too simply dumps out .idata$7. That seems to be plain wrong for a whole bunch of import libs out there in the wild. Cheers, Peter
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Peter Rosin wrote: I'm primarily trying to determine what impact this has on my MSVC branch... Den 2009-01-03 02:39 skrev Charles Wilson: *snip* +*cygwin* | *mingw* | *cegcc* ) We should strive to have fewer of these in ltmain.m4sh, not more. Yep. But the problem is, there are really two BIG categories of platforms: those that support ELF-semantics for shared libraries, and those that support PE-DLL semantics. The differences between, say, HP and Linux are in this regard much less significant than the differences between win32 (cygwin, mingw, msvc, even wince) and any *nixoid. And vice verse: cygwin and msvc are much more similar *with regards to the construction of shared libraries* than they are different (even though the implib/static lib formats are non-interchangeable). I'm not sure it would be an improvement, exactly, but we could have a libtool variable $LT_HOST_SUPPORTS_PE_DLL (or a function that takes $host), and replace many of these case $host in *cygwin* | *mingw* | *cegcc* ) ... ;; everything else ) ... ;; esac occurences with 'if host_supports_pe_dll ; then ... ; else ... ; fi' Still ugly, but it means you only have to fix the case $host pattern in one place. + func_warn Using fallback code to determine dllname for $1; consider updating binutils to version 2.20 (2.19.50.20081115), or newer. I fail to find that version of binutils in Cygwin setup, so I guess the fallback code will get exercised. Not exactly. Background: the --identify option is supported only in CVS. There has not yet been an official binutils release containing that code. Furthermore, cygwin's official binutils, while based on a CVS snapshot, is from 20080624. So, no, if you want it you have to compile it yourself. Same for the mingw-provided binutils. But, func_win32_dllname_for_implib is only ever called if we were unable to find the .la file for the implib. Normally, you'd do something like: -dlpreopen foo.la and then, the libfile_$(transliterated implib name) stuff is used, not func_win32_dllname_for_implib. You only use that function if somebody did: -dlpreopen /path/to/foo.dll.a (maybe because they had no .la file, or it was not installed by the system packaging, or whatever). BTW, I'm assuming that func_win32_import_lib_p() works for msvc, because you've got the correct $file_magic_command for your toolchain (whatever correct means)... The comments say that gcc adds the dll name in .idata$7, and the fallback code makes use of this fact. How stable is that? For gcc dll's, very. Hasn't changed in over a decade. pe-ppc (as opposed to pe-i386) uses .idata$6; a dlltool compiled for that toolchain correctly inspects .idata$6. That's why this manual parsing stuff is just a fallback; it'd be better to use a binary tool. But, for msvc, I haven't even thought about trying to parse dumpbin output. Can we (libtool?) provide binary utility programs to go along with msvc to solve some of these issues? Furthermore, can we even assume that binutils progs like objdump and dlltool are available? Or file, for that matter? What happens if you generate an import library late (if you only have the dll) with something that is not gcc? First, I'm assuming that you're not talking about mixing between toolchains (e.g. if $CC is gcc, then the libs were generated by gcc/ld. if $CC is cl, then the libs were generated by cl.exe.) So, you're talking about completely non-gcc-based toolchains AND you're dealing with an import library for which you have no .la file. In that case you're stuck using func_win32_dllname_for_implib. Now, dlltool --identify (if you even HAVE dlltool) doesn't work with MSVC lib files (I just checked). I could see different functions defined for each toolchain, and then a libtool variable $pedll_dllname_for_implib_cmd that points to the correct implementation for your toolchain. (mingw and cygwin and probably cegcc would point to my implementation, whatever it is renamed to). But remember, this is all a corner case: dlpreopen of a shared library, when you don't have an .la file. Otherwise, it ought to just work(tm). What if you have an import library created by e.g. MSVC? Looking at a few import libs in the Platform SDK suggests that MSVC uses .idata$6 instead. Sortof. I see a LOT of .idata$6 entries. Most of them contain symbol names at offset 2, and offset 0,1 contain a little-endian count. But the one that has the DLL name starts at offset 0. How are you supposed to tell that 'MS' is actually the first two characters of a DLL name, and not an indication that symbol 'VCR80.dll' is entry number 0x534d in the symbol list? Unless the first member of the archive is ALWAYS the one that will specify the DLL, and you look in the .idata$LAST of that member. I think it would be better NOT to try to generalize this, and instead go the $LT_pedll_dllname_for_implib_cmd route above. If your msvc port can use objdump, then the following works (and
