From: Keith M. <kei...@to...> - 2005-03-29 13:55:09
|
Earnie Boyd wrote: >> One of my reasons for preferring /usr/local is that that is the >> preferred installation path for most GNU software. Of course, you >> *do* have to configure with --prefix=`cd /usr/local;pwd -W`, to sort >> out the problem of path translation between the MSYS and Windoze >> semantics, or add an MSYS_PREFIX_HACK, such as I suggested a few >> weeks ago, to `configure.ac', and regenerate `configure' before >> building. It would be nice if GNU packages had this level of MSYS >> support built in, but how would one go about getting it accepted, >> as a general concept? > > The answer would be to submit a patch to the autoconf list for discussion. > But I've an idea brewing that may make it not worth submitting. The idea > is to treat --prefix=/what/ever/specified/path as a special case and > always convert to the windows path regardless. I haven't decided where to > implement the special case. ... I thought about submitting such a patch, but, as I formulated the MSYS_PREFIX_HACK, it would rely on individual project maintainers including the test in their `configure.ac's, project by project. What is really required, I think, is for the AC_INIT code to include the appropriate test, so that all `autoconf' managed projects will automagically incorporate the required MSYS hook, when the project maintainers next regenerate their `configure' scripts, using a version of `autoconf' which enforces the MSYS_PREFIX_HACK test. (Note that even this strategy would require co-operation from individual project maintainers, since the regeneration of the `configure' script is required on a project by project basis). Your idea of handling it from MSYS itself seems attractive, but I'm curious as to how you would ensure that every reference to ${prefix}, throughout the build process, was correctly mapped. Wouldn't this require some degree of co-operation from the `configure' script itself? How would such co-operation be obtained, when you don't have control of the content of the `configure' script? How would you handle the case where the user doesn't specify `--prefix', (which is addressed by my original MSYS_PREFIX_HACK)? Perhaps an MSYS specific, but package agnostic, wrapper for `configure' would do the trick; the disadvantage would be a minor departure from the normal GNU `./configure && make && make install' build procedure. Sorry: I don't mean to seem negative here; just playing devil's advocate, in the hope of promoting further constructive discussion. Cheers, Keith. |
From: Keith M. <kei...@to...> - 2005-03-29 16:15:12
|
Earnie Boyd wrote: > So, rather than --prefix being the key, what really needs > to happen is the value of the variable prefix always needs > to contain a windows path. Perhaps others as well. Then > when the configure script creates the Makefile the correct > values are in place. Yes. That's the way I see it. When I configure a GNU package, I generally find that, if I specify --prefix=`cd /usr/local;pwd -W`, then everything falls into place. If I forget the --prefix spec, then configure sets /usr/local as default, but then any paths which depend on ${prefix}, and are compiled into object files, get POSIX path semantics, where windows semantics are required. The MSYS_PREFIX_HACK, which I proposed previously, addresses this. By placing this definition in my `acsite.m4' ... # MSYS_PREFIX_HACK # # If the user didn't specify any explicit value for ${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 AC_MSG_CHECKING([MSYS build PREFIX mapping]) prefix=`exec 2>/dev/null; cd /usr/local && pwd -W` || prefix=NONE test "$prefix" = "/usr/local" && prefix=NONE AC_MSG_RESULT([$prefix]) fi ]) I can then modify any package's `configure.ac', to invoke it after AC_INIT, e.g. using the `configure.ac' fragment ... AC_INIT AC_PREREQ(2.59) MSYS_PREFIX_HACK . . and run autoconf, to regenerate `configure', I then have a GNU package which builds according to GNU convention, under MSYS, with a default `${prefix}' correctly mapped to its native windows path. (Of course, there may be, and usually will be, other porting issues to address, besides this). If this test, or something like it, could be implemented as part of AC_INIT, or perhaps AC_OUTPUT, then *all* GNU packages which use autoconf would eventually support the correct mapping of ${prefix} for building with MinGW under MSYS. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-03-29 17:00:36
|
<quote who="Keith MARSHALL"> > Earnie Boyd wrote: >> So, rather than --prefix being the key, what really needs >> to happen is the value of the variable prefix always needs >> to contain a windows path. Perhaps others as well. Then >> when the configure script creates the Makefile the correct >> values are in place. > > Yes. That's the way I see it. > Good. > When I configure a GNU package, I generally find that, if I > specify --prefix=`cd /usr/local;pwd -W`, then everything falls > into place. If I forget the --prefix spec, then configure > sets /usr/local as default, but then any paths which depend > on ${prefix}, and are compiled into object files, get POSIX > path semantics, where windows semantics are required. > > The MSYS_PREFIX_HACK, which I proposed previously, addresses > this. By placing this definition in my `acsite.m4' ... > > # MSYS_PREFIX_HACK > # > # If the user didn't specify any explicit value for ${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 > AC_MSG_CHECKING([MSYS build PREFIX mapping]) > prefix=`exec 2>/dev/null; cd /usr/local && pwd -W` || prefix=NONE > test "$prefix" = "/usr/local" && prefix=NONE > AC_MSG_RESULT([$prefix]) > fi > ]) > But if I change MSYS so that variable prefix is always a win32 path value this MSYS_PREFIX_HACK would not need to be done and ... > I can then modify any package's `configure.ac', to invoke it > after AC_INIT, e.g. using the `configure.ac' fragment ... > > AC_INIT > AC_PREREQ(2.59) > MSYS_PREFIX_HACK > . > . > > and run autoconf, to regenerate `configure', I then have a > GNU package which builds according to GNU convention, under > MSYS, with a default `${prefix}' correctly mapped to its > native windows path. (Of course, there may be, and usually > will be, other porting issues to address, besides this). > you would not be required to have autotools to regenerate configure. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Tor L. <tm...@ik...> - 2005-03-29 17:17:00
|
Earnie Boyd writes: > But if I change MSYS so that variable prefix is always a win32 path value > this MSYS_PREFIX_HACK would not need to be done and ... But what if someone in addition to --prefix also specifies one or several of --bindir, --libdir, etc? (Or do you use "prefix" as a placeholder for all of them?) But perhaps that is not probable. I guess for Win32 one usually explicitly *wants* to use the same prefix for all the configurable locations, so that run-time relocation based on a lookup of the bindir works for all of them. --tml |
From: Earnie B. <ea...@us...> - 2005-03-29 17:37:40
|
<quote who="Tor Lillqvist"> > Earnie Boyd writes: > > But if I change MSYS so that variable prefix is always a win32 path > value > > this MSYS_PREFIX_HACK would not need to be done and ... > > But what if someone in addition to --prefix also specifies one or > several of --bindir, --libdir, etc? (Or do you use "prefix" as a > placeholder for all of them?) > I will look at the typical configure script and Makefile and consider other variables as well. > But perhaps that is not probable. I guess for Win32 one usually > explicitly *wants* to use the same prefix for all the configurable > locations, so that run-time relocation based on a lookup of the bindir > works for all of them. > Yes, but there are those who are used to administration of UNIX and would possibly specify them out of habit. We must remember that the goal for MSYS is a tool to support ./configure && make for MinGW and not anything else. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Mark P. <mar...@ho...> - 2005-03-29 17:48:31
|
I don't know if this is the correct list for this but my head is going to explode if I can't sort this out soon. I am trying to compile the following code as part of a larger program. The only problem is whenever try to compile i get an error from the mingw compilor saying "storage size of 'division' is unknown" - I tried changing the line involved to struct ldiv_t{ long quot, rem;}division; but this didn't fix anything - now i get an error about incompatible types in assignment when i try to make division equal to the output of ldiv. I thought ldiv was an inbuilt strcture and that that could be the reason they are "incompatible". I then found the code in the stdlib.h header saying ldiv doesn't work unless you do some wierd command line stuff. I use the latest version of the mingw runtime (3.7) for Dev-C++ - how can i fix this code to mae it work - or if not can you perhaps suggest another way of doing this that would work as well? Thanks in advance Mark ========================== int get_factors( long working_N ) { int count_f; struct ldiv_t division; num_factor = 0; for( count_f = 0; count_f < 25; count_f++ ) { division = ldiv( working_N, factor_base[count_f] ); if( division.rem != 0 ) { continue; } else { factor_store[num_factor] = factor_base[count_f]; num_factor++; count_f--; working_N = division.quot; } } return num_factor; } ========================== |
From: Michael G. <mg...@te...> - 2005-03-29 23:23:09
|
[problem involving ldiv_t] > I then found the code in the stdlib.h header saying ldiv=20 > doesn't work unless you do some wierd command line stuff. This "weird command line stuff" actually is a compiler option for gcc (name -fno-pcc-struct-return) which according the comment in stdlib.h should be automatically be enabled for mingw32 (this is what "is included in the mingw32 specs file" means). I'm currently not on Win32 and therefor check with the precompiled W32 binaries but my Linux-hosted crosscompiler build from the same sources does NOT seem to include this option (i.e. it is not listed when I issue "x-win32-gcc -dumpspecs"). You may get a shell and enter gcc -dumpspecs and see wether the output contains anything like 'pcc-struct-return'. You might also want to try to add '-fno-pcc-struct-return' (without the quotes) to your compiler options and retry compiling. Last not least (and possibly a stupid question): you do include <stdlib.h>, don't you !?! HTH, best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Earnie B. <ea...@us...> - 2005-03-30 00:08:56
|
<quote who="Earnie Boyd"> > > <quote who="Tor Lillqvist"> >> Earnie Boyd writes: >> > But if I change MSYS so that variable prefix is always a win32 path >> value >> > this MSYS_PREFIX_HACK would not need to be done and ... >> >> But what if someone in addition to --prefix also specifies one or >> several of --bindir, --libdir, etc? (Or do you use "prefix" as a >> placeholder for all of them?) >> > > I will look at the typical configure script and Makefile and consider > other variables as well. > Ah, a beautiful thing. Now I'm testing what broke. For the moment I'm only looking for the prefix variable. I had to modify both bash and MSYS. Look for the changes to be up in CVS no later than tomorrow. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Keith M. <kei...@to...> - 2005-03-30 13:44:37
|
Earnie Boyd wrote: > But if I change MSYS so that variable prefix is always a win32 > path value this MSYS_PREFIX_HACK would not need to be done ... I'm curious as to how you might achieve that. In a recently generated configure script I see the following sequence of operations, invoked by AC_INIT: 1) Variable `ac_default_prefix' is explicitly initialised, as `ac_default_prefix=/usr/local' 2) Variable `prefix' is explicitly initialised, as `prefix=NONE' 3) Command line arguments are parsed; if `--prefix=value' is specified, then variable `prefix' is redefined, as `prefix=value' Then, when we get to the AC_OUTPUT phase, I see: `test "x$prefix" = xNONE && prefix=$ac_default_prefix' I know your objective with MSYS is to provide a minimal environment for running `./configure && make', but some of us also use it simply to have a usable shell on Win32 -- I know I am not not alone in saying that cmd.exe and command.com are quite useless. If you kludge MSYS, or MSYS-bash, such that any attempt to define a variable called `prefix', (or indeed, any other specifically named variable, other than those which are documented as special in standard bash), then you diminish its value as a generally useful UNIXy shell for Win32. Expand that, to treat other variable names as special cases, and you increase the probability of nasty surprises even further, making MSYS even less generally useful. Surely, the better approach is to adapt autoconf, such that either the AC_INIT setting of `ac_default_prefix' is more intelligent wrt Win32 (or more specifically, MSYS) paths, or to adapt the AC_OUTPUT reassignment of `prefix=$ac_default_prefix' to incorporate some variant of the MSYS_PREFIX_HACK logic I presented earlier -- my preference would be to have a more intelligent initialisation for `ac_default_prefix', e.g. instead of: ac_default_prefix=/usr/local say: ac_default_prefix=`exec 2>/dev/null;cd /usr/local;pwd -W` ||\ ac_default_prefix=/usr/local I have tested this alternative initialisation on every system available to me. On SunOS 5.5.1 with `sh', `ksh' and `bash', on Linux 2.4.18 with `sh' which is linked to `bash', and on Cygwin with `sh' and with `bash', it sets `ac_default_prefix=/usr/local', while on my MSYS setup it sets `ac_default_prefix=d:/msys/1.0/local', which is exactly the behaviour I want to see; (it does, of course, require that the directory `d:/msys/1.0/local' already exists, when the `pwd -W` is invoked, otherwise it would simply revert to the `ac_default_prefix=/usr/local' behaviour). Such autoconf modification *could* be restricted to the mingw.org distribution of autotools, but then a regeneration of `configure' would become a prerequisite phase of the MSYS build process, for autoconf maintained packages. A better solution, IMO, would be to incorporate this as an autoconf standard. BTW, I have opened a thread for this topic on `aut...@gn...'. This message is copied to both MinGW-users and to autoconf lists. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-03-31 14:06:34
|
<quote who="Keith MARSHALL"> > Earnie Boyd wrote: >> But if I change MSYS so that variable prefix is always a win32 >> path value this MSYS_PREFIX_HACK would not need to be done ... > > I'm curious as to how you might achieve that. > > In a recently generated configure script I see the following > sequence of operations, invoked by AC_INIT: > > 1) Variable `ac_default_prefix' is explicitly initialised, > as `ac_default_prefix=/usr/local' > > 2) Variable `prefix' is explicitly initialised, as > `prefix=NONE' > Relative paths are not converted so the value of prefix will be unchanged. > 3) Command line arguments are parsed; if `--prefix=value' > is specified, then variable `prefix' is redefined, as > `prefix=value' > > Then, when we get to the AC_OUTPUT phase, I see: > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix' > So when prefix is set to /usr/local it is converted to the win32 path (E.G.: C:/MSYS/1.0/local). I've used my change enough now to know that it works well. I want to do a few more configure exercises before I upload a snapshot. If you care to suggest a package configure to try, feel free to let me know about it. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Bob F. <bfr...@si...> - 2005-03-30 15:50:20
|
On Wed, 30 Mar 2005, Keith MARSHALL wrote: > Surely, the better approach is to adapt autoconf, such that either > the AC_INIT setting of `ac_default_prefix' is more intelligent wrt > Win32 (or more specifically, MSYS) paths, or to adapt the AC_OUTPUT > reassignment of `prefix=$ac_default_prefix' to incorporate some > variant of the MSYS_PREFIX_HACK logic I presented earlier -- my > preference would be to have a more intelligent initialisation > for `ac_default_prefix', e.g. instead of: > > ac_default_prefix=/usr/local > > say: > > ac_default_prefix=`exec 2>/dev/null;cd /usr/local;pwd -W` ||\ > ac_default_prefix=/usr/local > > I have tested this alternative initialisation on every system > available to me. On SunOS 5.5.1 with `sh', `ksh' and `bash', on I am sure that this works great if the real Windows path represented by prefix contains embedded spacess. ;-) Many/most packages will bomb as soon as they encounter spaces in paths. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Keith M. <kei...@to...> - 2005-03-31 09:57:02
|
Bob Friesenhahn wrote: >> ac=5Fdefault=5Fprefix=3D`exec 2>/dev/null;cd /usr/local;pwd -W` ||\ >> ac=5Fdefault=5Fprefix=3D/usr/local >> >> I have tested this alternative initialisation on every system >> available to me. On SunOS 5.5.1 with `sh', `ksh' and `bash', on > > I am sure that this works great if the real Windows path represented=20 > by prefix contains embedded spacess. ;-) Actually, there is no reason why it shouldn't; it is properly quoted, (by the backquotes), to ensure that `ac=5Fdefault=5Fprefix' will be correct= ly assigned, even if there *are* spaces embedded in the path. If that breaks something else, later in the configure script, then that later statement is improperly quoted, and should be fixed. However, there is one small, but very significant flaw which you didn't notice, or at least you didn't point it out, perhaps because you were more interested in delivering your sarcastic put down, than offering any constructive criticism; ah well, it *is* said that sarcasm is the final resort of the incompetent ... So, the flaw: the above *should* be written as ... ac=5Fdefault=5Fprefix=3D`exec 2>/dev/null;cd /usr/local && pwd -W` ||\ ac=5Fdefault=5Fprefix=3D/usr/local My earlier formulation of this *will* break, on any system on which `pwd -W` does not fail, if /usr/local either does not exist, or is not accessible by the user running the configure script. SunOS 5.5.1 with its standard `sh' is one such system, Cygwin with `sh' is another, and, oh dear, MSYS, the very system it is intended to help out, is yet another. (There are undoubtedly others besides these three, which I am unable to ascertain definitively, since I have no access to suitable test platforms). > Many/most packages will bomb as soon as they encounter spaces in=20 > paths. Spaces in path names are a Microsoft conspiracy to maximise the user hostility of their grossly overrated operating system. Smart admins don't use them. Smart users don't. Why do you? (Don't answer; it's a rhetorical question; I'm not really interested). In any case, when you install MSYS, the installer offers to put it in `C:\MSYS\1.0'. If you changed anything other than the drive letter assignment, then, borrowing a quotation from an explanation by Alejandro L=F3pez-Valencia, of how to build a Win32 native groff using Cygwin, "you are trying to be too clever for your own good; remove it, and reinstall properly". With a correct MSYS install, and the corrected version of my `ac=5Fdefault=5Fprefix' assignment, you would never see any embedded space in the assigned path. Regards, Keith. |
From: Keith M. <kei...@to...> - 2005-04-01 10:22:52
|
Earnie Boyd wrote: >> 1) Variable `ac_default_prefix' is explicitly initialised, >> as `ac_default_prefix=/usr/local' >> >> 2) Variable `prefix' is explicitly initialised, as >> `prefix=NONE' >> > > Relative paths are not converted so the value of prefix will be unchanged. > >> 3) Command line arguments are parsed; if `--prefix=value' >> is specified, then variable `prefix' is redefined, as >> `prefix=value' >> >> Then, when we get to the AC_OUTPUT phase, I see: >> >> `test "x$prefix" = xNONE && prefix=$ac_default_prefix' > > So when prefix is set to /usr/local it is converted to the win32 path > (E.G.: C:/MSYS/1.0/local). I've used my change enough now to know that it > works well. I want to do a few more configure exercises before I upload a > snapshot. That seems pretty much what we want, for the purposes of configuring and making autotool managed packages. However, still playing devil's advocate, my concern is not that this won't work -- I'm sure you've made it work very well indeed -- but that it is making MSYS, and its implementation of `bash', unnecessarily specialised towards this goal. I appreciate that this *is* the primary goal of MSYS; however, it is also genuinely useful far beyond this primary goal. Agreed, attaching special significance to an environment variable called `prefix' is a small price to pay, in order to better realise the goal; I do wonder, however, if it is the best solution to a problem which could be eliminated at source, by a fairly trivial patch to autoconf's `general.m4' code, to make it more intelligent in its initial assignment of `ac_default_prefix'. As a short term solution, this MSYS change sounds ideal; I look forward to trying it out, when the snapshot is available. In the long term, I still think it is worth pursuing the idea of an autoconf patch. When that eventually filtered through to the majority of packages, the need for specialised handling of `prefix' would fall away. Perhaps it would never become completely unnecessary however; how feasible would it be to provide this special `prefix' handling feature, but to also incorporate some mechanism, say with a custom `shopt' or `set -o' option, to enable and disable it at will? > If you care to suggest a package configure to try, feel free to let > me know about it. The one with which I am most closely involved is `groff' -- the current CVS, from savannah.gnu.org, builds OOTB when `prefix' is correctly defined, although there are some additional dependencies beyond MSYS and MinGW, which I have satisfied with packages from the GnuWin32 project, http://sourceforge.net/projects/gnuwin32/, and GhostScript from http://www.ghostscript.com/ Best regards, Keith. |
From: Keith M. <kei...@to...> - 2005-04-08 15:50:39
|
Stepan Kasal wrote: > Keith Marshall wrote: >> ac_default_prefix=`exec 2>/dev/null;cd /usr/local&&pwd -W` ||\ >> ac_default_prefix=/usr/local > > This is a possible solution, but I'd like to propose something simpler: > > AC_INIT reads file config.site at its initialization file. > So if the MSYS install process ensures that /usr/local/share/config.site > is present and assigns ac_default_prefix, then everything should work. > > I hope this solution is acceptable to you. I confess that I hadn't considered the possibility of using config.site to override the `ac_default_prefix=/usr/local' set by AC_INIT. It does look like an elegant solution, subject to a couple of caveats: 1) If a user has created a customised config.site, he needs to be careful not to clobber it with an MSYS upgrade. 2) If a configure.ac script uses AC_PREFIX_DEFAULT or AC_PREFIX_PROGRAM, that will override the effect of the config.site initialisation, probably resulting in an invalid prefix assignment for the MSYS/MinGW build, since these would normally specify POSIX paths. Of course, the second of these problems is not addressed by the simple patch I proposed either. Could this also be handled by config.site, or will it be necessary to modify the definitions of AC_PREFIX_DEFAULT and AC_PREFIX_PROGRAM to achieve my desired effect? I have explored this a bit further, and could work up an RFC for a simple patch, if you think it worth pursuing. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-03-29 14:54:27
|
<quote who="Keith MARSHALL"> > > Your idea of handling it from MSYS itself seems attractive, but > I'm curious as to how you would ensure that every reference to > ${prefix}, throughout the build process, was correctly mapped. > Wouldn't this require some degree of co-operation from the > `configure' script itself? How would such co-operation be > obtained, when you don't have control of the content of the > `configure' script? How would you handle the case where the > user doesn't specify `--prefix', (which is addressed by my > original MSYS_PREFIX_HACK)? Perhaps an MSYS specific, but > package agnostic, wrapper for `configure' would do the trick; > the disadvantage would be a minor departure from the normal > GNU `./configure && make && make install' build procedure. > So, rather than --prefix being the key, what really needs to happen is the value of the variable prefix always needs to contain a windows path. Perhaps others as well. Then when the configure script creates the Makefile the correct values are in place. > Sorry: I don't mean to seem negative here; just playing > devil's advocate, in the hope of promoting further constructive > discussion. > Discussion is good, no need to apologize. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |