[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool 2.2.2 cross-compile to mingw problems
From: |
Roumen Petrov |
Subject: |
Re: libtool 2.2.2 cross-compile to mingw problems |
Date: |
Mon, 28 Apr 2008 23:06:08 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080329 SeaMonkey/1.1.9 |
Charles Wilson wrote:
Ralf Wildenhues wrote:
Alternatively, for $host=cygwin|mingw, make the executable wrapper
capable of manipulating the environment of the child process, and
directly exec the target executable. Would libtool --exec gdb work in
this case, and allow to debug the actual target exe?
Dunno, but it would be good if it worked. :-)
FWIW, it /does/ indeed work:
Failure:
$ gdb .libs/depdemo.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break main
Breakpoint 1 at 0x401075: file
/usr/src/packages/libtool/git/libtool/tests/depdemo/main.c, line 33.
(gdb) run
Starting program:
/usr/src/packages/libtool/git/build-cwrapper-exec-target/tests/depdemo/.libs/depdemo.exe
[New thread 1052.0xbcc]
gdb: unknown target exception 0xc0000135 at 0x77788fc7
Program exited with code 030000000465.
You can't do that without a process to debug.
(gdb) q
Success:
$ ./libtool --mode=execute gdb ./depdemo.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break main
Breakpoint 1 at 0x401075: file
/usr/src/packages/libtool/git/libtool/tests/depdemo/main.c, line 33.
(gdb) run
Starting program:
/usr/src/packages/libtool/git/build-cwrapper-exec-target/tests/depdemo/.libs/depdemo.exe
[New thread 6100.0x15f8]
[New thread 6100.0x1670]
Breakpoint 1, main (argc=1, argv=0x1222c80) at
/usr/src/packages/libtool/git/libtool/tests/depdemo/main.c:33
33 {
(gdb) q
The program is running. Exit anyway? (y or n) y
$
--
Chuck
Please find attached archive lt-2.2.2-mingw-mlib.tgz .
It contain test case with an application that call functions from other
two project libraries:
- library libfoo1 in subdirectory lib1;
- library libfoo2 in subdirectory lib2;
- program foo in subdirectory appl.
The file lt-mdemo.c.diff from archive is difference to you wrapper script.
To get exit code from real program we has to use spawnvp(P_WAIT,....
In my test environment $WINEPREFIX/dosdevices/m: point to root for mingw
test sources. The sources from archive are located in subdirectory
1/lt-2.2.2-mingw-mlib.
Results from tests:
==========================
(main) argv[0] : ./foo.exe
(main) program_name : foo.exe
(find_executable) : ./foo.exe
(check_executable) : M:\1\lt-2.2.2-mingw-mlib\appl/./foo.exe
(main) found exe (before symlink chase) at :
M:\1\lt-2.2.2-mingw-mlib\appl/./foo.exe
(main) found exe (after symlink chase) at :
M:\1\lt-2.2.2-mingw-mlib\appl/./foo.exe
(main) libtool target name: foo.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_exe_path) modifying 'PATH' by prepending '.libs;'
(lt_setenv) setting 'PATH' to
'.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin'
(lt_update_lib_path) modifying 'PATH' by prepending
'../lib2/.libs;../lib1/.libs;'
(lt_setenv) setting 'PATH' to
'../lib2/.libs;../lib1/.libs;.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin'
(main) newargz[0] : M:\1\lt-2.2.2-mingw-mlib\appl/./.libs/foo.exe
foo1(11)
foo1(22)
foo2(22)
main()
DONE=126
==========================
Although the test succeed with slash(/) in path I think that on host it
will fail due "./" in paths. I think that winapi work with slashes in
path only if they do'nt appear after dot.
Also I note that path to second depended un-installed library is
absolute instead relative:
=======================
/bin/sh ../libtool --tag=CC --mode=link i386-mingw32msvc-gcc -g -O2
-no-undefined -avoid-version -o foo.exe foo.o ../lib2/libfoo2.la
libtool: link: i386-mingw32msvc-gcc -g -O2 -o .libs/foo.exe foo.o
../lib2/.libs/libfoo2.dll.a
/usr/local/...../1/lt-2.2.2-mingw-mlib/lib1/.libs/libfoo1.dll.a
-L/tmp/test/pkg/lt-2.2.2-mingw-mlib/lib
=======================
Also the path to libdir is added but may be this is fine.
In my environment the path to the library installation directory is not
visible under emulation.
Roumen
lt-2.2.2-mingw-mlib.tgz
Description: Binary data
- Re: libtool 2.2.2 cross-compile to mingw problems, (continued)
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/22
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Ralf Wildenhues, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, libtool, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Ralf Wildenhues, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/25
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/28
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/26
- Re: libtool 2.2.2 cross-compile to mingw problems,
Roumen Petrov <=
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/29
- Re: libtool 2.2.2 cross-compile to mingw problems, Simon Josefsson, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Olly Betts, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Simon Josefsson, 2008/04/25