subject:"mingw win64 comatibility"

Re: mingw win64 comatibility

2008-11-23 Thread Ralf Wildenhues

* Alon Bar-Lev wrote on Thu, Nov 13, 2008 at 10:45:23AM CET:
 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -2156,7 +2156,7 @@ func_win32_libid ()
  ;;
*ar\ archive*) # could be an import, or static
  if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
 -   $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
 +   $EGREP 'file format pe-i386(.*architecture: i386)?|file format 
 pe-x86-64' /dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 |
   $SED -n -e '
   1,100{

Committed like this.

Cheers, and thanks,
Ralf

2008-11-23  Alon Bar-Lev  ...

Fix func_win32_libid for 64-bit Windows.
* libltdl/config/ltmain.m4sh (func_win32_libid): Accept file
format 'pe-x86-64'.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index c00e404..1c99042 100644
--- a/NEWS
+++ b/NEWS
@@ -12,6 +12,7 @@ New in 2.2.8 2008-??-??: git version 2.2.7a, Libtool team:
   - New libtool command line flag --no-verbose, which disables only
 the extra verbose output messages and has no effect on the
 default informational messages.
+  - Improved support for 64bit Windows (mingw64).
 
 * Bug fixes:
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 28ad40d..e7dcdf2 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2159,6 +2159,7 @@ static const void *lt_preloaded_setup() {
 # Need a lot of goo to handle *both* DLLs and import libs
 # Has to be a shell function in order to 'eat' the argument
 # that is supplied when $file_magic_command is called.
+# Despite the name, also deal with 64 bit binaries.
 func_win32_libid ()
 {
   $opt_debug
@@ -2170,7 +2171,7 @@ func_win32_libid ()
 ;;
   *ar\ archive*) # could be an import, or static
 if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
-   $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
+   $EGREP 'file format (pe-i386(.*architecture: i386)?|pe-x86-64)' 
/dev/null; then
   win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-11-23 Thread Vincent Torri




On Sun, 23 Nov 2008, Ralf Wildenhues wrote:


* Alon Bar-Lev wrote on Thu, Nov 13, 2008 at 10:45:23AM CET:

--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2156,7 +2156,7 @@ func_win32_libid ()
 ;;
   *ar\ archive*) # could be an import, or static
 if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
-   $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
+   $EGREP 'file format pe-i386(.*architecture: i386)?|file format pe-x86-64' 
/dev/null ; then


may I recall that I am waiting a similar patch for Windows CE ?

thank you

Vincent Torri


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-11-23 Thread Alon Bar-Lev

On 11/23/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:

 Committed like this.

  Cheers, and thanks,
  Ralf

Thanks!
Will you backport this to 1.5 branch?

Alon.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-11-23 Thread Alon Bar-Lev

On 11/23/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 No.  The 1.5 branch is dead, and I don't recall anyone that desired
  turning it undead.

  If there is anything that 1.5.x gave you that you don't get from 2.2.x,
  then time to complain is *now* (well, *was* a long time ago, but anyway).
  2.2.x should be more portable, faster, shinier, better.  And 99%
  compatible (except for what changes NEWS mentions).

  Cheers,

It is that I need now to convince all developers in my project to
switch to 2.2 before distro marked it stable.

Thanks!


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-11-16 Thread Ralf Wildenhues

Hello Alon,

* Alon Bar-Lev wrote on Thu, Nov 13, 2008 at 10:45:23AM CET:
 On Wednesday 12 November 2008, Ralf Wildenhues wrote:
  verify that this command fails:
make check-local TESTSUITEFLAGS='-v -d -x -k AC_WITH_LTDL'
  
  and post the output, then find out where exactly the failure happens
  during configure:
cd tests/testsuite.dir/42
./configure --prefix=/nowhere
  
  You may have to look at the output, and/or config.log.
  Do you have the ECHO, RM, environment variables set?
 
 I tried with clean checkout, BTW: make maintainer-clean does not work.

Ah, yes; maintainer-clean only works if you have run 'make check' before
(and no 'make clean' in between), so that all the old test subdirs have
a Makefile.  Same thing with distclean.

 Following is the patch I use... I don't know if the old-m4-iface.at is
 correct. But it solved at least one issue.

Thanks.  The .gitignore issue is obvious, I've pushed that; the
old-m4-iface.m4 change should be obsolete with the pending patch.
I'll deal with the ltmain.m4sh change when we're through with this.

 I also don't know which test should be skipped. Now only the following tests 
 fails:
  32: sys_lib_search_pathtestsuite: WARNING: A 
 failure happened in a test group before any test could be
 testsuite: WARNING: run. This means that test suite is improperly designed.  
 Please
 testsuite: WARNING: report this failure to [EMAIL PROTECTED].
  ok

Thanks; fixed like this, and put you in THANKS.

Cheers,
Ralf

Skip sys_lib_search_path on systems without libz.
* tests/search-path.at (sys_lib_search_path): Autotest needs at
least one AT_CHECK executed in a test group.  So if we haven't
found -lz anywhere, as may happen with cross-compilers, skip the
test.
* THANKS: Update.
Report by Alon Bar-Lev.

diff --git a/tests/search-path.at b/tests/search-path.at
index 2bc56c0..929d2dd 100644
--- a/tests/search-path.at
+++ b/tests/search-path.at
@@ -1,6 +1,6 @@
 # search-path.at -- test sys_lib_search_path_spec -*- Autotest -*-
 #
-#   Copyright (C) 2006 Free Software Foundation, Inc.
+#   Copyright (C) 2006, 2008 Free Software Foundation, Inc.
 #   Written by Ralf Wildenhues, 2006
 #
 #   This file is part of GNU Libtool.
@@ -41,13 +41,20 @@ int main()
 $CC $CPPFLAGS $CFLAGS -c main.c
 eval `$LIBTOOL --config | $EGREP '^(sys_lib_search_path_spec)='`
 eval sys_lib_search_path=\$sys_lib_search_path_spec\
+no_libz=:
 for path in $sys_lib_search_path; do
   if $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT -L$path -lz
   then
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT 
-lz],
  [], [ignore], [ignore])
