mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Guy Gascoigne-Piggford wrote:

> Ah, but I was using the msys make and got the same problem.
>
> Guy

So what's the story with make --win32? I've seen a couple posts on 
cygwin-related lists about this but nothing very clear. Seems it is run 
in a DOS shell, and interprets all \ as backslash rather than escape 
characters, but I'm surprised it would work at all for 
automake-generated makefiles.

Oliver

Ah, but I was using the msys make and got the same problem.

Guy

Earnie Boyd wrote:

>Posted on DATE by AUTHOR Lennart Borgman
>  
>
>>----- Original Message -----
>>From: "Oliver Schoenborn" <oli...@ut...>
>>
>>
>>Thanks, but I am using GNU Make 3.80 from http://gnuwin32.sourceforge.net/
>>and it does not support the switch --win32. This is the advice I have got.
>>What make are you using?
>>
>>    
>>
>
>Then this is the wrong list for this discussion.  When using MSYS you must
>use the tools supplied by MSYS for support on this list.  There are
>reasons I supply a msys-1.0.dll dependent make.  If you choose not to use
>it then you are on your own in dealing with the problems.  IIRC, a similar
>statement is in the MSYS README file.
>
>Earnie
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Mingw-msys mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>.
>
>  
>

Posted on DATE by AUTHOR Lennart Borgman
> ----- Original Message -----
> From: "Oliver Schoenborn" <oli...@ut...>
>
>
> Thanks, but I am using GNU Make 3.80 from http://gnuwin32.sourceforge.net/
> and it does not support the switch --win32. This is the advice I have got.
> What make are you using?
>

Then this is the wrong list for this discussion.  When using MSYS you must
use the tools supplied by MSYS for support on this list.  There are
reasons I supply a msys-1.0.dll dependent make.  If you choose not to use
it then you are on your own in dealing with the problems.  IIRC, a similar
statement is in the MSYS README file.

Earnie

----- Original Message ----- 
From: "Oliver Schoenborn" <oli...@ut...>

: >I have put up a summary of the problems I have seen so far that occurs
when
: >using MSYS to build Emacs:
: >http://www.emacswiki.org/cgi-bin/wiki/BuildingCvsWThirtyTwoMingw - search
: >for MSYS on this page.
: >
: >
: I missed the beginning of the this thread and took only a very quick
: look at the above page, but have you tried the --win32 switch to make?
: I.e., "make --win32"? This seems to execute in some sort of DOS mode, I
: don't fully understand it but it has worked for me a number of times
: when I had problems with slashes and spaces. .

Thanks, but I am using GNU Make 3.80 from http://gnuwin32.sourceforge.net/
and it does not support the switch --win32. This is the advice I have got.
What make are you using?

- Lennart

Lennart Borgman wrote:

>I have put up a summary of the problems I have seen so far that occurs when
>using MSYS to build Emacs:
>http://www.emacswiki.org/cgi-bin/wiki/BuildingCvsWThirtyTwoMingw - search
>for MSYS on this page.
>  
>
I missed the beginning of the this thread and took only a very quick 
look at the above page, but have you tried the --win32 switch to make? 
I.e., "make --win32"? This seems to execute in some sort of DOS mode, I 
don't fully understand it but it has worked for me a number of times 
when I had problems with slashes and spaces. .

Oliver

I could not get that solution to work with the makefile for Emacs. It would
be much better if MSYS sh recognized the PATHEXT file extensions and handled
them. Cygwin does this and doing the same for MSYS would make the
differences smaller and easier to handle.

Are you familiar with PATHEXT?

- Lennart


----- Original Message ----- 
From: "Earnie Boyd" <ea...@us...>
To: <min...@li...>
Sent: Wednesday, October 27, 2004 2:57 PM
Subject: Re: [Mingw-msys] MSYS sh does not handle .bat files


: Posted on DATE by AUTHOR Lennart Borgman
: > Thanks Kevin, but unfortunately that does not seem to do what I want. I
get
: > a new cmd.exe in a new window, it does not wait, I have problems passing
: parameters etc.
:
: Does ``cmd //c foo.bat'' work the way you want?
:
: Earnie

Well I tried with both the 1.0.11-2004.04.30 snapshot as well as the 
vanilla 1.0 version.  Both of them cause an error to be logged when 
building bootstrap.

Guy

