Re: problem when cross compiling with mingw32ce
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) ?? thanks Vincent Torri ___ 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 pl
Libtool versioning for the Git repository
I think that instead of having the more recent version at the end of the version string, it should be in front of the parentheses. So, instead of: libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05) The reason for this is that certain programs(Gnash BZR repository, Subversion SVN repository, etc.) appear to look inside the parentheses for the libtool version, which subsequently causes the autogen script to either fail or use the version of libtool inside the parentheses. Thank you for you time, and I apologize if you are already aware of this. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool versioning for the Git repository
Hi Jeremiah, thanks for the report. I was not aware of this. * Jeremiah Wilson wrote on Wed, Oct 08, 2008 at 08:49:47PM CEST: > I think that instead of having the more recent version at the end of > the version string, it should be in front of the parentheses. > > So, instead of: libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a > > I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05) > > The reason for this is that certain programs(Gnash BZR repository, > Subversion SVN repository, etc.) appear to look inside the parentheses > for the libtool version, which subsequently causes the autogen script > to either fail or use the version of libtool inside the parentheses. Can you post an example failure that is caused by this, including package this happens with, commands called, and output copy'n'pasted? Thanks! Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool versioning for the Git repository
Jeremiah Wilson yahoo.com> writes: [your formatting is messed up in this reply, because you didn't send plain text] > > > I think that instead of having the more recent version at the end of the version string, it should be in front of the parentheses.So, instead of: > libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a > I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05) Unfortunately, this proposal violates GNU Coding Standards: http://www.gnu.org/software/automake/manual/standards.html#g_t_002d_002dversion > The reason for this is that certain programs(Gnash BZR repository, Subversion SVN repository, etc.) appear to look inside the parentheses for the libtool version, I suggest reporting that as a bug to those programs, then. -- Eric Blake ___ http://lists.gnu.org/mailman/listinfo/libtool
Fw: Libtool versioning for the Git repository
- Forwarded Message From: Jeremiah Wilson <[EMAIL PROTECTED]> To: Ralf Wildenhues <[EMAIL PROTECTED]> Sent: Wednesday, October 8, 2008 5:19:50 PM Subject: Re: Libtool versioning for the Git repository Sure! This is the output from my most recent gnash checkout, revision 9974. [EMAIL PROTECTED] ~/BZR/gnash/trunk $ ./autogen.sh Running libtoolize 1.3016 --force --copy --ltdl ... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in `macros'. libtoolize: copying file `macros/argz.m4' libtoolize: copying file `macros/libtool.m4' libtoolize: copying file `macros/ltdl.m4' libtoolize: copying file `macros/ltoptions.m4' libtoolize: copying file `macros/ltsugar.m4' libtoolize: copying file `macros/ltversion.m4' libtoolize: copying file `macros/lt~obsolete.m4' libtoolize: putting libltdl files in `libltdl'. libtoolize: copying file `libltdl/COPYING.LIB' libtoolize: copying file `libltdl/README' libtoolize: copying file `libltdl/argz_.h' libtoolize: copying file `libltdl/argz.c' libtoolize: copying file `libltdl/loaders/dld_link.c' libtoolize: copying file `libltdl/loaders/dlopen.c' libtoolize: copying file `libltdl/loaders/dyld.c' libtoolize: copying file `libltdl/loaders/load_add_on.c' libtoolize: copying file `libltdl/loaders/loadlibrary.c' libtoolize: copying file `libltdl/loaders/shl_load.c' libtoolize: copying file `libltdl/lt__dirent.c' libtoolize: copying file `libltdl/lt__strl.c' libtoolize: copying file `libltdl/libltdl/lt__alloc.h' libtoolize: copying file `libltdl/libltdl/lt__dirent.h' libtoolize: copying file `libltdl/libltdl/lt__glibc.h' libtoolize: copying file `libltdl/libltdl/lt__private.h' libtoolize: copying file `libltdl/libltdl/lt__strl.h' libtoolize: copying file `libltdl/libltdl/lt_dlloader.h' libtoolize: copying file `libltdl/libltdl/lt_error.h' libtoolize: copying file `libltdl/libltdl/lt_system.h' libtoolize: copying file `libltdl/libltdl/slist.h' libtoolize: copying file `libltdl/loaders/preopen.c' libtoolize: copying file `libltdl/lt__alloc.c' libtoolize: copying file `libltdl/lt_dlloader.c' libtoolize: copying file `libltdl/lt_error.c' libtoolize: copying file `libltdl/ltdl.c' libtoolize: copying file `libltdl/ltdl.h' libtoolize: copying file `libltdl/slist.c' libtoolize: creating file `libltdl/Makefile.am' libtoolize: Remember to add `LT_CONFIG_LTDL_DIR([libltdl])' to `configure.ac'. libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. processing . Running aclocal -I macros ... configure.ac:2048: warning: AC_CACHE_VAL(gcc_visibility_bug, ...): suspicious cache-id, must contain _cv_ to be cached .../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... .../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... configure.ac:2005: CHECK_VISIBILITY_GCC_BUG is expanded from... configure.ac:2048: the top level Running autoheader... configure.ac:2048: warning: AC_CACHE_VAL(gcc_visibility_bug, ...): suspicious cache-id, must contain _cv_ to be cached .../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... .../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... configure.ac:2005: CHECK_VISIBILITY_GCC_BUG is expanded from... configure.ac:2048: the top level Running automake --add-missing --copy ... configure.ac:2048: warning: AC_CACHE_VAL(gcc_visibility_bug, ...): suspicious cache-id, must contain _cv_ to be cached .../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... .../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... configure.ac:2005: CHECK_VISIBILITY_GCC_BUG is expanded from... configure.ac:2048: the top level Running autoconf ... configure.ac:2048: warning: AC_CACHE_VAL(gcc_visibility_bug, ...): suspicious cache-id, must contain _cv_ to be cached .../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... .../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... configure.ac:2005: CHECK_VISIBILITY_GCC_BUG is expanded from... configure.ac:2048: the top level [EMAIL PROTECTED] ~/BZR/gnash/trunk $ And this is Subversion from the SVN repository, revision 33565: [EMAIL PROTECTED] ~/SVN/subversion/trunk $ ./autogen.sh buildcheck: checking installation... buildcheck: autoconf version 2.63 (ok) buildcheck: autoheader version 2.63 (ok) buildcheck: libtool version 1.3016 (ok) Copying libtool helper: /usr/share/aclocal/libtool.m4 Creating build-outputs.mk... Creating svn_private_config.h.in... configure.ac:176: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd build/libtool.m4:67: LT_INIT is expanded from... configure.ac:176: the top level configure.ac:176: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd configure.ac:176: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd configure.ac:176: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd Creating configure...
Re: Libtool versioning for the Git repository
All right, I'll try doing that. Thank you. - Original Message From: Eric Blake <[EMAIL PROTECTED]> To: libtool@gnu.org Sent: Wednesday, October 8, 2008 3:32:27 PM Subject: Re: Libtool versioning for the Git repository Jeremiah Wilson yahoo.com> writes: [your formatting is messed up in this reply, because you didn't send plain text] > > > I think that instead of having the more recent version at the end of the version string, it should be in front of the parentheses.So, instead of: > libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a > I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05) Unfortunately, this proposal violates GNU Coding Standards: http://www.gnu.org/software/automake/manual/standards.html#g_t_002d_002dversion > The reason for this is that certain programs(Gnash BZR repository, Subversion SVN repository, etc.) appear to look inside the parentheses for the libtool version, I suggest reporting that as a bug to those programs, then. -- Eric Blake ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
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
