From: Stephen <ste...@ho...> - 2005-01-16 15:08:45
|
Earnie Boyd said: "It may sometimes be better to use the prefix=/mingw due to the way that the default library folder is searched for by the linker." and "Does http://www.mingw.org/MinGWiki/index.php/PostRejected answer how you might do what you want?" Thanks for the reply. The prefix determines where the program gets installed. ./configure --prefix=/use/local -C insures that the executable will be placed in /local/bin rather that /mingw/bin or /usr/bin under msys. My goal is to keep the locally compiled executables separate and to create a mini unix environment in Windows. There still is the problem that some of the env vars in the Windows cmd shell may conflict with the env vars in the bash command shell as my example demonstrated. In answer to the second question, my post went through this time, so the changes I made in my mail account properties in Outlook must have worked. It is tricky with MSN. Stephen |
From: Earnie B. <ea...@us...> - 2005-01-16 15:33:22
|
<quote who="Stephen"> > Earnie Boyd said: > > "It may sometimes be better to use the prefix=/mingw due to the way that > the default library folder is searched for by the linker." > > and > > "Does http://www.mingw.org/MinGWiki/index.php/PostRejected answer how you > might do what you want?" > > Thanks for the reply. The prefix determines where the program gets > installed. ./configure --prefix=/use/local -C insures that the executable > will be placed in /local/bin rather that /mingw/bin or /usr/bin under > msys. That is correct but doesn't nullify my statement. If you have a library you wish the linker to find, setting the prefix to /usr/local isn't what you will want as currently ld will not find it by default. You will have to tell ld where to find the library. > My goal is to keep the locally compiled executables separate and to create > a > mini unix environment in Windows. There still is the problem that some of > the env vars in the Windows cmd shell may conflict with the env vars in > the > bash command shell as my example demonstrated. > I do not know why your bison command had the paths it had. What distribution of bison are you using? Perhaps you have environment variables for bison that are not correct. The PATH as set by starting msys via the default msys.bat will search your /usr/local/bin then your /mingw/bin then the /usr/bin directory for the executable. > In answer to the second question, my post went through this time, so the > changes I made in my mail account properties in Outlook must have worked. > It > is tricky with MSN. > I'm glad to hear that you resolved it. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Keith M. <kei...@to...> - 2005-01-17 10:11:02
|
> Thanks for the reply. The prefix determines where the program gets > installed. ./configure --prefix=/use/local -C insures that the executable > will be placed in /local/bin rather that /mingw/bin or /usr/bin under msys. I also do this, for locally compiled and installed packages. You do need to take care when you specify the prefix -- some packages, (groff is one such), use whatever you specify as a component of some path which gets compiled into the executable. If you specify merely '--prefix=/usr/local', then any compiled in path will have the form 'INTERNAL_PATH=/usr/local/path/to/my/files', which the native Win32 executable wil not be able to resolve at run time. In such cases, you may need to specify '--prefix=D:/msys/1.0/local', where 'D:/msys/1.0' represents the root of your msys installation, as its absolute Win32 filesystem location. This requirement is explained in more detail, in my README.MinGW for the GNU groff package -- you can find it at http://savannah.gnu.org/cgi-bin/viewcvs/groff/groff/README.MinGW?rev=1.3&content-type=text/vnd.viewcvs-markup HTH. Cheers, Keith. |
From: Earnie B. <ea...@us...> - 2005-01-17 12:18:40
|
<quote who="Keith MARSHALL"> >> Thanks for the reply. The prefix determines where the program gets >> installed. ./configure --prefix=/use/local -C insures that the > executable >> will be placed in /local/bin rather that /mingw/bin or /usr/bin under > msys. > > I also do this, for locally compiled and installed packages. > > You do need to take care when you specify the prefix -- some packages, > (groff is one such), use whatever you specify as a component of some > path which gets compiled into the executable. If you specify merely > '--prefix=/usr/local', then any compiled in path will have the form > 'INTERNAL_PATH=/usr/local/path/to/my/files', which the native Win32 > executable wil not be able to resolve at run time. In such cases, you > may need to specify '--prefix=D:/msys/1.0/local', where 'D:/msys/1.0' > represents the root of your msys installation, as its absolute Win32 > filesystem location. > Another option is to modify the build files so that they are similar to WPREFIX=`pwd $prefix && pwd -W` INTERNAL_PATH=${WPREFIX}/path/to/my/files Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Earnie B. <ea...@us...> - 2005-01-17 13:54:23
|
<quote who="Earnie Boyd"> > > Another option is to modify the build files so that they are similar to > > WPREFIX=`pwd $prefix && pwd -W` ^^^ s/pwd/cd > INTERNAL_PATH=${WPREFIX}/path/to/my/files > > > Earnie > > -- > http://www.mingw.org > http://sourceforge.net/projects/mingw > https://sourceforge.net/donate/index.php?user_id=15438 |
From: Keith M. <kei...@to...> - 2005-01-17 14:14:40
|
<quote who="Keith MARSHALL"> >>> Thanks for the reply. The prefix determines where the program gets >>> installed. ./configure --prefix=/use/local -C insures that the >>> executable >>> will be placed in /local/bin rather that /mingw/bin or /usr/bin under >>> msys. >> >> I also do this, for locally compiled and installed packages. >> >> You do need to take care when you specify the prefix -- some packages, >> (groff is one such), use whatever you specify as a component of some >> path which gets compiled into the executable. If you specify merely >> '--prefix=/usr/local', then any compiled in path will have the form >> 'INTERNAL_PATH=/usr/local/path/to/my/files', which the native Win32 >> executable will not be able to resolve at run time. In such cases, you >> may need to specify '--prefix=D:/msys/1.0/local', where 'D:/msys/1.0' >> represents the root of your msys installation, as its absolute Win32 >> filesystem location. </quote> <quote who="Earnie Boyd"> > Another option is to modify the build files so that they are similar to > > WPREFIX=`pwd $prefix && pwd -W` > INTERNAL_PATH=${WPREFIX}/path/to/my/files </quote> Agreed, this is an option. However, not everyone trying to build generic GNU packages with MinGW wants, or indeed would feel confident, to modify the supplied build files in this way. Furthermore, in a real GNU project, the modifications required may well be more extensive than this simplified example might suggest. I cite examples based on groff, because it is a GNU project to which I contribute. I am *not* the maintainer, so even if I were to submit build file patches such as this, their eventual inclusion in the official GNU groff distribution would be subject to maintainer approval. One day, I may find time to develop and submit suitable patches, but, even today, the official groff distribution builds OOTB on a wide variety of *nix systems, and also on Win32 with MinGW, *provided* configure is invoked with the '--prefix=D:/msys/1.0/local' flag specified, identifying an absolute path from the Win32 file system root. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-01-17 15:45:13
|
<quote who="Keith MARSHALL"> > > <quote who="Earnie Boyd"> >> Another option is to modify the build files so that they are similar to >> >> WPREFIX=`pwd $prefix && pwd -W` >> INTERNAL_PATH=${WPREFIX}/path/to/my/files > </quote> > > Agreed, this is an option. However, not everyone trying to build generic > GNU packages with MinGW wants, or indeed would feel confident, to modify > the supplied build files in this way. Furthermore, in a real GNU project, > the modifications required may well be more extensive than this simplified > example might suggest. > I'm glad we're having this conversation really. I only responded for completeness, but have never given much thought to this. > I cite examples based on groff, because it is a GNU project to which I > contribute. I am *not* the maintainer, so even if I were to submit build > file patches such as this, their eventual inclusion in the official GNU > groff distribution would be subject to maintainer approval. One day, I > may find time to develop and submit suitable patches, but, even today, > the official groff distribution builds OOTB on a wide variety of *nix > systems, and also on Win32 with MinGW, *provided* configure is invoked > with the '--prefix=D:/msys/1.0/local' flag specified, identifying an > absolute path from the Win32 file system root. > So we could also do ``configure --prefix=`cd /usr/local && pwd -W`'' in order to have the best of both worlds. Thanks, Keith, I need to think some more about this. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Keith M. <kei...@to...> - 2005-01-17 16:33:58
|
<quote who="Earnie Boyd"> > > Another option is to modify the build files so that they are similar to > > WPREFIX=`pwd $prefix && pwd -W` ^^^ s/pwd/cd > INTERNAL_PATH=${WPREFIX}/path/to/my/files </quote> Ha! I wasn't paying enough attention -- I missed this deliberate mistake in your earlier post. On reflection, perhaps the simplest implementation, at least for autoconf generated build files, would be to define something like: # MSYS_PREFIX_HACK # # If the user didn't specify any prefix, # AND the build system supports `pwd -W`, (i.e. is probably MSYS), # set the default autoconf prefix, as a Win32 format path. # # Has no effect, UNLESS the build system supports `pwd -W`, # AND '/usr/local' exists in the MSYS pseudo file system. # AC_DEFUN([MSYS_PREFIX_HACK], [if test "$prefix" = "NONE"; then prefix=`exec 2>/dev/null; cd /usr/local && pwd -W` || prefix=NONE fi ]) in aclocal.m4, (or some site specific autoconf macro file), and to invoke it via configure.ac, when configure is generated. What do you think? I may propose something along these lines, for the groff project. Cheers, Keith. |
From: Earnie B. <ea...@us...> - 2005-01-17 18:22:26
|
<quote who="Keith MARSHALL"> > <quote who="Earnie Boyd"> >> >> Another option is to modify the build files so that they are similar to >> >> WPREFIX=`pwd $prefix && pwd -W` > ^^^ s/pwd/cd >> INTERNAL_PATH=${WPREFIX}/path/to/my/files > </quote> > > Ha! I wasn't paying enough attention -- I missed this deliberate mistake > in your earlier post. > > On reflection, perhaps the simplest implementation, at least for autoconf > generated build files, would be to define something like: > > # MSYS_PREFIX_HACK > # > # If the user didn't specify any prefix, > # AND the build system supports `pwd -W`, (i.e. is probably MSYS), > # set the default autoconf prefix, as a Win32 format path. > # > # Has no effect, UNLESS the build system supports `pwd -W`, > # AND '/usr/local' exists in the MSYS pseudo file system. > # > AC_DEFUN([MSYS_PREFIX_HACK], > [if test "$prefix" = "NONE"; then > prefix=`exec 2>/dev/null; cd /usr/local && pwd -W` || prefix=NONE > fi > ]) > > in aclocal.m4, (or some site specific autoconf macro file), and to invoke > it via configure.ac, when configure is generated. > > What do you think? I may propose something along these lines, for the > groff project. > Well, it should be MINGW32_PREFIX_HACK, IMO; but yes I think it should be the way to go. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Keith M. <kei...@to...> - 2005-01-18 10:45:47
|
<quote author="Keith Marshall> >> # MSYS_PREFIX_HACK >> # >> # If the user didn't specify any prefix, >> # AND the build system supports `pwd -W`, (i.e. is probably MSYS), >> # set the default autoconf prefix, as a Win32 format path. >> # >> # Has no effect, UNLESS the build system supports `pwd -W`, >> # AND '/usr/local' exists in the MSYS pseudo file system. >> # >> AC_DEFUN([MSYS_PREFIX_HACK], >> [if test "$prefix" = "NONE"; then >> prefix=`exec 2>/dev/null; cd /usr/local && pwd -W` || prefix=NONE >> fi >> ]) >> >> in aclocal.m4, (or some site specific autoconf macro file), and to invoke >> it via configure.ac, when configure is generated. >> >> What do you think? I may propose something along these lines, for the >> groff project. </quote> <quote author="Earnie Boyd"> > Well, it should be MINGW32_PREFIX_HACK, IMO; but yes I think it should be > the way to go. </quote> Whatever -- the name doesn't much matter to the functionality. I thought MSYS_PREFIX_HACK, because it relies on a feature of the MSYS shell, and is rather compiler neutral. It really wouldn't help users of MinGW, who don't use the MSYS environment for running their build scripts, unless of course, their chosen build environment uses POSIX file system emulation similar to that provided by MSYS, *and* their shell also supports the 'pwd -W' feature. Maybe there is a case for keeping this test as MSYS_PREFIX_HACK, and also providing a complementary MINGW32_PREFIX_HACK macro, which would rely on an AC_COMPILE_IFELSE, or an AC_RUN_IFELSE type test. Just a further thought -- if this is the way to go, wouldn't it be nice if it was available as a standard autoconf macro? Perhaps we should suggest it to the autoconf maintainers, (so it would become AC_MSYS_PREFIX_HACK, or AC_MINGW32_PREFIX_HACK, if you prefer). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-01-18 12:42:44
|
<quote who="Keith MARSHALL"> > <quote author="Earnie Boyd"> >> Well, it should be MINGW32_PREFIX_HACK, IMO; but yes I think it should > be >> the way to go. > </quote> > > Whatever -- the name doesn't much matter to the functionality. I thought I agree. > MSYS_PREFIX_HACK, because it relies on a feature of the MSYS shell, and is > rather compiler neutral. It really wouldn't help users of MinGW, who > don't > use the MSYS environment for running their build scripts, unless of > course, > their chosen build environment uses POSIX file system emulation similar to > that provided by MSYS, *and* their shell also supports the 'pwd -W' > feature. > Maybe there is a case for keeping this test as MSYS_PREFIX_HACK, and also > providing a complementary MINGW32_PREFIX_HACK macro, which would rely on > an AC_COMPILE_IFELSE, or an AC_RUN_IFELSE type test. > My thinking for the MINGW32_PREFIX_HACK name is that this should only be turned on for HOST=*-*-mingw32 and BUILD=*-*-mingw32. Your thinking for the MSYS_PREFIX_HACK is that it is only valid if building with MSYS. But, is that true? What about building a mingw32 package under Cygwin? Shouldn't the prefix be modified then as well? Cygwin has cygpath and maybe I should just break down and supply cygpath for MSYS. > Just a further thought -- if this is the way to go, wouldn't it be nice if > it was available as a standard autoconf macro? Perhaps we should suggest > it to the autoconf maintainers, (so it would become AC_MSYS_PREFIX_HACK, > or AC_MINGW32_PREFIX_HACK, if you prefer). > I agree. Autoconf already sets CYGPATH to cygpath if it is available else to echo. Would an MSYS version of cygpath help resolve this issue? Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Keith M. <kei...@to...> - 2005-01-18 15:23:47
|
<quote author="Earnie Boyd> > My thinking for the MINGW32_PREFIX_HACK name is that this should only be > turned on for HOST=*-*-mingw32 and BUILD=*-*-mingw32. Your thinking for > the MSYS_PREFIX_HACK is that it is only valid if building with MSYS. But, > is that true? What about building a mingw32 package under Cygwin? > Shouldn't the prefix be modified then as well? Cygwin has cygpath and > maybe I should just break down and supply cygpath for MSYS. </quote> Yes. I also realised there would be a thorny issue for MinGW target builds on hosts other than MSYS; this is true for Cygwin hosts, and equally so for cross compiles to a MinGW target from any *nix host. However, the `pwd -W` trick doesn't work for these alternative hosts, so an alternative solution is required. My thinking was not so much that the hack was only *valid* for building with MSYS, but rather that, as I proposed it, it will only *work* when building with MSYS. <quote author="Earnie Boyd> ><quote who="Keith Marshall"> >> Just a further thought -- if this is the way to go, wouldn't it be nice if >> it was available as a standard autoconf macro? Perhaps we should suggest >> it to the autoconf maintainers, (so it would become AC_MSYS_PREFIX_HACK, >> or AC_MINGW32_PREFIX_HACK, if you prefer). ></quote> > > I agree. Autoconf already sets CYGPATH to cygpath if it is available else > to echo. Would an MSYS version of cygpath help resolve this issue? </quote> Possibly. Clearly, this requires further thought, before jumping in with a half baked solution. Yes, we need some tool which will translate the POSIX representation of '/usr/local' to a Win32 form, but how will it identify the appropriate translation, if the build and target platforms are not the same? (IOW, while `cd /usr/local && pwd -W` will deliver 'D:/msys/1.0/local' in an MSYS build environment, where the MSYS installation root is 'D:/msys/1.0', what should 'cygpath' deliver, when the build host has no knowledge of the configuration of the target run time host? At the moment, I can't see past a solution for such cross compiling scenarios, other than requiring the user to specify the target installation path, by explicitly giving 'configure' a hint, with '--prefix=D:/Win32/installation/path'). Regards, Keith. |