Earnie Boyd wrote:

>Posted on DATE by AUTHOR Guy Gascoigne - Piggford
>  
>
>>True, but part of the problem is that if you try to build from within
>>Msys, it actually looks like it's working, only to break in an obscure
>>way after having got off to a good start.
>>
>>If it just didn't work in the first place it might have been less
>>confusing. :)
>>
>>Guy
>>
>>    
>>
>
>Guy,
>
>I'm in favor of finding a solution.  I will take a look at the emacs build
>process see how the path translation can be modified.  Which version of
>MSYS are you using?  Sorry if you've given that information before.
>
>  
>
>>Fred Kunz wrote:
>>
>>    
>>
>>>Without either arguing for or against a path conversion option, it might
>>>be appropriate to point out that there are two easy ways to build emacs
>>>on Windows without either CYGWIN or MSYS. One is to use Visual C++
>>>environment with some GNUWin32 modules and the other is to use a MinGW
>>>environment with some GNUWin32 modules and configure and build from the
>>>emacs\nt directory. This includes the current CVS tree with image
>>>support.
>>>
>>>      
>>>
>
>Fred,
>
>Are you saying that there is a special build method for MinGW beyond
>configure && make?  I don't like that method as it causes someone to have
>to make changes when the package structure changes.  I very much like the
>automated features of the auto tool set of modules.  Please encourage its
>use for MinGW builds as well.
>
>Earnie
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Mingw-msys mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>
>
>  
>

I have put up a summary of the problems I have seen so far that occurs when
using MSYS to build Emacs:
http://www.emacswiki.org/cgi-bin/wiki/BuildingCvsWThirtyTwoMingw - search
for MSYS on this page.

Earnie, did you get my messages about possible ways to correct these
problems? (High level suggestions only, sorry no source code ;-)

I would be really glad to get this working.

- Lennart


----- Original Message ----- 
From: "Earnie Boyd" <ea...@us...>
To: <min...@li...>
Sent: Wednesday, October 27, 2004 2:56 PM
Subject: Re: [Mingw-msys] Path conversion is not always good - please supply
a way to turn it off!


: Posted on DATE by AUTHOR Guy Gascoigne - Piggford
: > True, but part of the problem is that if you try to build from within
: > Msys, it actually looks like it's working, only to break in an obscure
: > way after having got off to a good start.
: >
: > If it just didn't work in the first place it might have been less
: > confusing. :)
: >
: > Guy
: >
:
: Guy,
:
: I'm in favor of finding a solution.  I will take a look at the emacs build
: process see how the path translation can be modified.  Which version of
: MSYS are you using?  Sorry if you've given that information before.
:
: > Fred Kunz wrote:
: >
: >>Without either arguing for or against a path conversion option, it might
: >>be appropriate to point out that there are two easy ways to build emacs
: >>on Windows without either CYGWIN or MSYS. One is to use Visual C++
: >>environment with some GNUWin32 modules and the other is to use a MinGW
: >>environment with some GNUWin32 modules and configure and build from the
: >>emacs\nt directory. This includes the current CVS tree with image
: >>support.
: >>
:
: Fred,
:
: Are you saying that there is a special build method for MinGW beyond
: configure && make?  I don't like that method as it causes someone to have
: to make changes when the package structure changes.  I very much like the
: automated features of the auto tool set of modules.  Please encourage its
: use for MinGW builds as well.
:
: Earnie
:
:
:
: -------------------------------------------------------
: This SF.Net email is sponsored by:
: Sybase ASE Linux Express Edition - download now for FREE
: LinuxWorld Reader's Choice Award Winner for best database on Linux.
: http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
: _______________________________________________
: Mingw-msys mailing list
: Min...@li...
: https://lists.sourceforge.net/lists/listinfo/mingw-msys
:

Posted on DATE by AUTHOR Lennart Borgman
> Thanks Kevin, but unfortunately that does not seem to do what I want. I get
> a new cmd.exe in a new window, it does not wait, I have problems passing
parameters etc.

Does ``cmd //c foo.bat'' work the way you want?

Earnie

Posted on DATE by AUTHOR Guy Gascoigne - Piggford
> True, but part of the problem is that if you try to build from within
> Msys, it actually looks like it's working, only to break in an obscure
> way after having got off to a good start.
>
> If it just didn't work in the first place it might have been less
> confusing. :)
>
> Guy
>

