git and branches (was: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6))
Maybe a bit more explanation: * Ralf Wildenhues wrote on Sat, Aug 28, 2010 at 07:22:42AM CEST: * Charles Wilson wrote on Sat, Aug 28, 2010 at 07:10:25AM CEST: On 8/27/2010 3:47 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST: However, once I have finished the requested changes above and the rebasing (plus whatever comes of the four open ***QQQ***uestions), I might ask for a 12 hour halt on updates to master so I can run those tests, if that's ok? Why should you need the halt? If there are new pushs in the meantime, you just merge origin/master into your master, and push. Doesn't that mess up the linear history of commits in the upstream master? Well, yes, if you want to call it messing up, that is. From git's perspective, origin/master and master are not the same branch in your repository. Just that most of the time, you use fast-forward or rebase when getting the changes from the former into the latter. With git, branch names are not permanent. branches are merely movable named pointers into some DAG, and when you delete a branch, all you delete is the named pointer. The only bit where branch names become permanent is in the text of the (automatically generated) log entries for merge commits. And these are just for humans to read and digest, so you could even change them after a merge (with commit --amend) if you haven't made that merge public. In that way, whether your master tracks origin/master is only relevant for 'git pull' (namely, which remote branch to merge or rebase against) and 'git status' messages. In the case above, you would of course do fetch and then merge rather than fetch and then rebase (not sure if your pull is configured to rebase rather than merge). FWIW, I've come to never use pull, simply because it confuses me having to think about which way was configured as default (merging or rebasing). The branch concept is in contrast to some other dVCS where branch names somehow permanently describe (possibly overlapping) subgraphs of the full history graph. Cheers, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* Charles Wilson wrote on Sat, Aug 28, 2010 at 08:57:04AM CEST:
This is just an FYI. The take-away here is that I did go ahead and
rename all the functions to
func_convert_{file|path}_X_to_Y
and moved them to just before func_mode_compile. I changed all comments
and function names to use the 'file' (or file name) and 'path'
terminology, instead of the original 'path' and 'pathlist' terminology.
Thanks.
Peter is going to hate me.
Well, since I'm sort-of responsible for the extra work, I volunteer to
rebase Peter's patches if that helps him. Peter, if you accept, please
either make your tree public or send me a git bundle that contains all
the patches.
Cheers,
Ralf
Fix AC_LANG_PROGRAM warnings from git Autoconf.
This patch should fix all warnings emitted by git Autoconf due to the
new AC_LANG_PROGRAM check:
http://lists.gnu.org/archive/html/autoconf-patches/2010-08/msg00080.html
As far as I can see, the first two instances were fairly benign *before*
the Autoconf patch, but the last one exposed a real bug, namely that
Fortran sources were not treated correctly on IRIX with GCC. I have
access to IRIX but no Fortran compiler is installed there, so I can't
really test it. The C++ case is just for consistency (this part of the
macro should not be expanded for that language), and the macro is broken
still for GCJ because AC_LANG does not have a setting for the language.
OK to commit?
Cheers,
Ralf
Fix AC_LANG_PROGRAM warnings from git Autoconf.
* libltdl/m4/libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Fix
underquoted AC_LANG_PROGRAM call.
(LT_PROG_AR): Use AC_LANG_PROGRAM.
(_LT_LINKER_SHLIBS) [irix, GCC]: Use the right source for the
given language.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d7bd57d..1fac524 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1083,7 +1083,7 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
m4_defun([_LT_SYS_MODULE_PATH_AIX],
[m4_require([_LT_DECL_SED])dnl
AC_CACHE_VAL([lt_cv_aix_libpath],
-[AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+[AC_LINK_IFELSE([AC_LANG_PROGRAM],[
lt_aix_libpath_sed='
/Import File Strings/,/^$/ {
/^0/ {
@@ -1324,7 +1324,7 @@ _LT_DECL([], [AR_FLAGS], [1], [Flags to create an
archive])
AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file],
[lt_cv_ar_at_file=no
- AC_COMPILE_IFELSE([[int some_variable = 0;]],
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
[echo conftest.$ac_objext conftest.lst
am_ar_try='$AR $AR_FLAGS libconftest.a @conftest.lst'
AC_TRY_EVAL([am_ar_try])
@@ -5130,9 +5130,18 @@ _LT_EOF
# implicitly export all symbols.
save_LDFLAGS=$LDFLAGS
LDFLAGS=$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo
${wl}-update_registry ${wl}/dev/null
-AC_LINK_IFELSE(int foo(void) {},
+AC_LINK_IFELSE(
+ [AC_LANG_SOURCE(
+[AC_LANG_CASE([C], [[int foo (void) { return 0; }]],
+ [C++], [[int foo (void) { return 0; }]],
+ [Fortran 77], [[
+ subroutine foo
+ end]],
+ [Fortran], [[
+ subroutine foo
+ end]])])], [
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname ${wl}$soname `test -n $verstring
func_echo_all ${wl}-set_version ${wl}$verstring` ${wl}-update_registry
${wl}${output_objdir}/so_locations ${wl}-exports_file ${wl}$export_symbols -o
$lib'
-)
+])
LDFLAGS=$save_LDFLAGS
else
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags -soname $soname `test -n $verstring func_echo_all
-set_version $verstring` -update_registry ${output_objdir}/so_locations -o
$lib'
Re: Fix AC_LANG_PROGRAM warnings from git Autoconf.
Hallo Ralf, On 28 Aug 2010, at 14:10, Ralf Wildenhues wrote: OK to commit? I didn't test, but by inspection everything looks good from here. Fix AC_LANG_PROGRAM warnings from git Autoconf. * libltdl/m4/libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Fix underquoted AC_LANG_PROGRAM call. (LT_PROG_AR): Use AC_LANG_PROGRAM. (_LT_LINKER_SHLIBS) [irix, GCC]: Use the right source for the given language. Add a NEWS item for lack of warnings/fixed latent bug? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
ChangeLog entries for sysroot branch, and merge
OK to apply to the sysroot branch and merge? I'm not sure if I need to ask, so I'll leave a bit of time for comments. I don't actually care too much if after the merge, ChangeLog dates are not all monotonic. That's just life with trying to map a graph linearly. Thanks, Ralf diff --git a/ChangeLog b/ChangeLog index 5f5e23a..9ba1343 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,91 @@ +2010-08-22 Ralf Wildenhues ralf.wildenh...@... + + fix AIX testsuite regression + * libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly + revert v2.2.10-83-gc45a288: Do not absolutize path here, only do + sysroot replacement. + (func_mode_link): Adjust. + +2010-08-22 Charles Wilson libt...@... + + fix --mode=finish + * libltdl/config/ltmain.m4sh (func_mode_finish): Invert then/else + blocks of the if $opt_dry_run conditional. + +2010-08-15 Paolo Bonzini bonz...@... + + improve code for sysroot --mode=finish + * libltdl/config/ltmain.m4sh (func_mode_finish): Change sysroot_regex + and sysroot_cmd delimiter from pipe to slash. Wrap the entire for + loop with if $opt_dry_run...fi and print an explanatory message + for the --dry-run case. + +2010-08-12 Paolo Bonzini bonz...@... + + add libtool --mode=finish mode for sysroot + * doc/libtool.texi (Finish mode): Document behavior when *.la files + are passed. + * libltdl/config/ltmain.m4sh (func_mode_finish): Eliminate sysroot + or `=' signs representing it from files in $libs. + * tests/sysroot.at (SYSROOT_TESTS): Test for presence of sysroot + references before running libtool --mode=finish, and for absence + afterwards. + + reorganize parsing of --mode=finish arguments + * libltdl/config/ltmain.m4sh (func_mode_finish): Split arguments for + directories and *.la files. + + fix sysroot handling for deplibs of preopened libtool libs + * libltdl/config/ltmain.m4sh: Pass $dependency_libs of preopened libtool + through func_resolve_sysroot. + + fix sysroot tests to pass on Fedora 13 + * tests/sysroot.at: Link $prefix/include into the sysroot as well, as + required by newer GCC. + +2010-07-29 Paolo Bonzini bonz...@... + + initial version of the NEWS entry + * NEWS: Document sysroot support. + + add sysroot test + * Makefile.am (TESTSUITE_AT): Add tests/sysroot.at. + * tests/sysroot.at: New. + + emit sysrooted paths when installing .la files + * libltdl/config/ltmain.m4sh (func_replace_sysroot): New. + (func_mode_link): Prepend paths in $libdir with the sysroot. Further, + replace the sysroot with = (using func_replace_sysroot) whenever + such a path is written in a .la file. + + process postdeps to include sysrooted paths + * libltdl/m4/libtool.m4 (_LT_FUNC_STRIPNAME_CNF): New (from Charles Wilson). + (_LT_SYS_HIDDEN_LIBDEPS): Require it. Use func_stripname_cnf to convert + sysroot (-L= and -R=) usage in postdeps. Adjust the code because -L, -R + and -l flags will now always be separated from the rest of the argument. + + handle sysrooted paths when reading dependencies to la files + * libltdl/config/ltmain.m4sh (func_mode_execute, func_mode_install, + func_mode_link): Whenever a .la file occurs in another .la file, + expand the sysroot path in it. + +2010-07-28 Paolo Bonzini bonz...@... + + teach libtool -L= and -R= + * libltdl/config/ltmain.m4sh (func_resolve_sysroot): New. + (func_mode_link): Always pass result of stripping -L and -R to + func_resolve_sysroot before using it. Remove absolute path expansion + when func_resolve_sysroot subsumes it. Expand sysroot in -rpath. + When processing dependent libraries also resolve sysroot paths there. + + add --with-sysroot + * libltdl/m4/libtool.m4 (_LT_HOST_NONCANONICAL, _LT_WITH_SYSROOT): New. + (LT_SETUP): Require _LT_WITH_SYSROOT. + + handle sysroot flags + * libltdl/config/ltmain.m4sh (func_mode_link): Recognize --sysroot + option. + 2010-08-22 Paolo Bonzini bonz...@... Fix sed_make_literal_regex.
Re: ChangeLog entries for sysroot branch, and merge
Hallo Ralf, On 28 Aug 2010, at 15:16, Ralf Wildenhues wrote: OK to apply to the sysroot branch and merge? I'm not sure if I need to ask, so I'll leave a bit of time for comments. I'm assuming that the ChangeLog entries map to the actual changes? How come the ChangeLogs weren't committed at the time of the changes that they log? But sure... we don't want changes in the tree without corresponding ChangeLog entries after all, so please go ahead. I don't actually care too much if after the merge, ChangeLog dates are not all monotonic. That's just life with trying to map a graph linearly. Me neither, although our TIMESTAMP is currently taken from the top date of the ChangeLog, which was designed to help us find the right state of the tree for any bugreports on unreleased versions. Actually, I have a patch series that moves to git-version-gen, but it's fiddly enough that we should wait until after the next release before merging. But, at least that means we don't have to worry about TIMESTAMPS being screwy for too long between the next release and merging that patch series :-) +2010-08-22 Ralf Wildenhues ralf.wildenh...@... + + fix AIX testsuite regression + * libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly + revert v2.2.10-83-gc45a288: Do not absolutize path here, only do + sysroot replacement. + (func_mode_link): Adjust. + +2010-08-22 Charles Wilson libt...@... + + fix --mode=finish + * libltdl/config/ltmain.m4sh (func_mode_finish): Invert then/else + blocks of the if $opt_dry_run conditional. + [[...]] Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: ChangeLog entries for sysroot branch, and merge
Good afternoon Gary, * Gary V. Vaughan wrote on Sat, Aug 28, 2010 at 10:29:01AM CEST: On 28 Aug 2010, at 15:16, Ralf Wildenhues wrote: OK to apply to the sysroot branch and merge? I'm not sure if I need to ask, so I'll leave a bit of time for comments. I'm assuming that the ChangeLog entries map to the actual changes? Erm. (goes back to look again ...) Yes, I would say so. :-) How come the ChangeLogs weren't committed at the time of the changes that they log? Oh, I think that was because at the start of the branch it wasn't clear whether it might see a big rebasing or patch collapsing anyway so authors wanted to not expend possibly extra time. Or something like that. But sure... we don't want changes in the tree without corresponding ChangeLog entries after all, so please go ahead. Done. And merged the sysroot branch to master. Actually, I have a patch series that moves to git-version-gen, but it's fiddly enough that we should wait until after the next release before merging. But, at least that means we don't have to worry about TIMESTAMPS being screwy for too long between the next release and merging that patch series :-) That's great! Thanks, Ralf
Re: Fix AC_LANG_PROGRAM warnings from git Autoconf.
Hi Gary, * Gary V. Vaughan wrote on Sat, Aug 28, 2010 at 09:25:41AM CEST: On 28 Aug 2010, at 14:10, Ralf Wildenhues wrote: OK to commit? I didn't test, but by inspection everything looks good from here. Fix AC_LANG_PROGRAM warnings from git Autoconf. * libltdl/m4/libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Fix underquoted AC_LANG_PROGRAM call. (LT_PROG_AR): Use AC_LANG_PROGRAM. (_LT_LINKER_SHLIBS) [irix, GCC]: Use the right source for the given language. Add a NEWS item for lack of warnings/fixed latent bug? Good idea. I'm squashing in the patch below and pushing the patch, after some testing and inspection on IRIX. Thanks for the quick review! Ralf diff --git a/NEWS b/NEWS index a6e73c2..ba7ce00 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,9 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team: - The `check-interactive' and `check-noninteractive' convenience make targets now also work for the old testsuite. + - Warnings from Autoconf v2.67-36-g1e604ec about incomplete programs +passed to AC_*_IFELSE tests have been fixed. + - On IRIX, the test for -Wl,-exported_symbol now also works with gfortran. New in 2.2.10 2010-06-10: git version 2.2.9a, Libtool team:
Fix archiver @FILE support test
Yay for IRIX ar handing back a useless exit status: configure:6118: checking for archiver @FILE support configure:6135: cc -c -g conftest.c 5 configure:6135: $? = 0 configure:6138: ar cru libconftest.a @conftest.lst ar: Error: @conftest.lst cannot open configure:6141: $? = 0 configure:6152: result: @ This makes the pdemo* tests fail, and I bet the new testsuite too, but I didn't wait for that. I'm pushing the following fix to make the test a bit more reliable, and get ourselves out of the Automake namespace again. Peter, can you check whether ar-lib, lib, and 'link -lib' reliably fail when an @file contains a nonexistent file name? Thanks, Ralf Fix response file test for unreliable exit status of IRIX ar. * libltdl/m4/libtool.m4 (_LT_PROG_AR): IRIX ar will not fail over a command-line argument specifying a nonexistent file (such as `...@file'), so ensure failure with a reponse file containing a nonexistent file. Also, use lt_* variable prefix for temporary variables. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index efb20de..305e2d8 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -1359,10 +1359,15 @@ AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file], [lt_cv_ar_at_file=no AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [echo conftest.$ac_objext conftest.lst - am_ar_try='$AR $AR_FLAGS libconftest.a @conftest.lst' - AC_TRY_EVAL([am_ar_try]) + lt_ar_try='$AR $AR_FLAGS libconftest.a @conftest.lst' + AC_TRY_EVAL([lt_ar_try]) if test $ac_status -eq 0; then -lt_cv_ar_at_file=@ + # Ensure the archiver fails upon bogus file names. + rm -f conftest.$ac_objext libconftest.a + AC_TRY_EVAL([lt_ar_try]) + if test $ac_status -ne 0; then + lt_cv_ar_at_file=@ +fi fi rm -f conftest.* libconftest.a ])
Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.
I'm going to at least try to see how much we can get Libtool in shape for LTO. This one should be easy: * Dave Korn wrote on Wed, Apr 07, 2010 at 01:13:08AM CEST: On 06/04/2010 22:39, Paolo Bonzini wrote: On 04/06/2010 04:01 AM, Charles Wilson wrote: As for whether it would get dropped if you did, I'd imagine that's quite plausible; you might want to add a volatile qualifier. 'static volatile const char * MAGIC = ...' ^^ err...maybe just 'volatile'! Volatile const _does_ make sense to the compiler, believe it or not. :-) Yep, that was no typo on my part, I meant exactly what I said :) Thanks guys. I'm applying the following in your name, if that wasn't exactly what you intended then please speak up. Thanks, Ralf 2010-08-28 Dave Korn dave.korn.cyg...@... Ensure cwrapper magic string is not optimized away. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): Declare MAGIC_EXE as volatile. Report by Charles Wilson. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index a1f3b35..746718a 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3181,7 +3181,7 @@ void lt_dump_script (FILE *f); EOF cat EOF -const char * MAGIC_EXE = $magic_exe; +volatile const char * MAGIC_EXE = $magic_exe; const char * LIB_PATH_VARNAME = $shlibpath_var; EOF
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
Since the question asked in:
* Ralf Wildenhues wrote on Tue, Jun 29, 2010 at 06:49:39AM CEST:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769.
was now answered in
http://thread.gmane.org/gmane.comp.gnu.libtool.general/11039/focus=11045
I feel confident enough for the patch quoted in the first link, and am
pushing it after retesting on GNU/Linux.
Cheers,
Ralf
Uniform const'ness of symlist variable lt_preloaded_symbols.
On some systems, lt_preloaded_symbols may not be declared
const due to relocation issues. C99 requires qualification to
match for compatible declarations, so ensure we declare
const'ness in the same way everywhere; link-time optimization
may otherwise rightfully complain about inconsistencies.
Since ltdl.h may not depend upon config.h, rely on system
defines for choosing const'ness.
* NEWS: Update.
* doc/libtool.texi (Dlpreopening): Document this issue.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms):
[__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
according to system defines. Remove old shell cruft. Use
LT_DLSYM_CONST for lt_${my_prefix}_LTX_preloaded_symbols.
* libltdl/libltdl/lt_system.h (LT_DLSYM_CONST): Likewise,
define LT_DLSYM_CONST according to system defines.
* tests/demo/foo.h (LT_DLSYM_CONST): Likewise.
* tests/pdemo/foo.h (LT_DLSYM_CONST): Likewise.
* tests/demo/dlmain.c (lt_dlsymlist): Use LT_DLSYM_CONST.
* tests/pdemo/longer_file_name_dlmain.c (lt_dlsymlist):
Likewise.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Likewise
for configure test code.
* libltdl/ltdl.c (preloaded_symbols): Use LT_DLSYM_CONST.
* libltdl/ltdl.h (LTDL_SET_PRELOADED_SYMBOLS): Likewise.
[...]
Re: [PATCH 4/4] Add $pic_flag to archive_cmds and archive_expsym_cmds.
[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9770 ] * Ralf Wildenhues wrote on Sun, Apr 04, 2010 at 10:57:04AM CEST: * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) archive_cmds, archive_expsym_cmds [GNU ld, netbsd]: Add $pic_flag if ELF. [GNU ld, solaris]: Likewise. [GNU ld, default case]: Likewise. [!GNU ld, freebsd, dragonfly]: Add $pic_flag. [!GNU ld, GCC, hpux9]: Add $pic_flag. [!GNU ld, GCC, hpux10]: Replace -fPIC with $pic_flag [!GNU ld, GCC, hpux11, !hppa*64]: Replace -fPIC with $pic_flag. [!GNU ld, GCC, irix5, irix6, nonstopux]: Add $pic_flag. [!GNU ld, GCC, osf4, osf5]: Likewise. [!GNU ld, GCC, solaris]: Likewise. (_LT_LANG_CXX_CONFIG) archive_cmds, archive_expsym_cmds [hpux9]: Add $pic_flag if $GXX. [hpux10, hpux11, !hppa*64]: Replace -fPIC with $pic_flag. [irix5, irix6]: Add $pic_flag if $GXX. [osf4, osf5]: Likewise. [solaris]: Add $pic_flag if $GXX and not GCC 2.7. This untested patch cleans up a number of hard-coded -fPIC entries in archive_cmds and archive_expsym_cmds settings, and adds $pic_flag to all that use GCC on ELF systems. However, the patch may also change the link command lines for some non-GCC compilers as well. It needs testing. Since I intend to test all listed systems (hopefully tomorrow), and regard the patch as pretty safe iff it survives that testing (and failure fairly obvious if not), I'm pushing it now, after rebasing it against master (with obvious conflict resolution) and retesting. That leaves only http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9767 plus its requirement wrt. http://thread.gmane.org/gmane.comp.gcc.devel/112719 for LTO support. In _LT_LANG_CXX_CONFIG, hpux10|hpux11, GXX, hppa*64* case, the -fPIC there is probably bogus and can be removed, but that can be another patch (and I haven't tested that either.) No changes on this front. Cheers, Ralf
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
Hi Charles,
* Charles Wilson wrote on Sat, Aug 28, 2010 at 05:13:38PM CEST:
On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
[__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
I don't think __WINDOWS__ is the correct symbol; that is only defined by
Watcom C/C++. I think this should be changed to _WIN32 throughout.
Oops. Like, this?
Would it be sufficient if I tested this on a GNU/Linux - MinGW cross?
Thanks,
Ralf
Fix symlist variable path to use _WIN32 instead of __WINDOWS__.
* libltdl/config/ltmain.m4sh, libltdl/libltdl/lt_system.h,
libltdl/m4/libtool.m4, tests/demo/foo.h, tests/pdemo/foo.h:
Change __WINDOWS__ to _WIN32.
Report by Charles Wilson.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index a7da74f..1aa2e0b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2005,7 +2005,7 @@ extern \C\ {
#endif
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.
*/
-#if defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
+#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
/* DATA imports from DLLs on WIN32 con't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT_DLSYM_CONST
diff --git a/libltdl/libltdl/lt_system.h b/libltdl/libltdl/lt_system.h
index a8481d6..f1545ce 100644
--- a/libltdl/libltdl/lt_system.h
+++ b/libltdl/libltdl/lt_system.h
@@ -77,7 +77,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
#endif
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.
*/
-#if defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
+#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
/* DATA imports from DLLs on WIN32 con't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT_DLSYM_CONST
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7e5022a..89e2e6a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3648,7 +3648,7 @@ _LT_EOF
if $GREP ' nm_test_func$' $nlist /dev/null; then
cat _LT_EOF conftest.$ac_ext
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.
*/
-#if defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
+#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
/* DATA imports from DLLs on WIN32 con't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT@t...@_dlsym_const
diff --git a/tests/demo/foo.h b/tests/demo/foo.h
index 838264e..167096a 100644
--- a/tests/demo/foo.h
+++ b/tests/demo/foo.h
@@ -63,7 +63,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
#endif
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.
*/
-#if defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
+#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
/* DATA imports from DLLs on WIN32 con't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT_DLSYM_CONST
diff --git a/tests/pdemo/foo.h b/tests/pdemo/foo.h
index dd4e86d..a2b2a4a 100644
--- a/tests/pdemo/foo.h
+++ b/tests/pdemo/foo.h
@@ -62,7 +62,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
#endif
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.
*/
-#if defined(__WINDOWS__) || defined(__CYGWIN__) || defined(_WIN32_WCE)
+#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
/* DATA imports from DLLs on WIN32 con't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT_DLSYM_CONST
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
On 8/28/2010 11:31 AM, Ralf Wildenhues wrote: * Charles Wilson wrote on Sat, Aug 28, 2010 at 05:13:38PM CEST: On 8/28/2010 9:21 AM, Ralf Wildenhues wrote: [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST I don't think __WINDOWS__ is the correct symbol; that is only defined by Watcom C/C++. I think this should be changed to _WIN32 throughout. Oops. Like, this? Yes, that looks fine. Would it be sufficient if I tested this on a GNU/Linux - MinGW cross? Yes; the mingw (gcc) compiler defines this symbol. -- Chuck
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
On 8/28/2010 11:43 AM, Vincent Torri wrote: On Sat, 28 Aug 2010, Charles Wilson wrote: On 8/28/2010 9:21 AM, Ralf Wildenhues wrote: [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST I don't think __WINDOWS__ is the correct symbol; that is only defined by Watcom C/C++. I think this should be changed to _WIN32 throughout. _WIN32 is what is defined everywhere, indeed. Wait, Vincent...what are you saying? Do you mean that we don't need to use _WIN32_WCE since (maybe?) _WIN32 is defined also on WINCE? -- Chuck
Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.
* Charles Wilson wrote on Sat, Aug 28, 2010 at 05:31:57PM CEST: On 8/28/2010 11:31 AM, Ralf Wildenhues wrote: * Charles Wilson wrote on Sat, Aug 28, 2010 at 05:13:38PM CEST: On 8/28/2010 9:21 AM, Ralf Wildenhues wrote: [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST I don't think __WINDOWS__ is the correct symbol; that is only defined by Watcom C/C++. I think this should be changed to _WIN32 throughout. Oops. Like, this? Yes, that looks fine. Great, thanks for the quick review, and also Vincent for the help! Would it be sufficient if I tested this on a GNU/Linux - MinGW cross? Yes; the mingw (gcc) compiler defines this symbol. Done, works as well as it did before; pushed. Cheers, Ralf
[PATCH] [cygwin|mingw|cross-compile]: Path conversion support.
* configure.ac: Ensure to_host_file_cmd is available to Makefile. * TODO: Document QoI issue with file name conversion functions. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function sets libtool variable $to_host_file_cmd, and employs cache. (_LT_SETUP): Require it. * tests/testsuite.at: Ensure to_host_file_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * Makefile.am (TESTS_ENVIRONMENT): Ensure to_host_file_cmd is included so that it is passed to (old testsuite) tests. * libltdl/config/general.m4sh: Define $lt_sed_naive_backslashify here. * libltdl/config/ltmain.m4sh ($to_host_file_cmd, $to_host_path_cmd): New variables. (func_cygpath): New function. (func_init_to_host_path_cmd): New function. (func_to_host_path): Renamed to... (func_to_host_file): Refactored to... (now uses $to_host_file_cmd). (func_convert_core_file_wine_to_w32): Here. New function. (func_convert_core_msys_to_w32): Here. New function. (func_convert_file_check): Here. New function. (func_convert_file_noop): Here. New function. (func_convert_file_msys_to_w32): Here. New function. (func_convert_file_cygwin_to_w32): Here. New function. (func_convert_file_nix_to_w32): Here. New function. (func_convert_file_msys_to_cygwin): New function. (func_convert_file_nix_to_cygwin): New function. (func_to_host_pathlist): Renamed to... (func_to_host_path): Refactored to... (now uses $to_host_path_cmd and func_init_to_host_path_cmd). (func_convert_path_check): Here. New function. (func_convert_path_front_back_pathsep): Here. New function. (func_convert_core_path_wine_to_w32): Here. New function. (func_convert_path_noop): Here. New function. (func_convert_path_msys_to_w32): Here. New function. (func_convert_path_cygwin_to_w32): Here. New function. (func_convert_path_nix_to_w32): Here. New function. (func_convert_path_msys_to_cygwin): New function. (func_convert_path_nix_to_cygwin): New function. --- Was [cygwin|mingw] Add cross compile support to cwrapper. This version reflects the results of the review process, and various accommodations to anticipate the queued MSVC patches. Renamed the commit to better reflect its actual contents. Validated on private master just after commit Merge branch 'parallel-tests' d1b98fd5399457b8d83daedb3eb4174d42480240 Results: no regressions (There was an issue with linux-cygwin, but (a) it was my own fault for actually setting LT_CYGPATH knowing that wine + cygwin-1.7 == boom, and (b) we'd already said we have to ignore test results from that environment until wine+cygwin-1.7 is fixed.) Pushed. cygwin-native: == old: All 122 tests passed (2 tests were not run) new: 111 tests behaved as expected. 6 tests were skipped. mingw-native: == old: 2 of 122 tests failed (2 tests were not run) FAIL: tests/mdemo-exec.test FAIL: tests/mdemo2-exec.test new: 109 tests were run, 4 failed (3 expected failures). 8 tests were skipped. 112: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) linux-native: == old: All 106 tests passed new: 102 tests behaved as expected. 15 tests were skipped. linux-mingw cross: === old: 2 of 100 tests failed (6 tests were not run) FAIL: tests/demo-hardcode.test FAIL: tests/depdemo-relink.test new: 89 tests behaved as expected. 28 tests were skipped. linux-cygwin cross: old: 2 of 112 tests failed (12 tests were not run) FAIL: tests/demo-hardcode.test FAIL: tests/depdemo-relink.test new: AWFUL again -- but there's an explanation 88 tests were run, 28 failed (3 expected failures). 29 tests were skipped. I was using my new, sysroot-less linux-cygwin cross compiler, so I expected good results just like the last time I used this compiler. However, UNLIKE last time, I went ahead an set LT_CYGPATH to point to my wine/cygwin cygpath.exe. Well, as has been demonstrated, it coredumps a lot -- and prints lots of gobbledygook. The new testsuite doesn't like gobbledygook. LAST time, I left LT_CYGPATH unset, so libtool simply skipped that part of the test. I'll re-run again, without LT_CYGPATH set, just to be sure... -- Chuck Makefile.am |3 +- TODO| 49 configure.ac|3 + libltdl/config/general.m4sh |5 + libltdl/config/ltmain.m4sh | 628 --- libltdl/m4/libtool.m4 | 50 tests/testsuite.at |5 +- 7 files changed, 577 insertions(+), 166 deletions(-) diff --git a/Makefile.am b/Makefile.am index 2c4a3db..3e424be 100644 --- a/Makefile.am +++ b/Makefile.am @@ -528,7 +528,8 @@ TESTS_ENVIRONMENT = MAKE=$(MAKE) CC=$(CC) CFLAGS=$(CFLAGS) \ CXX=$(CXX) CXXFLAGS=$(CXXFLAGS) CXXCPP=$(CXXCPP) \ F77=$(F77) FFLAGS=$(FFLAGS) \ FC=$(FC) FCFLAGS=$(FCFLAGS) \ - GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) + GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) \ +
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/28/2010 2:57 AM, Charles Wilson wrote: Ok, I've addressed all of the review comments, including the results of the four ***QQQ***estions. Quick-N-Dirty spot testing on native cygwin, native mingw, cygwin-mingw, linux-mingw, linux-cygwin all look good, so I'm about to rebase on my private branch. rebased, tested, merged, and pushed. I renamed the commit to better reflect the actual content (after 7 revisions, it shifted a bit). See [PATCH] [cygwin|mingw|cross-compile]: Path conversion support http://article.gmane.org/gmane.comp.gnu.libtool.patches/10408 -- Chuck
[PATCH] [cygwin] Minor sysroot fixups.
libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
---
Somehow this patch got dropped when the sysroot branch
was merged. Rebased against master...
OK to push?
--
Chuck
libltdl/m4/libtool.m4 |2 +-
tests/sysroot.at |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a7141c5..e03543b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1183,7 +1183,7 @@ lt_sysroot=
case ${with_sysroot} in #(
yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
fi
;; #(
/*)
diff --git a/tests/sysroot.at b/tests/sysroot.at
index c0ac6d1..2a27134 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -34,7 +34,7 @@ AT_CHECK([test -n $gcc_sysroot || exit 77])
# Detect installation prefix for the compiler
prefix=
-for i in crt1.o crt2.o crti.o; do
+for i in crt0.o crt1.o crt2.o crti.o; do
j=`$CC --print-file-name $i 2 /dev/null`
test $? = 0 || continue
case $j in
--
1.7.1
Re: [PATCH] [cygwin] Minor sysroot fixups.
On Sat, 28 Aug 2010, Charles Wilson wrote:
libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
---
Somehow this patch got dropped when the sysroot branch
was merged. Rebased against master...
OK to push?
--
Chuck
libltdl/m4/libtool.m4 |2 +-
tests/sysroot.at |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a7141c5..e03543b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1183,7 +1183,7 @@ lt_sysroot=
case ${with_sysroot} in #(
yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
what is the interest of testing $GCC if you use $CC ?
Vincent Torri
fi
;; #(
/*)
diff --git a/tests/sysroot.at b/tests/sysroot.at
index c0ac6d1..2a27134 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -34,7 +34,7 @@ AT_CHECK([test -n $gcc_sysroot || exit 77])
# Detect installation prefix for the compiler
prefix=
-for i in crt1.o crt2.o crti.o; do
+for i in crt0.o crt1.o crt2.o crti.o; do
j=`$CC --print-file-name $i 2 /dev/null`
test $? = 0 || continue
case $j in
--
1.7.1
Re: [PATCH] [cygwin] Minor sysroot fixups.
On 8/28/2010 6:38 PM, Vincent Torri wrote:
case ${with_sysroot} in #(
yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
what is the interest of testing $GCC if you use $CC ?
$GCC != gcc. It is yes if $CC contains some variant of gcc (like
i686-pc-cygwin-gcc); no otherwise.
So, IF the user specified --with-sysroot, but did not explicitly
indicate where that sysroot is located (e.g. --with-sysroot=/some/path),
THEN
IF $CC is some variant of gcc (e.g. $GCC = yes), THEN
invoke gcc (via $CC) and ask it where the compiled-in sysroot is located.
You don't want to ask the executable yes where its sysroot is.
--
Chuck
Re: [PATCH] [cygwin] Minor sysroot fixups.
* Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST: libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo. tests/sysroot.at: Search also for crt0.o to accommodate cygwin. --- Somehow this patch got dropped when the sysroot branch was merged. Rebased against master... OK to push? Sure. I thought this was approved before anyway. Ideally, you'd commit this to the sysroot branch and merge to master (if you already have it on the latter then: checkout sysroot; cherry-pick master; checkout master; reset --hard HEAD^; merge --log sysroot). You seem to have lost a couple of leading '*' and a ChangeLog entry on the way though. Thanks, Ralf
Re: [PATCH] [cygwin] Minor sysroot fixups.
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST: libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo. tests/sysroot.at: Search also for crt0.o to accommodate cygwin. --- Somehow this patch got dropped when the sysroot branch was merged. Rebased against master... OK to push? Sure. I thought this was approved before anyway. Ideally, you'd commit this to the sysroot branch and merge to master (if you already have it on the latter then: checkout sysroot; cherry-pick master; checkout master; reset --hard HEAD^; merge --log sysroot). You seem to have lost a couple of leading '*' and a ChangeLog entry on the way though. Yep, I know. I always did it this way: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268 in the past. For me, branches were always temporary workspaces, not something you actually *merged* somewhere... -- Chuck
Re: [PATCH] [cygwin] Minor sysroot fixups.
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST: libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo. tests/sysroot.at: Search also for crt0.o to accommodate cygwin. OK to push? Sure. Done. -- Chuck
Re: Fix archiver @FILE support test
Den 2010-08-28 12:24 skrev Ralf Wildenhues: Peter, can you check whether ar-lib, lib, and 'link -lib' reliably fail when an @file contains a nonexistent file name? I haven't run the testsuite, but manual testing shows that the patch should be ok. If the testsuite reveals unexpected problems I'll report back... Cheers, Peter
