Re: cross compilation to w32

2008-03-09 Thread Roumen Petrov

Roumen Petrov wrote:

Ralf Wildenhues wrote:

* Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET:

[SNIP]


Hmm during the tests tests/demo/helldl.exe is compiled many times.
First is ok, later don't produce output(exit code 127) and 
tests/demo/.libs/helldl.exe crash.


Roumen


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: cross compilation to w32

2008-03-08 Thread Gary V. Vaughan

Hallo Ralf,

On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote:

we have a couple of problems wrt. cross compilation to w32 in 2.2.
When I cross-compile from GNU/Linux to MinGW using Debian's mingw32
packages (i586-mingw32msvc-gcc etc.), then link mode already
requires executing a host program; for example:

cd tests/demo
/bin/sh -x ./libtool --tag=CC   --mode=link i586-mingw32msvc-gcc  -g  
-O2 -export-dynamic -dlpreopen libhello.la -L/usr/i586-mingw32msvc/ 
lib -o helldl.exe dlmain.o


[...]
+ ./helldl.exe --lt-dump-script
Wine exited with a successful status
+ exit 0

This means that building will fail on systems without a simulator.

The other problem I've stumbled over so far is this one: the
*_ltshwrapper file has DOS line endings.  This causes 'make install'
to fail, because the native /bin/sh cannot parse the script:

 /bin/sh ./libtool --mode=install /usr/bin/install -c 'hell.exe' '/ 
home/ralf/download/cvs/libtool/HEAD/build-mingw/_inst/bin/hell.exe'

: command not foundapper: line 2:
: command not foundapper: line 11:
: command not foundapper: line 16:
./.libs/hell_ltshwrapper: line 26: syntax error near unexpected  
token `newline'
./.libs/hell_ltshwrapper: line 26: `  case `(set -o) 2/dev/null` in  
*posix*) se' -o posix;; esac
libtool: install: invalid libtool wrapper script `./.libs/ 
hell_ltshwrapper'


Does anybody see easy ways out?



Shouldn't the cwrapper be compiled with the host compiler?  It looks as
though it isn't at the moment...

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_






PGP.sig
Description: This is a digitally signed message part
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: cross compilation to w32

2008-03-08 Thread Ralf Wildenhues
Hi Gary,

* Gary V. Vaughan wrote on Sat, Mar 08, 2008 at 05:39:38PM CET:
 On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote:
 we have a couple of problems wrt. cross compilation to w32 in 2.2.
 When I cross-compile from GNU/Linux to MinGW using Debian's mingw32
 packages (i586-mingw32msvc-gcc etc.), then link mode already
 requires executing a host program; for example:
[...]
 This means that building will fail on systems without a simulator.
[...]
 Does anybody see easy ways out?

 Shouldn't the cwrapper be compiled with the host compiler?  It looks as
 though it isn't at the moment...

It is.  With our new scheme in 2.2 however, the wrapper is also
*executed* already at link time, rather than only at run time.
That is the gist of the first problem for users without a simulator.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: cross compilation to w32

2008-03-08 Thread Charles Wilson

Ralf Wildenhues wrote:


Does anybody see easy ways out?


Well, for the second problem there are two solutions. (1) always ensure 
that the script is emitted with unix line endings, or (2) specify 
$TARGETSHELL=/emulation/environment/sh when cross-compiling.


Obviously, (2) is the easiest, because getting rid of the requirement 
for an emulator is going to take a bit more work.  (1) is slightly more 
difficult, and doesn't solve the emulator problem -- but at least 
doesn't compound the problem.


For cygwin/msys, (1) means for --lt-dump-script, using setmode() on 
stdout here:


  if (strcmp (argv[i], dumpscript_opt) == 0)
{
 setmode here? 
  printf (%s, script_text);
  return 0;
}

and for normal operation, changing this:

  /* note: do NOT use wt here! -- defer to underlying
   * mount type on cygwin
   */
  if ((shwrapper = fopen (newargz[1], w)) == 0)

to

  /* always use binary mode */
  if ((shwrapper = fopen (newargz[1], wb)) == 0)

Both cygwin and msys's shell will work with unix line endings, 
regardless of cygwin's underlying mount type, etc.



Of course, both of these suggestions (setmode, and using wb) are 
win32-isms, and will only work as written above if we continue to use 
$LTCC as described below:


# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the real binary.
# Since the real binary is built for $host, then this
# wrapper might as well be built for $host, too.
$opt_dry_run || {
  $LTCC $LTCFLAGS -o $cwrapper $cwrappersource
  $STRIP $cwrapper
}

As Ralf has pointed out, the comment above is not currently correct: we 
currently do need to execute the binary wrapper, even if we don't want 
to run the actual target, because the next step is:


# Now, create the wrapper script for func_source use:
$opt_dry_run || {
  $cwrapper --lt-dump-script  
$func_ltwrapper_scriptname_result

}

=== emulator problem 

(1) guard win32-isms in the binary wrapper source code against non-win32 
build environment

(2) use build environment compiler to compile binary wrapper
(3) this means that you CAN'T use an emulator environment at all, if you 
wanted to run the tests -- because the emulator won't be able to execute 
the binary wrappers


Okay. So that's not really a solution.  What we really need is the 
capability to extract (or emit) the shell wrapper during the link phase 
(or earlier), just so libtool can source it back in and parse the contents.


One important note: for win32 targets, there are TWO different copies 
(with different names) of the shell wrapper. One is created during the 
link phase, and is only present so that it can be sourced back in by 
libtool and parsed.  The other (ephemeral) copy is (re)created each time 
the binary wrapper is executed, and the binary wrapper then execs it.


Our problem is the first one.  How about, when cross-compiling for win32 
targets, keep most things as they are (with perhaps some of the 
line-ending changes described above). However, just change this bit:


# Now, create the wrapper script for func_source use:
func_ltwrapper_scriptname $cwrapper
$RM $func_ltwrapper_scriptname_result
trap $RM $func_ltwrapper_scriptname_result; exit 
$EXIT_FAILURE 1 2 15

$opt_dry_run || {
  $cwrapper --lt-dump-script  
$func_ltwrapper_scriptname_result

}

so that when cross-compiling for win32, we use the normal method of 
creating $func_ltwrapper_scriptname_result -- direct creation from libtool:


func_emit_wrapper no  $func_ltwrapper_scriptname_result

Here's a possible (completely untested) patch.

--
Chuck

Index: ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.99
diff -u -r1.99 ltmain.m4sh
--- ltmain.m4sh 5 Mar 2008 20:14:43 -   1.99
+++ ltmain.m4sh 8 Mar 2008 18:54:53 -
@@ -2513,6 +2513,7 @@
 #ifdef _MSC_VER
 # include direct.h
 # include process.h
+# include io.h
 #else
 # include unistd.h
 # include stdint.h
@@ -2523,6 +2524,7 @@
 #include string.h
 #include ctype.h
 #include errno.h
+#include fcntl.h
 #include sys/stat.h
 
 #if defined(PATH_MAX)
@@ -2556,6 +2558,7 @@
 #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
   defined (__OS2__)
 # define HAVE_DOS_BASED_FILE_SYSTEM
+# define FOPEN_WB wb
 # ifndef DIR_SEPARATOR_2
 #  define DIR_SEPARATOR_2 '\\'
 # endif
@@ -2577,6 +2580,17 @@
 # define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
 #endif /* PATH_SEPARATOR_2 */
 
+#ifdef __CYGWIN__
+# define FOPEN_WB wb
+#endif
+
+#ifndef FOPEN_WB
+# define FOPEN_WB w
+#endif
+#ifndef _O_BINARY
+#