Guy,

I'm in favor of finding a solution.  I will take a look at the emacs build
process see how the path translation can be modified.  Which version of
MSYS are you using?  Sorry if you've given that information before.

> Fred Kunz wrote:
>
>>Without either arguing for or against a path conversion option, it might
>>be appropriate to point out that there are two easy ways to build emacs
>>on Windows without either CYGWIN or MSYS. One is to use Visual C++
>>environment with some GNUWin32 modules and the other is to use a MinGW
>>environment with some GNUWin32 modules and configure and build from the
>>emacs\nt directory. This includes the current CVS tree with image
>>support.
>>

Fred,

Are you saying that there is a special build method for MinGW beyond
configure && make?  I don't like that method as it causes someone to have
to make changes when the package structure changes.  I very much like the
automated features of the auto tool set of modules.  Please encourage its
use for MinGW builds as well.

Earnie

True, but part of the problem is that if you try to build from within 
Msys, it actually looks like it's working, only to break in an obscure 
way after having got off to a good start.

If it just didn't work in the first place it might have been less 
confusing. :)

Guy

Fred Kunz wrote:

>Without either arguing for or against a path conversion option, it might
>be appropriate to point out that there are two easy ways to build emacs
>on Windows without either CYGWIN or MSYS. One is to use Visual C++
>environment with some GNUWin32 modules and the other is to use a MinGW
>environment with some GNUWin32 modules and configure and build from the
>emacs\nt directory. This includes the current CVS tree with image
>support.
>
>
>
>-----Original Message-----
>From: Lennart Borgman [mailto:len...@st...] 
>Sent: Monday, October 25, 2004 9:14 AM
>To: min...@li...
>Subject: [Mingw-msys] Path conversion is not always good - please supply
>a way to turn it off!
>
>I am new here on this list. I have some suggestions, because I think
>MSYS is
>a good initiative and I want to make it more useful.
>
>The documentation says that Posix paths are converted to Win32 paths.
>This
>is maybe not entirely correct since in a command like the one below the
>paths are converted:
>
>"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l
>autoload \
>    --eval '(setq find-file-hooks nil \
>        find-file-suppress-same-file-warnings t \
>        generated-autoload-file \
>          "c:/dev/emacs-src/emacs/lisp/loaddefs.el")'
>
>I would expect that /c/dev/emacs-src/emacs/lisp/loaddefs.el should be
>converted, but not the one above.
>
>Anyway this is not the real problem here. The problem is that the paths
>are
>converted at all since this gives incorrect parameters to Emacs.
>"c:\dev\emacs-src\emacs\lisp\loaddefs.el" is from Emacs standpoint just
>a
>string with some escaped characters. It will evaluate to something like
>"C:Devmsys.0evacs-srcacslisploaddefs.el".
>
>I would suggest some way to turn this feature off for all programs or
>for
>certain programs. As it works now MSYS sh does not work with Emacs. I
>think
>it would be very good if it did. It could then be an easy to use build
>environment for Emacs on MS Windows (which I believe would be
>appreciated by
>many people).
>
>Actually I do not know which programs needs backslashes in the paths
>today?
>
>Kind regards,
>Lennart
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give
>us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
>more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Mingw-msys mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Mingw-msys mailing list
>Min...@li...
>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>
>
>  
>

Without either arguing for or against a path conversion option, it might
be appropriate to point out that there are two easy ways to build emacs
on Windows without either CYGWIN or MSYS. One is to use Visual C++
environment with some GNUWin32 modules and the other is to use a MinGW
environment with some GNUWin32 modules and configure and build from the
emacs\nt directory. This includes the current CVS tree with image
support.



-----Original Message-----
From: Lennart Borgman [mailto:len...@st...]=20
Sent: Monday, October 25, 2004 9:14 AM
To: min...@li...
Subject: [Mingw-msys] Path conversion is not always good - please supply
a way to turn it off!

I am new here on this list. I have some suggestions, because I think
MSYS is
a good initiative and I want to make it more useful.

The documentation says that Posix paths are converted to Win32 paths.
This
is maybe not entirely correct since in a command like the one below the
paths are converted:

"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l
autoload \
    --eval '(setq find-file-hooks nil \
        find-file-suppress-same-file-warnings t \
        generated-autoload-file \
          "c:/dev/emacs-src/emacs/lisp/loaddefs.el")'

I would expect that /c/dev/emacs-src/emacs/lisp/loaddefs.el should be
converted, but not the one above.

Anyway this is not the real problem here. The problem is that the paths
are
converted at all since this gives incorrect parameters to Emacs.
"c:\dev\emacs-src\emacs\lisp\loaddefs.el" is from Emacs standpoint just
a
string with some escaped characters. It will evaluate to something like
"C:Devmsys.0evacs-srcacslisploaddefs.el".

I would suggest some way to turn this feature off for all programs or
for
certain programs. As it works now MSYS sh does not work with Emacs. I
think
it would be very good if it did. It could then be an easy to use build
environment for Emacs on MS Windows (which I believe would be
appreciated by
many people).

Actually I do not know which programs needs backslashes in the paths
today?

Kind regards,
Lennart



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Mingw-msys mailing list
Min...@li...
https://lists.sourceforge.net/lists/listinfo/mingw-msys

And I am commenting myself here, sorry for the noice ;-)

I forgot the case with absolute POSIX style file names, like
/c/dir/file.txt - these must of course be converted. Would it not be enough
to convert those file names when the file name are the whole of an argument
in sh parsing syntax?

- Lennart


----- Original Message ----- 
From: "Lennart Borgman" <len...@st...>
To: <min...@li...>
Sent: Monday, October 25, 2004 6:14 PM
Subject: [Mingw-msys] Path conversion is not always good - please supply a
way to turn it off!


: I am new here on this list. I have some suggestions, because I think MSYS
is
: a good initiative and I want to make it more useful.
:
: The documentation says that Posix paths are converted to Win32 paths. This
: is maybe not entirely correct since in a command like the one below the
: paths are converted:
:
: "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l
: autoload \
:     --eval '(setq find-file-hooks nil \
:         find-file-suppress-same-file-warnings t \
:         generated-autoload-file \
:           "c:/dev/emacs-src/emacs/lisp/loaddefs.el")'
:
: I would expect that /c/dev/emacs-src/emacs/lisp/loaddefs.el should be
: converted, but not the one above.
:
: Anyway this is not the real problem here. The problem is that the paths
are
: converted at all since this gives incorrect parameters to Emacs.
: "c:\dev\emacs-src\emacs\lisp\loaddefs.el" is from Emacs standpoint just a
: string with some escaped characters. It will evaluate to something like
: "C:Devmsys.0evacs-srcacslisploaddefs.el".
:
: I would suggest some way to turn this feature off for all programs or for
: certain programs. As it works now MSYS sh does not work with Emacs. I
think
: it would be very good if it did. It could then be an easy to use build
: environment for Emacs on MS Windows (which I believe would be appreciated
by
: many people).
:
: Actually I do not know which programs needs backslashes in the paths
today?
:
: Kind regards,
: Lennart
:
:
:
: -------------------------------------------------------
: This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
: Use IT products in your business? Tell us what you think of them. Give us
: Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
: http://productguide.itmanagersjournal.com/guidepromo.tmpl
: _______________________________________________
: Mingw-msys mailing list
: Min...@li...
: https://lists.sourceforge.net/lists/listinfo/mingw-msys
:

Thanks Kevin, but unfortunately that does not seem to do what I want. I get
a new cmd.exe in a new window, it does not wait, I have problems passing
parameters etc.

- Lennart

----- Original Message ----- 
From: "Kevin Mack" <kev...@us...>
To: <min...@li...>
Sent: Monday, October 25, 2004 6:39 PM
Subject: Re: [Mingw-msys] MSYS sh does not handle .bat files


: well, you can kind of work around this by doing
:
: "start abc.bat" or "start abc" and the MSYS sh will execute the .bat
: file...not as convenient as being able to fire it off directly, but
: works good enough for me
:
: Kevin
:
: --
:
: Lennart Borgman wrote:
: > If I enter the name of a .bat-file from the MSYS sh prompt it is handles
as
: > if it was a sh script. That is not very reasonable.
: >
: > Would it not be good if MSYS sh handled the list of extension in the
PATHEXT
: > variable correctly? (PATHEXT is by default something like
: > PATHEXT=.COM;.EXE;.BAT;.CMD)
: >
: > This would mean for example that if I had a bat file named
MY-CMD-FILE.CMD
: > and entered MY-CMD-FILE then sh would start cmd.exe to run
MY-CMD-FILE.CMD.
: >
: > I do believe that such a change would make it much easier for someone
used
: > to the MS Windows shell (cmd.exe) to switch to using MSYS sh.
: >
: > Beside this there is currently an issue with the build script of Emacs
where
: > a .bat-file is called for the NT build. This fails with MSYS sh but
works
: > correctly with Cygwin sh.
: >
: > I would prefer to use MSYS here if it is possible (because it is much
: > smaller and I do not need the other functionality of Cygwin). I do
however
: > believe that many people use Cygwin instead because of issues like this.
: >
: > Kind regards,
: > Lennart
: >
: >
: >
: >
: >
: > -------------------------------------------------------
: > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
: > Use IT products in your business? Tell us what you think of them. Give
us
: > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
: > http://productguide.itmanagersjournal.com/guidepromo.tmpl
: > _______________________________________________
: > Mingw-msys mailing list
: > Min...@li...
: > https://lists.sourceforge.net/lists/listinfo/mingw-msys
: >
: >
:
:
:
:
: -------------------------------------------------------
: This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
: Use IT products in your business? Tell us what you think of them. Give us
: Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
: http://productguide.itmanagersjournal.com/guidepromo.tmpl
: _______________________________________________
: Mingw-msys mailing list
: Min...@li...
: https://lists.sourceforge.net/lists/listinfo/mingw-msys
:

well, you can kind of work around this by doing

"start abc.bat" or "start abc" and the MSYS sh will execute the .bat 
file...not as convenient as being able to fire it off directly, but 
works good enough for me

Kevin

--

Lennart Borgman wrote:
> If I enter the name of a .bat-file from the MSYS sh prompt it is handles as
> if it was a sh script. That is not very reasonable.
> 
> Would it not be good if MSYS sh handled the list of extension in the PATHEXT
> variable correctly? (PATHEXT is by default something like
> PATHEXT=.COM;.EXE;.BAT;.CMD)
> 
> This would mean for example that if I had a bat file named MY-CMD-FILE.CMD
> and entered MY-CMD-FILE then sh would start cmd.exe to run MY-CMD-FILE.CMD.
> 
> I do believe that such a change would make it much easier for someone used
> to the MS Windows shell (cmd.exe) to switch to using MSYS sh.
> 
> Beside this there is currently an issue with the build script of Emacs where
> a .bat-file is called for the NT build. This fails with MSYS sh but works
> correctly with Cygwin sh.
> 
> I would prefer to use MSYS here if it is possible (because it is much
> smaller and I do not need the other functionality of Cygwin). I do however
> believe that many people use Cygwin instead because of issues like this.
> 
> Kind regards,
> Lennart
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 
> 

I did have problems building Emacs Info with MSYS because makeinfo from MSYS
did not work as expected. I then switched to using MSYS sh but with makeinfo
replaced with the one available from http://gnuwin32.sourceforge.net/
(makeinfo is part of TexInfo).

I first believed that makeinfo 4.3 from MSYS was too old, but that does not
seem to be the case (makeinfo from Gnuwin32 is 4.6).

Instead after discussing this with some other people (especially Kees
Zeelenberg on Gnuwin32) it turned out to be a problem with CR-LF conversion.
Kees wrote:

> The problem with CR-LF is not a bug of TeXinfo, but a characteristic of
the
> runtime library. Djgpp, Cygwin and Msys use their own runtime libraries,
> Gnuwin32 uses the native runtime one (msvcrt.dll). The Djgpp, Cygwin and
> native runtimes handle CR-LF files transparently by converting CR-LF into
LF
> (upon reading) and vice versa (upon writing). Apparently, the Msys runtime
> does not do such a conversion, or at least has problems with it.

Could not the version of makeinfo from MSYS do it the same way? The version
from Gnuwin32 seems to work perfect with MSYS (and is compiled with MinGW).

Kind regards,
Lennart

If I enter the name of a .bat-file from the MSYS sh prompt it is handles as
if it was a sh script. That is not very reasonable.

Would it not be good if MSYS sh handled the list of extension in the PATHEXT
variable correctly? (PATHEXT is by default something like
PATHEXT=.COM;.EXE;.BAT;.CMD)