+no_libz=false
 break
   fi
 done
 
+# If -lz doesn't exist (hello, cross compiler!), we need a dummy test.
+if $no_libz; then
+  AT_CHECK([exit 77])
+fi
+
 AT_CLEANUP


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-11-05 Thread Alon Bar-Lev

Ralf?
This is the last task... OpenSSL, mingw64 and other projects already
accepted all patches to make this environment work.
libtool is the last one.

Alon.

On 10/27/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
 Hello Raf,

  Any news?
  Can I do anything to help?


  Alon.


  On 10/21/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
   Hello,
  
Used git head.
Before I use cross compile, I tried to see if all tests pass on local 
 compiler.
  
My system (gentoo) has the following versions:
sys-devel/m4-1.4.11
sys-devel/autoconf-2.61-r2
sys-devel/automake-1.10.1-r1
sys-devel/libtool-1.5.26
  
Attached is the native log and win64 log (after the fix).
  
You should add *.exe to ignore... :)
  
Thanks!
  
   Alon.
  
  
On 10/21/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 Hello Alon,

  Thanks for the report.

  * Alon Bar-Lev wrote on Mon, Oct 20, 2008 at 03:19:50PM CEST:

 
   The func_win32_libid is not working correctly when win64 objects are 
 found.
   The file format is file format pe-x86-64.
  
   The attached patches for 1.5.26, 2.2.6a for the resulting libtool 
 script.
   I did not know where to put this in libtool source, can you please
   look into it?


 It needs to be done in libltdl/config/ltmain.m4sh.


   --- libtool.2.2.6a2008-10-20 14:21:57.0 +0200
   +++ libtool   2008-10-20 14:21:42.0 +0200
   @@ -3073,7 +3073,7 @@ func_win32_libid ()
;;
  *ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
   -   $EGREP 'file format pe-i386(.*architecture: i386)?' 
 /dev/null ; then
   +   $EGREP 'file format pe-i386(.*architecture: i386)?|file 
 format pe-x86-64?' /dev/null ; then


 The trailing ? after pe-x86-64 is wrong, pleasse drop it.


  win32_nmres=`eval $NM -f posix -A $1 |
 $SED -n -e '
 1,100{


 Can you be bothered to check out the Libtool git tree or a nightly
  snapshot (see homepage for links) and, with above change, build it
  and run the testsuite on win64, please?  We'd be interested in any
  failures of
   make -k check

  (add VERBOSE=yes for verbose output of the old testsuite, and send
  tests/testsuite.log for failure of the new one).

  You'd need Autoconf for rebuilding Libtool, and also Automake for
  running all tests.

  Thanks!

 Ralf

  
  



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

2008-10-27 Thread Alon Bar-Lev

Hello Raf,

Any news?
Can I do anything to help?

Alon.

On 10/21/08, Alon Bar-Lev [EMAIL PROTECTED] wrote:
 Hello,

  Used git head.
  Before I use cross compile, I tried to see if all tests pass on local 
 compiler.

  My system (gentoo) has the following versions:
  sys-devel/m4-1.4.11
  sys-devel/autoconf-2.61-r2
  sys-devel/automake-1.10.1-r1
  sys-devel/libtool-1.5.26

  Attached is the native log and win64 log (after the fix).

  You should add *.exe to ignore... :)

  Thanks!

 Alon.


  On 10/21/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
   Hello Alon,
  
Thanks for the report.
  
* Alon Bar-Lev wrote on Mon, Oct 20, 2008 at 03:19:50PM CEST:
  
   
 The func_win32_libid is not working correctly when win64 objects are 
 found.
 The file format is file format pe-x86-64.

 The attached patches for 1.5.26, 2.2.6a for the resulting libtool 
 script.
 I did not know where to put this in libtool source, can you please
 look into it?
  
  
   It needs to be done in libltdl/config/ltmain.m4sh.
  
  
 --- libtool.2.2.6a2008-10-20 14:21:57.0 +0200
 +++ libtool   2008-10-20 14:21:42.0 +0200
 @@ -3073,7 +3073,7 @@ func_win32_libid ()
  ;;
*ar\ archive*) # could be an import, or static
  if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null |
 -   $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null 
 ; then
 +   $EGREP 'file format pe-i386(.*architecture: i386)?|file format 
 pe-x86-64?' /dev/null ; then
  
  
   The trailing ? after pe-x86-64 is wrong, pleasse drop it.
  
  
win32_nmres=`eval $NM -f posix -A $1 |
   $SED -n -e '
   1,100{
  
  
   Can you be bothered to check out the Libtool git tree or a nightly
snapshot (see homepage for links) and, with above change, build it
and run the testsuite on win64, please?  We'd be interested in any
failures of
 make -k check
  
(add VERBOSE=yes for verbose output of the old testsuite, and send
tests/testsuite.log for failure of the new one).
  
You'd need Autoconf for rebuilding Libtool, and also Automake for
running all tests.
  
Thanks!
  
   Ralf
  




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw win64 comatibility

Re: mingw win64 comatibility

Re: mingw win64 comatibility

Re: mingw win64 comatibility

Re: mingw win64 comatibility

Re: mingw win64 comatibility

Re: mingw win64 comatibility

7 matches

Site Navigation

Mail list logo

Footer information