From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-08 12:48:09
|
[Sorry if this message is duplicated -- I just noticed I used the wrong e-mail address when sending the previous copy] Hi, I am quite sure someone must have explained this somewhere, but really I cannot find any documentation shown how to do the following. I have a program that compiles and runs in many different unix environments by means of "configure". The program in question is a Lisp interpreter called ECL (http://ecl.sf.net). I gave MSYS an attempt and it works almost fine, except when my program tries to locate files. My feeling is that MSYS forces, during configuration process, all pathnames from windows format to what I would call "MSYS-format". However, when I build my program, the open(), fopen(), and other functions do not understand this convention. To give an idea of what goes on, in the bootstrap process ECL needs to load a bunch of files that it locates using @srcdir@. Even though I initially set to a valid windows path, d:/msys/1.0/home/user1/ecl, in my Makefile.in it appears as /home/user1/ecl, and when ECL tries to fopen("@srcdir@/boot.lisp"), it fails. Is there a standard tool which converts MSYS paths into windows ones? What is the name of this tool? Or do I have to link my program against the MSYS DLL so that fopen() learns about MSYS paths? If so, how do I do it and how should I distribute the resulting executable? Best regards Juanjo |
From: Earnie B. <ear...@ya...> - 2003-07-08 13:14:22
|
Juan Jose Garcia-Ripoll wrote: > [Sorry if this message is duplicated -- I just noticed I used the wrong e-mail > address when sending the previous copy] > > Hi, > > I am quite sure someone must have explained this somewhere, but really I > cannot find any documentation shown how to do the following. > > I have a program that compiles and runs in many different unix environments > by means of "configure". The program in question is a Lisp interpreter > called ECL (http://ecl.sf.net). > > I gave MSYS an attempt and it works almost fine, except when my program tries > to locate files. My feeling is that MSYS forces, during configuration > process, all pathnames from windows format to what I would call > "MSYS-format". However, when I build my program, the open(), fopen(), and > other functions do not understand this convention. > Your problem has a focus point on my round tuit list. I supply msys dll dependent versions of such things a perl, guile, etc for this very reason. The focus point is set to with or beyond version MSYS-2.0.0 I'm afraid. > To give an idea of what goes on, in the bootstrap process ECL needs to load a > bunch of files that it locates using @srcdir@. Even though I initially set to > a valid windows path, d:/msys/1.0/home/user1/ecl, in my Makefile.in it > appears as /home/user1/ecl, and when ECL tries to > fopen("@srcdir@/boot.lisp"), it fails. > You say that you explicitly use an absolute win32 path and MSYS is converting it to posix? Which version of MSYS? Can you provide a small test case? > Is there a standard tool which converts MSYS paths into windows ones? What is > the name of this tool? Or do I have to link my program against the MSYS DLL > so that fopen() learns about MSYS paths? If so, how do I do it and how should > I distribute the resulting executable? > Well, that is what MSYS is about, convert to win32 paths where appropriate, so no external tool should be needed. I want to work with you on getting this resolved. A possible work around would be to use a macro instead for you boot.lisp path. So that you have ``fopen(BOOT_LISP)'' and have the a -DBOOT_LISP="$srcdir/boot.lisp" in the Makefile. Notice the use of a variable instead of the configure replacement of @srcdir@. Earnie. |
From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-08 13:57:52
|
On Tuesday 08 July 2003 15:15, Earnie Boyd wrote: > > To give an idea of what goes on, in the bootstrap process ECL needs to > > load a bunch of files that it locates using @srcdir@. Even though I > > initially set to a valid windows path, d:/msys/1.0/home/user1/ecl, in my > > Makefile.in it appears as /home/user1/ecl, and when ECL tries to > > fopen("@srcdir@/boot.lisp"), it fails. > > You say that you explicitly use an absolute win32 path and MSYS is > converting it to posix? Which version of MSYS? Can you provide a small > test case? I use MSYS 1.0.8. The thing is as follows: I have a script which uses "pwd -W" (I figured this out) to get the win32 path of the directory in which the source code of ECL resides. To keep things clean, this script makes a directory "build_mingw" and once inside there it invokes the true configuration file, with something like d:/msys/1.0/home/user1/src/configure \ --srcdir=d:/msys/1.0/home/user1/ecl \ --prefix=d:/mingw/ecl [... more options ...] Here, d:/msys/1.0/home/user1/ecl is simply the output of "pwd -W". The role of the configuration script is to figure out the capabilities of the system (i.e. which functions are missing, size of integer numbers, etc). Plus, the same script creates a lot of Makefile-s, config.status, config.h, etc in the "build_mingw" directory. Many of these filese depend on the value of "srcdir", but somehow this value gets trashed and becomes /home/user1/ecl. > A possible work around would be to use a macro instead for you boot.lisp > path. So that you have ``fopen(BOOT_LISP)'' and have the a > -DBOOT_LISP="$srcdir/boot.lisp" in the Makefile. Notice the use of a > variable instead of the configure replacement of @srcdir@. The problem is that the "Makefile" itself is created by the configuration program, and gets the value of "srcdir" from it. Not only that: the bootstrapping process involves many subdirectories, in which there are either makefiles or lisp files with @srcdir@, @builddir@ and @top_srcdir@ substitutions in them... Hmm, I really liked the fact that "configure" builds all these subdirectories, makefiles and script files for me, but maybe it will be better just to do everything "by hand", and have a set of Makefiles for the windows platform. In any case, I am very happy to see that, with MSYS, both the GNU MP library and the Boehm-Weiser garbage collector can be configured and compiled just as easy as on the unix platforms. Juanjo -- Max-Planck-Institut fuer Quantenoptik +49/(0)89/32905-345 Hans-Kopfermann-Str. 1, D-85748 www.mpq.mpg.de/Theorygroup/CIRAC/ Garching b. Muenchen, Germany Jua...@mp... |
From: Earnie B. <ear...@ya...> - 2003-07-08 14:27:14
|
Juan Jose Garcia-Ripoll wrote: > On Tuesday 08 July 2003 15:15, Earnie Boyd wrote: > >>>To give an idea of what goes on, in the bootstrap process ECL needs to >>>load a bunch of files that it locates using @srcdir@. Even though I >>>initially set to a valid windows path, d:/msys/1.0/home/user1/ecl, in my >>>Makefile.in it appears as /home/user1/ecl, and when ECL tries to >>>fopen("@srcdir@/boot.lisp"), it fails. >> >>You say that you explicitly use an absolute win32 path and MSYS is >>converting it to posix? Which version of MSYS? Can you provide a small >>test case? > > > I use MSYS 1.0.8. The thing is as follows: I have a script which uses "pwd -W" Try http://prdownloads.sf.net/mingw/MSYS-1.0.9-rc-1.exe?download instead. I think it will make a difference. The environment variables are coverted to Win32 paths. > (I figured this out) to get the win32 path of the directory in which the > source code of ECL resides. To keep things clean, this script makes a > directory "build_mingw" and once inside there it invokes the true > configuration file, with something like > d:/msys/1.0/home/user1/src/configure \ > --srcdir=d:/msys/1.0/home/user1/ecl \ > --prefix=d:/mingw/ecl [... more options ...] > > Here, d:/msys/1.0/home/user1/ecl is simply the output of "pwd -W". The role of > the configuration script is to figure out the capabilities of the system > (i.e. which functions are missing, size of integer numbers, etc). Plus, the > same script creates a lot of Makefile-s, config.status, config.h, etc in the > "build_mingw" directory. Many of these filese depend on the value of > "srcdir", but somehow this value gets trashed and becomes /home/user1/ecl. > Again 1.0.9 may make a difference. If have problems with it then I need to get more involved. > >>A possible work around would be to use a macro instead for you boot.lisp >>path. So that you have ``fopen(BOOT_LISP)'' and have the a >>-DBOOT_LISP="$srcdir/boot.lisp" in the Makefile. Notice the use of a >>variable instead of the configure replacement of @srcdir@. > > > The problem is that the "Makefile" itself is created by the configuration > program, and gets the value of "srcdir" from it. Not only that: the > bootstrapping process involves many subdirectories, in which there are either > makefiles or lisp files with @srcdir@, @builddir@ and @top_srcdir@ > substitutions in them... Hmm, I really liked the fact that "configure" builds > all these subdirectories, makefiles and script files for me, but maybe it > will be better just to do everything "by hand", and have a set of Makefiles > for the windows platform. > By hand - blech!! Yes, MSYS is built to execute configure, that was my major desire for it. Lot's of packages have special makefiles for windows. I'm hoping to eliminate the need for all of those with MSYS. Win32 is a different kind of bird from UNIX and if you distribute a prebuilt binary that requires knowing where a file is from the configure process, you're user is going to loose if you use absolute paths only. A work around for that is to use a known absolute path, I.E., the location of the binary file and use relative pathing with the absolute prefix. So if I have c:/Program Files/mingw/bin and I need to file c:/Program Files/mingw/share/mytool/config.ini then I need to path it as c:/Program Files/mingw/bin/../share/mytool/config.ini in the open. The c:/Program Files/mingw/bin portion is returned by a win32 API that gives you the path to the binary. If you don't do this then the end user of your distribution must install in exactly the same place that you configured it. That works for UNIX but not for Win32. I stated all of the above, so that you could see that you will have work to do on all those paths you state are given by configure, if you distribute a binary release and your binaries are dependent on the paths given by configure. > In any case, I am very happy to see that, with MSYS, both the GNU MP library > and the Boehm-Weiser garbage collector can be configured and compiled just as > easy as on the unix platforms. > Yes, and many others. Earnie. |
From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-08 16:29:29
|
On Tuesday 08 July 2003 16:28, Earnie Boyd wrote: > Try http://prdownloads.sf.net/mingw/MSYS-1.0.9-rc-1.exe?download > instead. I think it will make a difference. The environment variables > are coverted to Win32 paths. I have tracked this problem further by putting a couple of "set -x" here and there. The original problem is the following: My configure.in file tried to convert the srcdir variable to an absolute path by using the trick srcdir=`cd ${srcdir}; pwd`. I fixed this, so that it now reads srcdir=`cd ${srcdir}; pwd -W` in the mingw32 platform. But now the real problem is in config.status. This is a shell script created by "configure", and its purpose is to build all makefiles and special header files, plus all directories and subdirectories for the build process. This script does not accept DOS or win32 paths, and it breaks if srcdir has an absolute value with a drive unit in it (c:, d:, etc). In other words, if I take a GNU-ish program and do something like mkdir build cd build d:/path/to/a/source/tree/configure --srcdir=d:/path/to/a/source/tree the configuration process will fail, because the "config.status" program will not be able to process the srcdir=d:/path/to/a/source/tree The problem I am mentioning is therefore very general, and it is related to autoconf itself. I really do not understand why it exists at all -- I was involved in porting Autoconf to DOS-ish platforms (OS/2, DOS, win32...) long long ago. I made patches back then that allowed autoconf to handle DOS paths elegantly, and got many programs and libraries compiled in OS/2 that way. I seem to recall that those patches got in the main distribution, but it seems people have broken the compatibility that was built in those days, and the currently generated scripts fail with DOS pathnames. Juanjo |
From: Earnie B. <ear...@ya...> - 2003-07-08 16:44:15
|
Juan Jose Garcia-Ripoll wrote: > On Tuesday 08 July 2003 16:28, Earnie Boyd wrote: > >>Try http://prdownloads.sf.net/mingw/MSYS-1.0.9-rc-1.exe?download >>instead. I think it will make a difference. The environment variables >>are coverted to Win32 paths. > Is your below in response to 1.0.9? Earnie. > > I have tracked this problem further by putting a couple of "set -x" here and > there. > > The original problem is the following: My configure.in file tried to convert > the srcdir variable to an absolute path by using the trick srcdir=`cd > ${srcdir}; pwd`. I fixed this, so that it now reads srcdir=`cd ${srcdir}; pwd > -W` in the mingw32 platform. > > But now the real problem is in config.status. This is a shell script created > by "configure", and its purpose is to build all makefiles and special header > files, plus all directories and subdirectories for the build process. This > script does not accept DOS or win32 paths, and it breaks if srcdir has an > absolute value with a drive unit in it (c:, d:, etc). In other words, if I > take a GNU-ish program and do something like > > mkdir build > cd build > d:/path/to/a/source/tree/configure --srcdir=d:/path/to/a/source/tree > > the configuration process will fail, because the "config.status" program will > not be able to process the srcdir=d:/path/to/a/source/tree > > The problem I am mentioning is therefore very general, and it is related to > autoconf itself. I really do not understand why it exists at all -- I was > involved in porting Autoconf to DOS-ish platforms (OS/2, DOS, win32...) long > long ago. I made patches back then that allowed autoconf to handle DOS paths > elegantly, and got many programs and libraries compiled in OS/2 that way. I > seem to recall that those patches got in the main distribution, but it seems > people have broken the compatibility that was built in those days, and the > currently generated scripts fail with DOS pathnames. > > Juanjo > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > |
From: Earnie B. <ear...@ya...> - 2003-07-08 16:54:16
|
BTW, what version and what dependencies are there for me to try to build ECL? Earnie. Juan Jose Garcia-Ripoll wrote: > [Sorry if this message is duplicated -- I just noticed I used the wrong e-mail > address when sending the previous copy] > > Hi, > > I am quite sure someone must have explained this somewhere, but really I > cannot find any documentation shown how to do the following. > > I have a program that compiles and runs in many different unix environments > by means of "configure". The program in question is a Lisp interpreter > called ECL (http://ecl.sf.net). > > I gave MSYS an attempt and it works almost fine, except when my program tries > to locate files. My feeling is that MSYS forces, during configuration > process, all pathnames from windows format to what I would call > "MSYS-format". However, when I build my program, the open(), fopen(), and > other functions do not understand this convention. > > To give an idea of what goes on, in the bootstrap process ECL needs to load a > bunch of files that it locates using @srcdir@. Even though I initially set to > a valid windows path, d:/msys/1.0/home/user1/ecl, in my Makefile.in it > appears as /home/user1/ecl, and when ECL tries to > fopen("@srcdir@/boot.lisp"), it fails. > > Is there a standard tool which converts MSYS paths into windows ones? What is > the name of this tool? Or do I have to link my program against the MSYS DLL > so that fopen() learns about MSYS paths? If so, how do I do it and how should > I distribute the resulting executable? > > Best regards > > Juanjo > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > |
From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-08 17:45:04
|
On Tuesday 08 July 2003 18:55, Earnie Boyd wrote: > BTW, what version and what dependencies are there for me to try to build > ECL? > > Earnie. In general, I recommend building from CVS. I have uploaded the fixes required for mingw32 (ECL compiles under cygwin -- or used to --, but mingw does not have a times() function, nor lstat(), etc), but it takes a while to get the CVS server updated so therefore I have made a patch file against the 0.9 release, and left it here: http://ecls.sf.net/patch-0.9-current.gz Please tell me which of the methods you use, if you have problems with any of them. ECL is otherwise self-contained, and requires no other software than a working POSIX environment (sed, make, sh, etc): it includes a copy of the GMP library and the Boehm-Weiser garbage collector. It is intended to become a truly embeddable implementation of Common-Lisp, and it has been succesfully used as an extension language with Quake, XChat, and some other toy projects. Regards, Juanjo |
From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-08 16:58:47
|
On Tuesday 08 July 2003 18:45, Earnie Boyd wrote: > Juan Jose Garcia-Ripoll wrote: > > On Tuesday 08 July 2003 16:28, Earnie Boyd wrote: > >>Try http://prdownloads.sf.net/mingw/MSYS-1.0.9-rc-1.exe?download > >>instead. I think it will make a difference. The environment variables > >>are coverted to Win32 paths. > > Is your below in response to 1.0.9? Yes. I installed it over the 1.0.8, and since the Software Installer now shows 1.0.9 on the list of programs, I assume everything went ok. Juanjo |
From: Earnie B. <ear...@ya...> - 2003-07-08 17:51:11
|
Juan Jose Garcia-Ripoll wrote: > On Tuesday 08 July 2003 18:45, Earnie Boyd wrote: > >>Juan Jose Garcia-Ripoll wrote: >> >>>On Tuesday 08 July 2003 16:28, Earnie Boyd wrote: >>> >>>>Try http://prdownloads.sf.net/mingw/MSYS-1.0.9-rc-1.exe?download >>>>instead. I think it will make a difference. The environment variables >>>>are coverted to Win32 paths. >> >>Is your below in response to 1.0.9? > > > Yes. I installed it over the 1.0.8, and since the Software Installer now shows > 1.0.9 on the list of programs, I assume everything went ok. > What happens if you don't use the pwd trickery? Tell me which version to download or if you're using the CVS version and I'll give it a go. Earnie. |
From: Juan J. Garcia-R. <wo...@ar...> - 2003-07-10 07:43:24
|
Ooops, sorry, this message passed through my mailbox unnoticed. On Tuesday 08 July 2003 19:52, Earnie Boyd wrote: > > Yes. I installed it over the 1.0.8, and since the Software Installer now > > shows 1.0.9 on the list of programs, I assume everything went ok. > > What happens if you don't use the pwd trickery? If I undo the fixes in ecl/configure, ecl/src/configure.in and ecl/src/aclocal.m4 with respect to the "pwd" command, then ECL builds the bootstrapping executable, ecl_min.exe, which is unable to find out where the sources to load are. > Tell me which version to download or if you're using the CVS version and > I'll give it a go. You can just pull the latest version from CVS. TIA, Juanjo |