This would mean for example that if I had a bat file named MY-CMD-FILE.CMD
and entered MY-CMD-FILE then sh would start cmd.exe to run MY-CMD-FILE.CMD.

I do believe that such a change would make it much easier for someone used
to the MS Windows shell (cmd.exe) to switch to using MSYS sh.

Beside this there is currently an issue with the build script of Emacs where
a .bat-file is called for the NT build. This fails with MSYS sh but works
correctly with Cygwin sh.

I would prefer to use MSYS here if it is possible (because it is much
smaller and I do not need the other functionality of Cygwin). I do however
believe that many people use Cygwin instead because of issues like this.

Kind regards,
Lennart

I am new here on this list. I have some suggestions, because I think MSYS is
a good initiative and I want to make it more useful.

The documentation says that Posix paths are converted to Win32 paths. This
is maybe not entirely correct since in a command like the one below the
paths are converted:

"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l
autoload \
    --eval '(setq find-file-hooks nil \
        find-file-suppress-same-file-warnings t \
        generated-autoload-file \
          "c:/dev/emacs-src/emacs/lisp/loaddefs.el")'

I would expect that /c/dev/emacs-src/emacs/lisp/loaddefs.el should be
converted, but not the one above.

Anyway this is not the real problem here. The problem is that the paths are
converted at all since this gives incorrect parameters to Emacs.
"c:\dev\emacs-src\emacs\lisp\loaddefs.el" is from Emacs standpoint just a
string with some escaped characters. It will evaluate to something like
"C:Devmsys.0evacs-srcacslisploaddefs.el".

I would suggest some way to turn this feature off for all programs or for
certain programs. As it works now MSYS sh does not work with Emacs. I think
it would be very good if it did. It could then be an easy to use build
environment for Emacs on MS Windows (which I believe would be appreciated by
many people).

Actually I do not know which programs needs backslashes in the paths today?

Kind regards,
Lennart

Earnie wrote:

>P.S.: Don't forget to distribute the source for the msys dll and any
>utilities that may depend on it.  The dll is covered by the GPL and will
>infect any code to that uses it to also be covered by the GPL.  If the
>license of your utilities that depend on the msys-1.0.dll are incompatible
>with the GPL then you have unresolvable issues.
>  
>

Actually, the dll is only necessary to support those parts of our 
toolchain which are windows unfriendly such as the shell, gdb, compiler, 
binutils, etc.   Those are all GPL already so there's no problem.  We'd 
been using Cygwin up until now but are migrating to MingW to get better 
path support.  Thanks for the help Earnie.

cheers,

Kris

> Earnie Boyd wrote:
>> I just remembered another item, the msys-1.0.dll will expect to find a
directory named etc in its parent directory.  So if you have the
msys-1.0.dll in a directory tree of c:\foo\bin then c:\foo\etc must
exist.
>> Well, checking the code, I'm not sure if that is exactly correct so YMMV.
> Aha!  Good catch.  I tried creating an etc dir in the same dir as the
msys dll which didn't work.  Then I though about it and put it where the
>   filesystem was rooted (c:\ in this case) and that did the trick.  For
> our purposes, we can't create a c:\etc in our install but I guess we can
make the registry entries to root it elsewhere in our SDK.
> Thanks for the help Earnie.

I'm glad it was that easy.  There's a thread that watches for changes to
the /etc directory so that it can reinitialize the mount table for changes
to /etc/fstab.  My guess is it is that code which caused the problem
within one of the system dll's.

Earnie

P.S.: Don't forget to distribute the source for the msys dll and any
utilities that may depend on it.  The dll is covered by the GPL and will
infect any code to that uses it to also be covered by the GPL.  If the
license of your utilities that depend on the msys-1.0.dll are incompatible
with the GPL then you have unresolvable issues.

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Earnie Boyd wrote:
> I just remembered another item, the msys-1.0.dll will expect to find a 
> directory named etc in its parent directory.  So if you have the 
> msys-1.0.dll in a directory tree of c:\foo\bin then c:\foo\etc must exist.
> 
> Well, checking the code, I'm not sure if that is exactly correct so YMMV.

Aha!  Good catch.  I tried creating an etc dir in the same dir as the 
msys dll which didn't work.  Then I though about it and put it where the 
  filesystem was rooted (c:\ in this case) and that did the trick.  For 
