Re: problem when cross compiling with mingw32ce
On Wed, 21 Jan 2009, Charles Wilson wrote: Vincent Torri wrote: here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not done. That function fails because several functions do not exist on that platform. They are: * getenv, putenv (no environment variable on that OS) * getcwd (no current working directory feature too) * _spawn() The simple way would be to guard them, like it was done with errno: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 Well, not really. The whole purpose of the wrapper (executable, or shell script on unix platforms) is to *set environment variables* appropriately before invoking the actual target executable -- especially $PATH on win32 so that the target executable can find the newly-built and not-yet-installed DLLs that it needs. How wince handles that with no environment variables I have no idea. Maybe if it has no directories at all (and hence, no current working directory), then finding DLLs it not really an issue. I dunno. there are directories, BUT, and that's one of the incredible issues on that OS (there are others...): the directory is not taken into account when looking for a dll. That is, you should avoid having 2 dll with the same name. Otherwise, only one will be always used. Which one, I don't know. But that's a limitation of the OS. Incredible, isn't it ? But most of that can be worked-around using stub functions in the wrapper executable (e.g. wince_setenv() that does nothing and returns success, etc). If it's not a problem for the wrapper, it's fine to me. What can't be worked-around is: _spawn. Somehow there MUST be a way for one executable on wince to start another process. Maybe by invoking CreateProcess() directly -- whereas the normal win32 C runtime provides the _spawn functions as posix-like wrappers around the core Win32API CreateProcess(). CreateProcess can be used, I guess. I'm not a windows programmer. I just ported linux libraries to that terrible OS. I guess there are two choices: (1) do we need the wrapper (executable) to work -- that is, can you invoke the wrapper executable within the target environment (a wince emulator, perhaps?) and if so, do we need it to perform as advertised: set up the proper environment (whatever that means, if anything, given no env vars) and handover control within the simulator environment to the actual executable, in .libs/$myexe? I always do cross-compilation for that OS. I compile on linux. Then I copy the dll / binaries with a SD card. So I don't need it, I think If the answer to either question is no, then perhaps the answer is (2) just to ensure that the wrapper executable compiles without error, even if it is utterly non-functional on wince. That's a little...disturbing, but then, I'm not involved with wince. FYI: the re-organized includes and portability macros part of this patch: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89. http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html was done with an eye toward making these wince workarounds a little easier. I hope. ok Oh, there also might be a third option, but I could be exposing more of my ignorance: maybe wince could just set $needs_wrapper false always, regardless of whether the build is static or dynamically linked? However, what this all boils down to, is somebody is going to have to write the patch, and test it, using mingw32ce. That's going to have to be someone actively involved in using mingw32ce and the wince OS. That ain't me. And given that your original post was 2 months ago, with little response, it looks like very few of the list denizens, other than yourself, have the expertise to directly tackle the problem. I can provide patches, but, as I already said, I'm not involved in libtool dev and I can't write patches if i'm not helped. I have not time to dig into libtool code, as i already have not a lot of time to work on my own todo list. I can compile libtool, run tests, see if my libs compiles flawlessly with libtool. So, according to what I've said, what do you think it is best for that wrapper ? Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not done. That function fails because several functions do not exist on that platform. They are: * getenv, putenv (no environment variable on that OS) * getcwd (no current working directory feature too) * _spawn() The simple way would be to guard them, like it was done with errno: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 Well, not really. The whole purpose of the wrapper (executable, or shell script on unix platforms) is to *set environment variables* appropriately before invoking the actual target executable -- especially $PATH on win32 so that the target executable can find the newly-built and not-yet-installed DLLs that it needs. How wince handles that with no environment variables I have no idea. Maybe if it has no directories at all (and hence, no current working directory), then finding DLLs it not really an issue. I dunno. But most of that can be worked-around using stub functions in the wrapper executable (e.g. wince_setenv() that does nothing and returns success, etc). What can't be worked-around is: _spawn. Somehow there MUST be a way for one executable on wince to start another process. Maybe by invoking CreateProcess() directly -- whereas the normal win32 C runtime provides the _spawn functions as posix-like wrappers around the core Win32API CreateProcess(). I guess there are two choices: (1) do we need the wrapper (executable) to work -- that is, can you invoke the wrapper executable within the target environment (a wince emulator, perhaps?) and if so, do we need it to perform as advertised: set up the proper environment (whatever that means, if anything, given no env vars) and handover control within the simulator environment to the actual executable, in .libs/$myexe? If the answer to either question is no, then perhaps the answer is (2) just to ensure that the wrapper executable compiles without error, even if it is utterly non-functional on wince. That's a little...disturbing, but then, I'm not involved with wince. FYI: the re-organized includes and portability macros part of this patch: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89. http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html was done with an eye toward making these wince workarounds a little easier. I hope. Oh, there also might be a third option, but I could be exposing more of my ignorance: maybe wince could just set $needs_wrapper false always, regardless of whether the build is static or dynamically linked? However, what this all boils down to, is somebody is going to have to write the patch, and test it, using mingw32ce. That's going to have to be someone actively involved in using mingw32ce and the wince OS. That ain't me. And given that your original post was 2 months ago, with little response, it looks like very few of the list denizens, other than yourself, have the expertise to directly tackle the problem. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not done. That function fails because several functions do not exist on that platform. They are: * getenv, putenv (no environment variable on that OS) * getcwd (no current working directory feature too) * _spawn() The simple way would be to guard them, like it was done with errno: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 I don't know if that way would break or not that function Here is the output I have: ./.libs/lt-evil_suite.c: In function 'find_executable': ./.libs/lt-evil_suite.c:620: warning: initialization makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-evil_suite.c:880: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-evil_suite.c:901: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_update_exe_path': ./.libs/lt-evil_suite.c:917: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_update_lib_path': ./.libs/lt-evil_suite.c:938: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast /tmp/cchXYNpc.o: In function `lt_setenv': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:790: undefined reference to `putenv' /tmp/cchXYNpc.o: In function `lt_update_lib_path': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:938: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_update_exe_path': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:917: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_opt_process_env_append': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:901: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_opt_process_env_prepend': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:880: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `find_executable': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:620: undefined reference to `getenv' /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:635: undefined reference to `getcwd' /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:660: undefined reference to `getcwd' /tmp/cchXYNpc.o: In function `main': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:484: undefined reference to `_spawnv' collect2: ld returned 1 exit status arm-mingw32ce-strip: './evil_suite.exe': No such file ../../libtool: line 8551: $func_ltwrapper_scriptname_result: ambiguous redirect thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 7 Dec 2008, Roumen Petrov wrote: the issue is that 'make install' installs no executables at all. Vincent, I can't reproduce with testcase from attached file lt-mingw-nowine-bootstrap.sh.gz (Note my emulator is not in /bin:/usr/bin). sorry, i was not precise enough. So: 1) with the host i586-mingw32msvc, I have the warnings and the installation succeeds 2) with the host mingw32ce, I have the warnings (and some errors I already mentioned) and the installation fails Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hello Vincent, * Vincent Torri wrote on Sun, Dec 07, 2008 at 09:49:56AM CET: On Sun, 7 Dec 2008, Roumen Petrov wrote: the issue is that 'make install' installs no executables at all. Vincent, I can't reproduce with testcase from attached file lt-mingw-nowine-bootstrap.sh.gz (Note my emulator is not in /bin:/usr/bin). sorry, i was not precise enough. So: 1) with the host i586-mingw32msvc, I have the warnings and the installation succeeds 2) with the host mingw32ce, I have the warnings (and some errors I already mentioned) and the installation fails So it's really the failed installation, that is the problem. And the warnings are a nuisance, but no problem. For the second case, the mingw32ce one, please show exactly the failure output; i.e., if 'make install' fails, then copy and paste all of its output. Then, in that output, find the 'libtool --mode=install' command that failed, rerun it manually (in the correct directory), with --debug added as first argument after 'libtool'. Copy and paste all of that output. Then, remove the program/library that was going to be installed, from the build directory, so 'make' rebuilds it. Find that --mode=link command, and execute it with --debug as well, and post that, too. Please pack large outputs with gzip or bzip2. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, On Mon, 8 Dec 2008, Ralf Wildenhues wrote: For the second case, the mingw32ce one, please show exactly the failure output; i.e., if 'make install' fails, then copy and paste all of its output. Then, in that output, find the 'libtool --mode=install' command that failed, rerun it manually (in the correct directory), with --debug added as first argument after 'libtool'. Copy and paste all of that output. Then, remove the program/library that was going to be installed, from the build directory, so 'make' rebuilds it. Find that --mode=link command, and execute it with --debug as well, and post that, too. maybe the issues i have reported in that mail: http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html should be fixed first Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: Hey, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' [SNIP] Note that I also have those warnings when I cross-compile on linux using the host i586-mingw32msvc. So it's not specific to the arm-mingw32ce host Vincent Torri You environment lack emulator, or winepath isn't in PATH. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sat, 6 Dec 2008, Roumen Petrov wrote: You environment lack emulator, or winepath isn't in PATH. WHY do I need an emulator ? I don't care about that. I just want my executables being installed (copied) in the prefix/bin directory I passed when I exec 'make install'. That's all. WHY does libtool does not want to do so ? Is there a way to forbid libtool executing that wrapper ? like -do-not-exec-the-stupid-wrapper Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: On Sat, 6 Dec 2008, Roumen Petrov wrote: You environment lack emulator, or winepath isn't in PATH. WHY do I need an emulator ? I need it to run the project tests including libtool tests. I don't care about that. I just want my executables being installed (copied) in the prefix/bin directory I passed when I exec 'make install'. That's all. WHY does libtool does not want to do so ? Is there a way to forbid libtool executing that wrapper ? like -do-not-exec-the-stupid-wrapper It is just a warning. Is there a real issue ? Vincent Torri Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. Do you still have this problem, and if yes, is there anything wrong *except* for the warnings? I have downloaded the git repo this morning and I still have these warnings. Do you have an explanation, btw ? About problems, I sent 1 mail this morning related to the compilation with mingw32ce. Do you have/does there exist a simulator for mingw32ce, i.e., can you execute WinCE binaries on your host system in the cross compile setup? I have an ipaq and I execute my progs on it. If yes, do they see Windows-style paths (C:\...), and if yes, how do they look like, or do they see unix-style paths? in the Windows CE OS, there is only one disk and one root, a bit like unix fs. It should understand \ and / as separators, but I know for sure that \ is working. so a typical absolute path is: \efl\expedite\data for example Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
I've pushed three patches for cegcc now. This should flush all patches pending from this mail thread. Cheers, Ralf commit 2a06feab95ec4c0e10f265dfb40aff381489d8f3 Author: Vincent Torri [EMAIL PROTECTED] Date: Sun Nov 23 20:30:33 2008 +0100 Fix func_emit_cwrapperexe_src for WinCE: no errno support. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [__MINGW32CE__]: Do not use errno, do not include errno.h and remove calls related to errno when using the mingw32ce compiler. Signed-off-by: Ralf Wildenhues [EMAIL PROTECTED] commit 6ad29eaccf58011e38488875695612728ae52dad Author: Ralf Wildenhues [EMAIL PROTECTED] Date: Sun Nov 23 20:11:38 2008 +0100 No libm in WinCE. * libltdl/m4/libtool.m4 (LT_LIB_M) [cegcc*]: This system has only a dummy libm, ignore. Report by Vincent Torri. Signed-off-by: Ralf Wildenhues [EMAIL PROTECTED] commit 20d15587b268f67aa539d5351027dbe5bdbd183b Author: Ralf Wildenhues [EMAIL PROTECTED] Date: Sun Nov 23 20:10:32 2008 +0100 Fix import library detection for WinCE. * libltdl/config/ltmain.m4sh (func_win32_libid): Work for pe-arm-wince import libraries. * NEWS: Update. Report by Vincent Torri. Signed-off-by: Ralf Wildenhues [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hello Vincent, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. Do you still have this problem, and if yes, is there anything wrong *except* for the warnings? Do you have/does there exist a simulator for mingw32ce, i.e., can you execute WinCE binaries on your host system in the cross compile setup? If yes, do they see Windows-style paths (C:\...), and if yes, how do they look like, or do they see unix-style paths? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
* Vincent Torri wrote on Mon, Oct 27, 2008 at 11:39:58PM CET: /bin/sh ../../libtool --debug --tag=CXX --mode=link arm-mingw32ce-g++ -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil_errno.lo libevil_la-evil_fcntl.lo libevil_la-evil_fnmatch.lo libevil_la-evil_fnmatch_list_of_states.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_stdio.lo libevil_la-evil_string.lo libevil_la-evil_time.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo libevil_la-evil_uuid.lo -lws2 libtool_link.txt 21 I've bzipped the file because it's 1MB large Thanks. As a workaround, remove all -lm entries from dependency_libs in /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib/libstdc++.la aka. /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libstdc++.la then recreate all libraries that use g++ (no need to recompile): cd $top_builddir find . -name \*.la | xargs ./libtool --mode=clean rm -f make Then the reference should be gone. Still thinking about whether we should weed -lm from dependency_libs entries of postdeps. Probably a good thing. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Mon, 27 Oct 2008, Ralf Wildenhues wrote: It would help if you posted, for a library where this fails, the output of the './libtool --mode=link' line with --debug added as first argument; the command is: /bin/sh ../../../libtool --debug --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la libtool_link.txt 21 the result is in the attached file libtool_link.txt also, please post the output of ./libtool --tag=CXX --config the result is in the attached file libtool_config.txt thank you Vincent Torrilibtool: enabling shell trace mode + test 17 -gt 0 + opt=--tag=CC + shift + case $opt in + func_opt_split --tag=CC + func_opt_split_opt=--tag + func_opt_split_arg=CC + set dummy --tag CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + shift + test 18 -gt 0 + opt=--tag + shift + case $opt in + test 17 -eq 0 + preserve_args=' --debug --tag CC' + func_enable_tag CC + tagname=CC + re_begincf='^# ### BEGIN LIBTOOL TAG CONFIG: CC$' + re_endcf='^# ### END LIBTOOL TAG CONFIG: CC$' + sed_extractcf='/^# ### BEGIN LIBTOOL TAG CONFIG: CC$/,/^# ### END LIBTOOL TAG CONFIG: CC$/p' + case $tagname in + case $tagname in + shift + test 16 -gt 0 + opt=--mode=link + shift + case $opt in + func_opt_split --mode=link + func_opt_split_opt=--mode + func_opt_split_arg=link + set dummy --mode link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + shift + test 17 -gt 0 + opt=--mode + shift + case $opt in + test 16 -eq 0 + case $1 in + mode=link + shift + test 15 -gt 0 + opt=arm-mingw32ce-gcc + shift + case $opt in + nonopt=arm-mingw32ce-gcc + break + case $host in + opt_duplicate_compiler_generated_deps=: + : 1 + false + func_check_version_match + test 1.3012 '!=' 1.3012 + test yes '!=' yes + test -z link + eval 'std_shrext=.dll' ++ std_shrext=.dll + test -n '' + generic_help='Try `libtool --help'\'' for more information.' + help='Try `libtool --help --mode=link'\'' for more information.' + false + test link = compile + false + test link = execute + test link = finish + test link = install + test link = link + func_mode_link -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + set -x + case $host in + allow_undefined=yes + libtool_args=arm-mingw32ce-gcc + base_compile='arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la' + compile_command=arm-mingw32ce-gcc + finalize_command=arm-mingw32ce-gcc + compile_rpath= + finalize_rpath= + compile_shlibpath= + finalize_shlibpath= + convenience= + old_convenience= + deplibs= + old_deplibs= + compiler_flags= + linker_flags= + dllsearchpath= ++ pwd + lib_search_path=/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs + inst_prefix_dir= + new_inherited_linker_flags= + avoid_version=no + dlfiles= + dlprefiles= + dlself=no + export_dynamic=no + export_symbols= + export_symbols_regex= + generated= + libobjs= + ltlibs= + module=no + no_install=no + objs= + non_pic_objects= + precious_files_regex= + prefer_static_libs=no + preload=no + prev= + prevarg= + release= + rpath= + xrpath= + perm_rpath= + temp_rpath= + thread_safe=no + vinfo= + vinfo_number=no + weak_libs= + single_module=-Wl,-single_module + func_infer_tag arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + set -x + test -n 'CXX ' + test -z CC + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + test -n '' + test 14 -gt 0 + arg=-g + shift + func_quote_for_eval -g + case $1 in + func_quote_for_eval_unquoted_result=-g + case $func_quote_for_eval_unquoted_result
Re: problem when cross compiling with mingw32ce
Hey, Now I have a problem with libm.a. The ptch you provided is good for all the static lib i currently used, but recently i had to use libm.a (more precisely, it's libtool which adds -lm when c++ code is used). Here are some output: * arm-mingw32ce-objdump -f ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a: _libm_dummy.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x * arm-mingw32ce-nm -f posix -A ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_abbrev N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_info N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_line N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .text t that's all. Should I provide more informations ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hi Vincent, * Vincent Torri wrote on Wed, Oct 22, 2008 at 08:18:28AM CEST: Now I have a problem with libm.a. The ptch you provided is good for all the static lib i currently used, but recently i had to use libm.a (more precisely, it's libtool which adds -lm when c++ code is used). * arm-mingw32ce-nm -f posix -A ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_abbrev N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_info N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_line N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .text t Since this is a dummy library only, the prudent thing for libtool to do would be just to drop instances of -lm. This is already done for some other hosts. I hope to address all the pending Libtool issues soonish. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
[...]
I've never seen those message. Again, I would like to know what is
happening.
No idea where I should look in ltmain.sh to fix those messages ?
Please provide more information, like exactly how you invoked
configure,
post the command that was used that produced the above output, and all
its output, not just the warnings.
configure call:
./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g
-O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
memcpy_glibc_arm.o ../../src/lib/libevil.la
libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o
.libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o
-L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib
../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
Libtool try to convert path from build system to the path from host
system.
So, where and how can I correct that in ltmain.sh
In file included from ./.libs/lt-suite.c:40:
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25:
error: no include path in which to search for errno.h
./.libs/lt-suite.c: In function 'find_executable':
./.libs/lt-suite.c:617: warning: initialization makes pointer from
integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend':
./.libs/lt-suite.c:873: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_append':
./.libs/lt-suite.c:894: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_exe_path':
./.libs/lt-suite.c:910: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_lib_path':
./.libs/lt-suite.c:931: warning: passing argument 1 of
'lt_extend_str' makes pointer from integer without a cast
arm-mingw32ce-strip: './suite.exe': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: there is no environment
variables in that OS, hence no getenv / setenv functions.
If exist emulator for this host os libtool may generate binary wrapper.
If I remember well the libtool contain cases for *mingw* (or
*mingw32*) and may be this is problem - mingw32ce isn't for this
category.
maybe. I don'tt know much about how ltmain.sh works.
Nevertheless, I have a question about all that stuff:
for me, libtool is about libraries (libtool == library tool ?). Anyway,
the doc is saying that libtool is for making life easier when dealing
with libraries. So why is libtool so much involved when dealing with
binaries (it is my case here) ??
The libtool create wrapper script to allow user to run tests programs.
The wrapper script set environment so that test programs to use project
libraries , not system one. For the w32 platform since libtool version
2.{2|4}(?) the wrapper script is replaces by binary executable.
The host triplet *-*-mingw* is used in scripts to detect mingw build
for win32 platform. I mean mingw32msvc as host_os(the
Re: problem when cross compiling with mingw32ce
On Wed, 8 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
[...]
I've never seen those message. Again, I would like to know what is
happening.
No idea where I should look in ltmain.sh to fix those messages ?
Please provide more information, like exactly how you invoked configure,
post the command that was used that produced the above output, and all
its output, not just the warnings.
configure call:
./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
memcpy_glibc_arm.o ../../src/lib/libevil.la
libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o
.libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o
-L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib
../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
Libtool try to convert path from build system to the path from host
system.
So, where and how can I correct that in ltmain.sh
In file included from ./.libs/lt-suite.c:40:
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25:
error: no include path in which to search for errno.h
./.libs/lt-suite.c: In function 'find_executable':
./.libs/lt-suite.c:617: warning: initialization makes pointer from
integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend':
./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_append':
./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_exe_path':
./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_lib_path':
./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
arm-mingw32ce-strip: './suite.exe': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: there is no environment
variables in that OS, hence no getenv / setenv functions.
If exist emulator for this host os libtool may generate binary wrapper.
If I remember well the libtool contain cases for *mingw* (or *mingw32*)
and may be this is problem - mingw32ce isn't for this category.
maybe. I don'tt know much about how ltmain.sh works.
Nevertheless, I have a question about all that stuff:
for me, libtool is about libraries (libtool == library tool ?). Anyway, the
doc is saying that libtool is for making life easier when dealing with
libraries. So why is libtool so much involved when dealing with binaries
(it is my case here) ??
The libtool create wrapper script to allow user to run tests programs.
The wrapper script set environment so that test programs to use project
libraries , not system one. For the w32 platform since libtool version
2.{2|4}(?) the wrapper script is replaces by binary executable.
The host triplet *-*-mingw* is used in scripts to detect mingw build for
win32
Re: problem when cross compiling with mingw32ce
On Wed, 8 Oct 2008, Roumen Petrov wrote: Libtool try to convert path from build system to the path from host system. So, where and how can I correct that in ltmain.sh ? any idea ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. [...] I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? Please provide more information, like exactly how you invoked configure, post the command that was used that produced the above output, and all its output, not just the warnings. configure call: ./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. In file included from ./.libs/lt-suite.c:40: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25: error: no include path in which to search for errno.h ./.libs/lt-suite.c: In function 'find_executable': ./.libs/lt-suite.c:617: warning: initialization makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_exe_path': ./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_lib_path': ./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast arm-mingw32ce-strip: './suite.exe': No such file About the errno problem, I've sent a mail about that. There is also a problem with Windows CE: there is no environment variables in that OS, hence no getenv / setenv functions. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. [...] I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? Please provide more information, like exactly how you invoked configure, post the command that was used that produced the above output, and all its output, not just the warnings. configure call: ./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. Libtool try to convert path from build system to the path from host system. In file included from ./.libs/lt-suite.c:40: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25: error: no include path in which to search for errno.h ./.libs/lt-suite.c: In function 'find_executable': ./.libs/lt-suite.c:617: warning: initialization makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_exe_path': ./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_lib_path': ./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast arm-mingw32ce-strip: './suite.exe': No such file About the errno problem, I've sent a mail about that. There is also a problem with Windows CE: there is no environment variables in that OS, hence no getenv / setenv functions. If exist emulator for this host os libtool may generate binary wrapper. If I remember well the libtool contain cases for *mingw* (or *mingw32*) and may be this is problem - mingw32ce isn't for this category. Vincent Torri Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
* Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST:
If with those settings, things still fail, you should surround the
func_win32_libid code in your libtool script with 'set -x', 'set +x'
and look at the commands called, when 'libtool --mode=link' is run.
Call them manually and inspect their output. The comments in the
function explain what is expected.
I have run manually the commands of func_win32_libid():
$OBJDUMP -f libws2.a | sed -e '10q'
In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a:
duewbt.o: file format pe-arm-wince-little
architecture: armv4, flags 0x0038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x
duewbh.o: file format pe-arm-wince-little
architecture: armv4, flags 0x0039:
But grep is used to check i386, and not arm-wince-little.
Please post the output of
/home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \
/home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a |
sed 100q
and try the patch below.
Now we need someone who knows about wince to tell us whether this is
the right thing to do.
Thanks,
Ralf
2008-10-05 Ralf Wildenhues [EMAIL PROTECTED]
Fix import library detection for WinCE.
* libltdl/config/ltmain.m4sh (func_win32_libid): Work for
pe-arm-wince import libraries.
Report by Vincent Torri.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 1a4a0ff..8300849 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2167,7 +2167,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-arm-wince)'
/dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. Please post the output of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \ /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q Here is the result of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q [beginning] /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: __libws2_a_iname I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$2 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: __libws2_a_iname U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: _head_libws2_a I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: fthunk i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: hname i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: __imp_socket I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: socket T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: __imp_shutdown I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: shutdown T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .idata$4 i
Re: problem when cross compiling with mingw32ce
Hello Vincent, and sorry for the delay, * Vincent Torri wrote on Fri, Oct 03, 2008 at 08:52:54AM CEST: I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a This should only happen if the logic in libtool cannot determine that libws2.a is an import library. The logic for this is quite involved: it uses 'file' to determine the file type, and may use the func_win32_libid shell function in libtool, which itself uses $NM and $OBJDUMP to find out more. So you have to have these set correctly to the cross tools (arm-mingw32ce-objdump or so), for example. Normally, the configure script should get that right (please check that!). If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. [...] I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? Please provide more information, like exactly how you invoked configure, post the command that was used that produced the above output, and all its output, not just the warnings. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, * Vincent Torri wrote on Fri, Oct 03, 2008 at 08:52:54AM CEST: I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a This should only happen if the logic in libtool cannot determine that libws2.a is an import library. The logic for this is quite involved: it uses 'file' to determine the file type, and may use the func_win32_libid shell function in libtool, which itself uses $NM and $OBJDUMP to find out more. So you have to have these set correctly to the cross tools (arm-mingw32ce-objdump or so), for example. Normally, the configure script should get that right (please check that!). I have verified, and the names are correct (even in the libtool script: OBJDUMP=arm-mingw32ce-objdump NM=/home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B ) If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): file -L libws2.a: /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: current ar archive $OBJDUMP -f libws2.a | sed -e '10q' | /bin/grep -E 'file format pe-i386(.*architecture: i386)?' returns nothing. But: $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. I think that the problem is here. But I have no idea on how to fix it. What is even more strange is that there is no problem with the cegcc toolchain. There should be the same problem as the library is also an arm one. Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
* Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST:
If with those settings, things still fail, you should surround the
func_win32_libid code in your libtool script with 'set -x', 'set +x'
and look at the commands called, when 'libtool --mode=link' is run.
Call them manually and inspect their output. The comments in the
function explain what is expected.
I have run manually the commands of func_win32_libid():
$OBJDUMP -f libws2.a | sed -e '10q'
In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a:
duewbt.o: file format pe-arm-wince-little
architecture: armv4, flags 0x0038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x
duewbh.o: file format pe-arm-wince-little
architecture: armv4, flags 0x0039:
But grep is used to check i386, and not arm-wince-little.
Please post the output of
/home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \
/home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a |
sed 100q
and try the patch below.
Now we need someone who knows about wince to tell us whether this is
the right thing to do.
Thanks,
Ralf
2008-10-05 Ralf Wildenhues [EMAIL PROTECTED]
Fix import library detection for WinCE.
* libltdl/config/ltmain.m4sh (func_win32_libid): Work for
pe-arm-wince import libraries.
Report by Vincent Torri.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 1a4a0ff..8300849 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2167,7 +2167,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-arm-wince)'
/dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 |
$SED -n -e '
1,100{
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. Please post the output of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \ /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q Here is the result of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q [beginning] /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: __libws2_a_iname I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$2 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: __libws2_a_iname U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: _head_libws2_a I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: fthunk i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: hname i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: __imp_socket I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: socket T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: __imp_shutdown I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: shutdown T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .idata$4 i
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. about that function, the results mentions 'x86 archive *', same when it's a dll or executable. Is it a problem ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Vincent Torri wrote: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. about that function, the results mentions 'x86 archive *', same when it's a dll or executable. Is it a problem ? more precisely, with mingw32ce: * for DLL, win32_fileres is: $ file -L .libs/libevil-0.dll .libs/libevil-0.dll: MS-DOS executable PE for MS Windows (DLL) 32-bit so it is good enough * for executable, win32_fileres is: $ file -L ../bin/.libs/suite.exe ../bin/.libs/suite.exe: MS-DOS executable PE for MS Windows 32-bit so it is not enough. I think that a case should be added. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. No idea where I should look to fix those messages ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
problem when cross compiling with mingw32ce
Hey, I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