our purposes, we can't create a c:\etc in our install but I guess we can 
make the registry entries to root it elsewhere in our SDK.

Thanks for the help Earnie.

cheers,

Kris

Hmm.  I didn't but in this case,  the problem is showing up on two 
identical machines, one which has mingw installed, one which doesn't.  
I've been looking at some strace output and it looks like there might be 
some sort of issue with the msys dll.  Here's a funny thing we 
observed:  If you do a 'chmod +x' of msys-1.0.dll from the cygwin 
prompt, the behaviour changes.  Instead of getting a popup with the App 
failed to init error, the application just fails silently.

I'm going to play around with depends and see if I can figure something out.

cheers,

Kris

Earnie Boyd wrote:

> Nothing special required.  No registry entries or background 
> processes.  Perhaps you can get more info from profiling with the 
> Depends tool.
>
> The memory location doesn't match one for the msys-1.0.dll.  Did you 
> specify a -march value when you built your application?
>
> Earnie
>
> Kris Warkentin wrote:
>
>> When I build a shell such as ksh or bash using msys-dvlpr, it runs 
>> fine on my machine as long as it can find the msys-1.0.dll.  If, 
>> however, I copy the binary and dll to another windows machine, I get 
>> an "Application failed to initialize properly 0xc0000022".
>>
>> Any ideas?  I was wondering if there's some registry key or 
>> environment variable or background service that needs to be running.
>>
>> cheers,
>>
>> Kris
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. 
>> Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>> out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Mingw-msys mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>>
>>
>>
>

I don't know if it will work, but you could try getting the termcap library
from here:

http://sourceforge.net/projects/gnuwin32/

Luke

----- Original Message ----- 
From: "John David Ratliff" <jdr...@in...>
To: <min...@li...>
Sent: Tuesday, October 19, 2004 12:49 AM
Subject: [Mingw-msys] compiling nano in msys


> I would like to use nano in msys, but I can't seem to compile it.
>
> I have posted my configure output at
> http://www.technoplaza.net/mingw/configure.log and my make output at
> http://www.technoplaza.net/mingw/make.log
>
> Configure suggests installing ncurses because I have no termcap lib. But I
> was also unable to compile ncurses.
>
> I installed pdcurses and libiconv, but that didn't help.
>
> Anyone know if nano can be compiled in mingw/msys and if so, how?
>
> I'm using mingw 3.1.0 with mingw-runtime 3.5 and gcc/g++ 3.4.2. I have
msys
> 1.0.11.
>
> Thanks,
>
> --John Ratliff
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

I just remembered another item, the msys-1.0.dll will expect to find a 
directory named etc in its parent directory.  So if you have the 
msys-1.0.dll in a directory tree of c:\foo\bin then c:\foo\etc must exist.

Well, checking the code, I'm not sure if that is exactly correct so YMMV.

Earnie

Earnie Boyd wrote:

> Nothing special required.  No registry entries or background 
> processes.  Perhaps you can get more info from profiling with the 
> Depends tool.
>
> The memory location doesn't match one for the msys-1.0.dll.  Did you 
> specify a -march value when you built your application?
>
> Earnie
>
> Kris Warkentin wrote:
>
>> When I build a shell such as ksh or bash using msys-dvlpr, it runs 
>> fine on my machine as long as it can find the msys-1.0.dll.  If, 
>> however, I copy the binary and dll to another windows machine, I get 
>> an "Application failed to initialize properly 0xc0000022".
>>
>> Any ideas?  I was wondering if there's some registry key or 
>> environment variable or background service that needs to be running.
>>
>> cheers,
>>
>> Kris
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. 
>> Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>> out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Mingw-msys mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>>
>>
>>
>

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Nothing special required.  No registry entries or background processes.  
Perhaps you can get more info from profiling with the Depends tool.

The memory location doesn't match one for the msys-1.0.dll.  Did you 
specify a -march value when you built your application?

Earnie

Kris Warkentin wrote:

> When I build a shell such as ksh or bash using msys-dvlpr, it runs 
> fine on my machine as long as it can find the msys-1.0.dll.  If, 
> however, I copy the binary and dll to another windows machine, I get 
> an "Application failed to initialize properly 0xc0000022".
>
> Any ideas?  I was wondering if there's some registry key or 
> environment variable or background service that needs to be running.
>
> cheers,
>
> Kris
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>
>

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438