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

je...@in... wrote:
> 
> Hi there all
> 
> I've downloaded and installed the new msysDTK-1.0.0-alpha.

Alpha package bug, it should not contain the include file or libraries. 
These libraries are dependent on msys-1.0.dll.

> One of the directories it provides is ./include, which contains
> amoungst other things, blowfish.h
> 
> I untared the pakaged and moved in into my msys root at /msys/1.0.8/,
> so that eg blowfish.h is now located at /include/openssl.blowfish.h
> 
> My pain is that, even with a configure --includedir=/include I still
> get a failure when autoconf tries to look for openssl/blowfish.h
> 
> Is there some part of the installation that I missed?
> 

You are trying to mix environments.  You're using a MINGW32 environment,
see the title bar heading, it says MINGW32.  It is an msysDTK because
the binaries are dependent on the MSYS dll.  And you are trying to build
a package for the MINGW32 environment which can't use libraries
dependent on the MSYS dll.  I haven't tried configure OpenSSL in the
MINGW32 environment but I suppose it to be possible.  You will need a
Win32 version of Perl to do that.

Ok, your next logical question will be, how can I use these already
built msys dll dependent libraries?  Obviously you need to switch to an
MSYS environment.  Get the msysDVLPR alpha package, read the msysDVLPR
documentation in /doc/msys, execute the instructions, and you should be
able to use the libraries.

Earnie.

Hi there all

I've downloaded and installed the new msysDTK-1.0.0-alpha.
One of the directories it provides is ./include, which contains
amoungst other things, blowfish.h

I untared the pakaged and moved in into my msys root at /msys/1.0.8/, 
so that eg blowfish.h is now located at /include/openssl.blowfish.h

My pain is that, even with a configure --includedir=/include I still
get a failure when autoconf tries to look for openssl/blowfish.h

Is there some part of the installation that I missed?

--
Jean le Roux

On Fri, 31 May 2002, Earnie Boyd wrote:
>
> Ok, I'll pull down a copy of ImageMagick and take a look, any particular
> version I should use?  I want MSYS to handle the conversions to the
> stored paths behind the scenes and not with you having to do anything
> special.  I'll make a decision about how to handle this in 10 to 14
> days.

The latest beta available as
ftp://ftp.simplesystems.org/pub/ImageMagick/beta/ImageMagick-5.4.6.tar.gz
is the best choice.  It should at least configure and compile using
MSYS.

I don't see how MSYS could possibly know if a path is being stored,
and whether it should be in POSIX or Windows format.  Paths stored in
POSIX format are to support building and installing, while paths
stored in Windows format are for use by the software which is built.

ImageMagick's configure uses standard Autoconf macros to store string
data so perhaps there is some hope.  The support could go into the
standard Autoconf distribution so that popular software would be able
to use it in a few years.

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen

Bob Friesenhahn wrote:
> 
> On Fri, 31 May 2002, Earnie Boyd wrote:
> > >
> > > Cygpath's --windir output is also quite useful for me since my package
> > > (ImageMagick) must locate certain files (font files) in the Windows
> > > installation directory.
> >
> > I want to avoid this at all costs.  This is trickery that you shouldn't
> > need to do.
> 
> Perhaps we shouldn't, but since ImageMagick uses FreeType to render
> fonts directly rather than using the non-portable MS-Windows APIs, our
> programs need to locate the TrueType font files.
> 
> > I plan for the next release to convert the environment much like the
> > argv conversion so that environment variables passed to non-MSYS
> > programs have the converted string.  Is this what you're needing?
> 
> Not at all.  Clearly you are not understanding what we need to do.
> The program is intended to run outside of MSYS/MinGW (isn't that what
> MinGW is all about?) so the built program can't depend on it.
> 

I do understand that all of your stored paths must be Win32 format.

> > > I have probably about 40 path strings that may require translation.
> >
> > You still haven't given me an example of what you're needing to do (in a
> > normal POSIX fashion).  What is it you're doing with the paths?  I
> > understand that you need the Win32 version of the path in the result.
> 
> Here is an example extracted from the configure script:
> 
> im_cv_x_coder_modules="${LIB_DIR}/ImageMagick/modules/coders/"
> MagickModulesPath="${im_cv_x_coder_modules}"
> if test "$native_win32_build" = 'yes' ; then
> # Convert to Windows path
>   MagickModulesPath=`echo "${MagickModulesPath}" | sed -e \
>                   's:^/::;s/./&:/;s:/:\\\\\\\\:g'`
> fi
> AC_DEFINE_UNQUOTED(MagickModulesPath,"$MagickModulesPath",
>                    Location of coder modules)
> 
> where LIB_DIR is something like "/usr/local/lib" or
> "/c/usr/local/lib".  The AC_DEFINE_UNQUOTED macro makes this
> definition available in ImageMagick's config.h file so that the string
> is embedded in ImageMagick binaries.
> 
> Besides embedding Windows paths into binaries, there are Windows paths
> to exernal programs and files embedded into configuration files.
> These paths are used by a native Windows program so they must appear
> as Windows paths rather than POSIX paths.
> 

Ok, I'll pull down a copy of ImageMagick and take a look, any particular
version I should use?  I want MSYS to handle the conversions to the
stored paths behind the scenes and not with you having to do anything
special.  I'll make a decision about how to handle this in 10 to 14
days.

Earnie.

He did mention that paths were embedded in the executable file, which is not
a simple problem to solve. You may remember that this came up before with
gcc, which passes literal paths on the compiler command line as preprocessor
macros (e.g. -DPREFIX=\"/usr/local\"). An earlier version of MSYS translated
this to -DPREFIX=\"c:\mingw\msys\1.0\local\" but this had to be disabled
because the backslashes are special in C string literals. For gcc the
hardcoded POSIX paths were not a problem because it is able to use relative
paths too. However the easier way to work around most of these problems was
to use Windows paths with forward slashes: --prefix=c:/mingw. If this is not
sufficient for the software in question, perhaps MSYS could be changed to
convert POSIX paths in these string literals to Windows paths with forward
slashes.

On the other hand, there are many other ways that the hardcoded paths could
be used: string literals in automatically generated source/header files,
configuration files (as was mentioned), generated shell scripts, etc. I seem
to remember that hardcoded POSIX paths in perl scripts prevented autoconf
from being built with MSYS (though there may have been other reasons too).

But I am only guessing because the specific problems have not been explained
yet...

Luke Dunstan

----- Original Message -----
From: "Earnie Boyd" <ear...@ya...>
To: "Bob Friesenhahn" <bfr...@si...>
Cc: "Earnie Boyd" <min...@li...>
Sent: Friday, May 31, 2002 10:59 PM
Subject: Re: [Mingw-msys] MSYS/MinGW --> Windows Path?


> Bob Friesenhahn wrote:
> >
> > On Fri, 31 May 2002, Earnie Boyd wrote:
> > >
> > > Since one of my goals for MSYS was to not have to muck with path
> > > translations I didn't provide such a utility.  I would like to
> > > understand your need so if you could provide a sample so that I can
> > > incorporate something into MSYS it sure would be appreciated.
> >
> > I would like to have a tool equivalent to Cygwin's cygpath available
> > (a MSYS port of cygpath would be great). My application is for use
> > within a package configure script in order to produce path strings
> > which are embedded in package configuration files, and within the
> > binaries themselves.
> >
> > For example
> >
> >   cygpath --windows /cygwin/c/windows
> >
> > prints
> >
> >   C:\cygwin\cygwin\c\windows
> >
> > Cygpath's --windir output is also quite useful for me since my package
> > (ImageMagick) must locate certain files (font files) in the Windows
> > installation directory.
> >
>
> I want to avoid this at all costs.  This is trickery that you shouldn't
> need to do.
>
> I plan for the next release to convert the environment much like the
> argv conversion so that environment variables passed to non-MSYS
> programs have the converted string.  Is this what you're needing?
>
> > > You can create a posix path to win32 path conversion utility simply by
> > > creating a binary that does nothing more than output it's argv array.
> > > As long as that binary doesn't exist in /bin or /usr/bin then MSYS
will
> > > do the path conversion for argv before executing the program.
> >
> > Good idea, but painful since normally programs compiled by Autoconf
> > configure scripts are removed as soon as the test is complete.  I
> > would prefer to minimize the changes to support MinGW vs Unix-like
> > platforms as much as possible.  There are already more special tweaks
> > than there should be.
> >
> > I have probably about 40 path strings that may require translation.
> >
>
> You still haven't given me an example of what you're needing to do (in a
> normal POSIX fashion).  What is it you're doing with the paths?  I
> understand that you need the Win32 version of the path in the result.
>
> Earnie.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

On Fri, 31 May 2002, Earnie Boyd wrote:
> >
> > Cygpath's --windir output is also quite useful for me since my package
> > (ImageMagick) must locate certain files (font files) in the Windows
> > installation directory.
>
> I want to avoid this at all costs.  This is trickery that you shouldn't
> need to do.

Perhaps we shouldn't, but since ImageMagick uses FreeType to render
fonts directly rather than using the non-portable MS-Windows APIs, our
programs need to locate the TrueType font files.

> I plan for the next release to convert the environment much like the
> argv conversion so that environment variables passed to non-MSYS
> programs have the converted string.  Is this what you're needing?

Not at all.  Clearly you are not understanding what we need to do.
The program is intended to run outside of MSYS/MinGW (isn't that what
MinGW is all about?) so the built program can't depend on it.

> > I have probably about 40 path strings that may require translation.
>
> You still haven't given me an example of what you're needing to do (in a
> normal POSIX fashion).  What is it you're doing with the paths?  I
> understand that you need the Win32 version of the path in the result.

Here is an example extracted from the configure script:

im_cv_x_coder_modules="${LIB_DIR}/ImageMagick/modules/coders/"
MagickModulesPath="${im_cv_x_coder_modules}"
if test "$native_win32_build" = 'yes' ; then
# Convert to Windows path
  MagickModulesPath=`echo "${MagickModulesPath}" | sed -e \
                  's:^/::;s/./&:/;s:/:\\\\\\\\:g'`
fi
AC_DEFINE_UNQUOTED(MagickModulesPath,"$MagickModulesPath",
                   Location of coder modules)

where LIB_DIR is something like "/usr/local/lib" or
"/c/usr/local/lib".  The AC_DEFINE_UNQUOTED macro makes this
definition available in ImageMagick's config.h file so that the string
is embedded in ImageMagick binaries.

Besides embedding Windows paths into binaries, there are Windows paths
to exernal programs and files embedded into configuration files.
These paths are used by a native Windows program so they must appear
as Windows paths rather than POSIX paths.

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen

Bob Friesenhahn wrote:
> 
> On Fri, 31 May 2002, Earnie Boyd wrote:
> >
> > Since one of my goals for MSYS was to not have to muck with path
> > translations I didn't provide such a utility.  I would like to
> > understand your need so if you could provide a sample so that I can
> > incorporate something into MSYS it sure would be appreciated.
> 
> I would like to have a tool equivalent to Cygwin's cygpath available
> (a MSYS port of cygpath would be great). My application is for use
> within a package configure script in order to produce path strings
> which are embedded in package configuration files, and within the
> binaries themselves.
> 
> For example
> 
>   cygpath --windows /cygwin/c/windows
> 
> prints
> 
>   C:\cygwin\cygwin\c\windows
> 
> Cygpath's --windir output is also quite useful for me since my package
> (ImageMagick) must locate certain files (font files) in the Windows
> installation directory.
> 

I want to avoid this at all costs.  This is trickery that you shouldn't
need to do.

I plan for the next release to convert the environment much like the
argv conversion so that environment variables passed to non-MSYS
programs have the converted string.  Is this what you're needing?

> > You can create a posix path to win32 path conversion utility simply by
> > creating a binary that does nothing more than output it's argv array.
> > As long as that binary doesn't exist in /bin or /usr/bin then MSYS will
> > do the path conversion for argv before executing the program.
> 
> Good idea, but painful since normally programs compiled by Autoconf
> configure scripts are removed as soon as the test is complete.  I
> would prefer to minimize the changes to support MinGW vs Unix-like
> platforms as much as possible.  There are already more special tweaks
> than there should be.
> 
> I have probably about 40 path strings that may require translation.
> 

You still haven't given me an example of what you're needing to do (in a
normal POSIX fashion).  What is it you're doing with the paths?  I
understand that you need the Win32 version of the path in the result.

Earnie.

On Fri, 31 May 2002, Earnie Boyd wrote:
>
> Since one of my goals for MSYS was to not have to muck with path
> translations I didn't provide such a utility.  I would like to
> understand your need so if you could provide a sample so that I can
> incorporate something into MSYS it sure would be appreciated.

I would like to have a tool equivalent to Cygwin's cygpath available
(a MSYS port of cygpath would be great). My application is for use
within a package configure script in order to produce path strings
which are embedded in package configuration files, and within the
binaries themselves.

For example

  cygpath --windows /cygwin/c/windows

prints

  C:\cygwin\cygwin\c\windows

Cygpath's --windir output is also quite useful for me since my package
(ImageMagick) must locate certain files (font files) in the Windows
installation directory.

> You can create a posix path to win32 path conversion utility simply by
> creating a binary that does nothing more than output it's argv array.
> As long as that binary doesn't exist in /bin or /usr/bin then MSYS will
> do the path conversion for argv before executing the program.

Good idea, but painful since normally programs compiled by Autoconf
configure scripts are removed as soon as the test is complete.  I
would prefer to minimize the changes to support MinGW vs Unix-like
platforms as much as possible.  There are already more special tweaks
than there should be.

I have probably about 40 path strings that may require translation.

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen

Bob Friesenhahn wrote:
> 
> Is there a reliable means to translate between the Unix-style path
> know to MSYS/MinGW and native Windows paths?  I am working to ensure
> that ImageMagick (http://www.imagemagick.org/) builds well using
> MinGW.  Since paths stored in configuration files and embedded in
> executables need to be expressed as Windows paths I need a reliable
> translation mechanism beyond 'sed'.
> 
> Cygwin provides a path translation utility.  Is there any such animal
> provided with MSYS/MinGW?
> 

Since one of my goals for MSYS was to not have to muck with path
translations I didn't provide such a utility.  I would like to
understand your need so if you could provide a sample so that I can
incorporate something into MSYS it sure would be appreciated.

You can create a posix path to win32 path conversion utility simply by
creating a binary that does nothing more than output it's argv array. 
As long as that binary doesn't exist in /bin or /usr/bin then MSYS will
do the path conversion for argv before executing the program.

Earnie.

Is there a reliable means to translate between the Unix-style path
know to MSYS/MinGW and native Windows paths?  I am working to ensure
that ImageMagick (http://www.imagemagick.org/) builds well using
MinGW.  Since paths stored in configuration files and embedded in
executables need to be expressed as Windows paths I need a reliable
translation mechanism beyond 'sed'.

Cygwin provides a path translation utility.  Is there any such animal
provided with MSYS/MinGW?

Thanks,

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen

On 30 May 2002 at 7:25, Earnie Boyd wrote:

> Allen Lake wrote:
> > 
> > I'm sure this minor problem has probably been raised before, but I got an
> > interesting question from a MinGW/MSYS newbie while trying to walk him
> > through setting everything up.

[snip]

> > This might help stop some of the problems being seen with setting the wrong
> > options in WinZip or other archive-handling programs during MinGW and MSYS
> > installs.
> > 
> 
> How would that stop the wrong options?  A .zip versus a .tar.gz just
> means that different methods were used to create the archives and .zip
> is much fatter than .tar.gz causing you to take longer in the download
> process and causing me to take longer in the upload process.  WinZip is
> a free download and understands .tar.gz format and comes with a nice GUI
> so you don't really need a windows version of tar and gzip.  If it
> (WinZip) understood .tar.bz2 format I would probably package with bzip2.
> 
> As far as the wrong options for WinZip, that's in the users hands, not
> the archivers hands.  And for users of Windows XP, it's in Microsoft's
> hands as the FileMenu will uncompress both zip and tar.gz for you
> without WinZip.  I haven't checked to see what it does with line
> endings.

	Well, can tell you, without doubt, since I did try out the XP pre-release (1&2), that XP automatically assigns 
the \r\n on decompression..."it's the Microsft Way..."  *ick*.

	Anyway, I ended up having to use Winzip to decompress some files that did not have the \r\n ending in order 
to get the stuff to decompress properly and had to go in and massage the registry so that XP would not 
autodecompress my downloaded .tar or  tar.gz archives.  Eventually I pulled the OS (personal opinion:  XP-Pro is 
poor excuse for Win2k, nothing more.).

	Paul G.

On 29 May 2002 at 6:59, Earnie Boyd wrote:

> "Paul G." wrote:
> > 
> > Is MSYS supposed to set usr/local/bin?
> > 
> 
> Yes.
> 
> > Just noticed that it does, and was not sure if it was what it was supposed to be doing...
> > 
> > I had thought that usr/bin was supposed to be where MSYS looked for .exe, etc., not usr/local/bin.  Can someone
> > clarify for me? (it looks like posixy standards, so am not sure).
> > 
> 
> MSYS is an aid to build programs with a MINGW32 host/build system.  The
> default configuration prefix is /usr/local so it makes sense to allocate
> that in the PATH.  The /usr/bin is reserved for binaries and scripts
> dependent on msys-1.0.dll.

	Okey, dokey.  Running into conflicts with something that appear to be directly related to usr/local/bin being 
defined.  Now I know that is the way things are "supposed to be".

	Thanks Earnie.

		Paul G.

The short answer is that you need to install MSYS after Mingw.

When you installed Mingw followed by MSYS the first time, it renamed
d:\mingw\bin\make.exe to d:\mingw\bin\mingw32-make.exe so that you could use
MSYS make by default (it tells you this when installing). Then when you
reinstalled Mingw, it created the old make.exe again. Mingw make does not
understand the MSYS paths, so you get these errors. If you had deleted or
renamed the Mingw make.exe after reinstalling, it would probably have
worked. In the future Mingw will be installed using a GUI too, so I guess it
will need to be set up to allow the two packages to be installed in either
order.

Luke Dunstan

----- Original Message -----
From: "Viktor Ransmayr" <vik...@t-...>
To: <min...@li...>
Sent: Thursday, May 30, 2002 10:20 PM
Subject: [Mingw-msys] Question of an MinGW/ MSYSY newcomer ...


>   I'm trying to build ACE using the MinGW-tools and the
> MSYS environment. Unfortunately I fail, which I've also
> reported to the ACE-User mailing-list. - But what puzzels
> me are a few things I've noticed during my work w/ MinGW
> and MSYS, which hopefully someone can explain to me.
>
> Here comes a detailed log of my activities.
>
> Host Machine and OS: i686-Laptop + Windows XP Pro
>
> I started out using the newest versions of everything
> (I know that wasn't to smart, but that's what I tried :-)
>
> At the last instance before I downgraded I used
>
> o MinGW-1.1
> o mingw-runtime-2.0-20020430
> o w32api-1.4-2
> o gcc-3_1-core-20020516-1
> o binutils-2_12_90-20020518-1
>
> and
>
> o MSYS-1.0.7-i686-2
>
> Since I didn't get any further I decided to start with
> the hopefully most stable versions of everything.
>
> I considered this to be MinGW-1.1 and MSYS-1.0.7-2
>
> Here now the detailed steps of how I "downgraded"...
>
> 1) I removed the previous MinGW-tools by simple
>     deleting the directory D:\MinGW\.
>
> !!! Note that I didn't make any modifications
> !!! to my MSYS-Environment nor my WinXP-Environment.
>
> 2) I installed the plain MinGW-1.1 package and verified
>     the installation w/ a simple C++-program on the
>     XP-CLI-prompt.
>
> 3) I tried to build ACE-5.2.1 and got the following
>     make.error.log:
>
> Makefile:307: /d/ACE_wrappers/include/makeinclude/wrapper_macros.GNU: No
> such file or directory
> Makefile:461: /d/ACE_wrappers/include/makeinclude/macros.GNU: No such
> file or directory
> Makefile:462: /d/ACE_wrappers/include/makeinclude/rules.common.GNU: No
> such file or directory
> Makefile:463: /d/ACE_wrappers/include/makeinclude/rules.nested.GNU: No
> such file or directory
> Makefile:464: /d/ACE_wrappers/include/makeinclude/rules.lib.GNU: No such
> file or directory
> Makefile:470: /d/ACE_wrappers/include/makeinclude/rules.local.GNU: No
> such file or directory
> D:\MinGW\bin\make.exe: *** No rule to make target
> `/d/ACE_wrappers/include/makeinclude/rules.local.GNU'.  Stop.
>
> 4) Since I am not working w/ Administrator-rights per default
>     I had to remove the MSYS-1.0.7-2 logged in as Administrator
>     as well as re-installing it again. ( via the menue
>     MinGW->MSYS->deinstall )
>
> 5) At this point the ACE-build-process suceeded much further ...
>
> Now my questions:
>
> Why did I have to re-install both MinGW and MSYS before
> the environment was "useable" again ? - Or where else was
> a mistake in my procedure ?
>
> Any explanation is appreciated.
>
> Kind regards,
>
> Viktor Ransmayr
>
>
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

  I'm trying to build ACE using the MinGW-tools and the
MSYS environment. Unfortunately I fail, which I've also
reported to the ACE-User mailing-list. - But what puzzels
me are a few things I've noticed during my work w/ MinGW
and MSYS, which hopefully someone can explain to me.

Here comes a detailed log of my activities.

Host Machine and OS: i686-Laptop + Windows XP Pro

I started out using the newest versions of everything
(I know that wasn't to smart, but that's what I tried :-)

At the last instance before I downgraded I used

o MinGW-1.1
o mingw-runtime-2.0-20020430
o w32api-1.4-2
o gcc-3_1-core-20020516-1
o binutils-2_12_90-20020518-1

and

o MSYS-1.0.7-i686-2

Since I didn't get any further I decided to start with
the hopefully most stable versions of everything.

I considered this to be MinGW-1.1 and MSYS-1.0.7-2

Here now the detailed steps of how I "downgraded"...

1) I removed the previous MinGW-tools by simple
    deleting the directory D:\MinGW\.

!!! Note that I didn't make any modifications
!!! to my MSYS-Environment nor my WinXP-Environment.

2) I installed the plain MinGW-1.1 package and verified
    the installation w/ a simple C++-program on the
    XP-CLI-prompt.

3) I tried to build ACE-5.2.1 and got the following
    make.error.log:

Makefile:307: /d/ACE_wrappers/include/makeinclude/wrapper_macros.GNU: No 
such file or directory
Makefile:461: /d/ACE_wrappers/include/makeinclude/macros.GNU: No such 
file or directory
Makefile:462: /d/ACE_wrappers/include/makeinclude/rules.common.GNU: No 
such file or directory
Makefile:463: /d/ACE_wrappers/include/makeinclude/rules.nested.GNU: No 
such file or directory
Makefile:464: /d/ACE_wrappers/include/makeinclude/rules.lib.GNU: No such 
file or directory
Makefile:470: /d/ACE_wrappers/include/makeinclude/rules.local.GNU: No 
such file or directory
D:\MinGW\bin\make.exe: *** No rule to make target 
`/d/ACE_wrappers/include/makeinclude/rules.local.GNU'.  Stop.

4) Since I am not working w/ Administrator-rights per default
    I had to remove the MSYS-1.0.7-2 logged in as Administrator
    as well as re-installing it again. ( via the menue
    MinGW->MSYS->deinstall )

5) At this point the ACE-build-process suceeded much further ...

Now my questions:

Why did I have to re-install both MinGW and MSYS before
the environment was "useable" again ? - Or where else was
a mistake in my procedure ?

Any explanation is appreciated.

Kind regards,

	Viktor Ransmayr

Allen Lake wrote:
> 
> I'm sure this minor problem has probably been raised before, but I got an
> interesting question from a MinGW/MSYS newbie while trying to walk him
> through setting everything up.
> 
> Basically, why is the MinGW-1.1 binaries package a .tar.gz file rather than
> a .zip file?  Since the current procedure for setting up MinGW and MSYS
> seems to be to install the MinGW package first (e.g. in c:\mingw), then use
> the MSYS installer's post-install procedure to map the MinGW installation
> into the MSYS environment, why not make MinGW-1.1 (and its eventual
> successors) into .zip files?  The newbie's point was that not everybody
> would have a DOS/Win tar program, but they would probably have an unzip
> program.  Since tar is included in the MSYS package, why force the user to
> to download a Win/DOS version of tar, or use something like WinZip (in a
> mode they are not accustomed to using) to install the MinGW-1.1 package.
> 
> This might help stop some of the problems being seen with setting the wrong
> options in WinZip or other archive-handling programs during MinGW and MSYS
> installs.
> 

How would that stop the wrong options?  A .zip versus a .tar.gz just
means that different methods were used to create the archives and .zip
is much fatter than .tar.gz causing you to take longer in the download
process and causing me to take longer in the upload process.  WinZip is
a free download and understands .tar.gz format and comes with a nice GUI
so you don't really need a windows version of tar and gzip.  If it
(WinZip) understood .tar.bz2 format I would probably package with bzip2.

As far as the wrong options for WinZip, that's in the users hands, not
the archivers hands.  And for users of Windows XP, it's in Microsoft's
hands as the FileMenu will uncompress both zip and tar.gz for you
without WinZip.  I haven't checked to see what it does with line
endings.

Earnie.

I'm sure this minor problem has probably been raised before, but I got an 
interesting question from a MinGW/MSYS newbie while trying to walk him 
through setting everything up.

Basically, why is the MinGW-1.1 binaries package a .tar.gz file rather than 
a .zip file?  Since the current procedure for setting up MinGW and MSYS 
seems to be to install the MinGW package first (e.g. in c:\mingw), then use 
the MSYS installer's post-install procedure to map the MinGW installation 
into the MSYS environment, why not make MinGW-1.1 (and its eventual 
successors) into .zip files?  The newbie's point was that not everybody 
would have a DOS/Win tar program, but they would probably have an unzip 
program.  Since tar is included in the MSYS package, why force the user to 
to download a Win/DOS version of tar, or use something like WinZip (in a 
mode they are not accustomed to using) to install the MinGW-1.1 package.

This might help stop some of the problems being seen with setting the wrong 
options in WinZip or other archive-handling programs during MinGW and MSYS 
installs.



_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

"Paul G." wrote:
> 
> Is MSYS supposed to set usr/local/bin?
> 

Yes.

> Just noticed that it does, and was not sure if it was what it was supposed to be doing...
> 
> I had thought that usr/bin was supposed to be where MSYS looked for .exe, etc., not usr/local/bin.  Can someone
> clarify for me? (it looks like posixy standards, so am not sure).
> 

MSYS is an aid to build programs with a MINGW32 host/build system.  The
default configuration prefix is /usr/local so it makes sense to allocate
that in the PATH.  The /usr/bin is reserved for binaries and scripts
dependent on msys-1.0.dll.

Earnie.

Is MSYS supposed to set usr/local/bin?

Just noticed that it does, and was not sure if it was what it was supposed to be doing...

I had thought that usr/bin was supposed to be where MSYS looked for .exe, etc., not usr/local/bin.  Can someone 
clarify for me? (it looks like posixy standards, so am not sure).


	Thanks,

		Paul G.

I just looked at the taskinfo.exe output which gives four new entries 
after running msys.bat.

These entries are the same either with start or with run. The last one 
seems to be connected to the DOS box.

Holger


Taskinfo.exe output for run:

      + RXVT.EXE       0,10%    0,84%                102    1.032 
2.452      5    Norm   4,0    32 Con         G:\MSYS\BIN\RXVT.EXE 


      + WINOA386.MOD            0,32%                1      8          8 
          1    Norm   4,0    16 
C:\WINDOWS\SYSTEM\WINOA386.MOD 


      + SH.EXE         0,05%    0,45%                2      1.216 
1.736      4    Norm   4,0    32 Con         G:\MSYS\BIN\SH.EXE 


      + VM: id                  0,01%                1      0          0 
          1    Norm   4,0    16 Dos Idle 



Earnie Boyd wrote:

> Does the run.exe process remain opened or does it exit once rxvt is
> started?
> 
> Earnie.
> 
> Holger Vogt wrote:
> 
>>Dear all,
>>
>>I have removed the console window which appears after starting rxvt from
>>msys.bat in line 42 by replacing start with run ( run.exe from
>>http://www.neuro.gatech.edu/users/cwilson/cygutils/run/ ).
>>
>>:startrxvt
>>run rxvt -sl 2500 -fg %FGCOLOR% -bg %BGCOLOR% -sr -fn Courier-12 -tn
>>msys -e /bin/sh --login -i
>>
>>I have installed MSYS-1.0.7-i686-2.exe on an Athlon 1.4GHz 256MB under
>>Windows ME.
>>
>>Regards
>>
>>Holger Vogt
>>
>>_______________________________________________________________
>>
>>Don't miss the 2002 Sprint PCS Application Developer's Conference
>>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>>
>>_______________________________________________
>>Mingw-msys mailing list
>>Min...@li...
>>https://lists.sourceforge.net/lists/listinfo/mingw-msys
>>
> 
> 

Does the run.exe process remain opened or does it exit once rxvt is
started?

Earnie.

Holger Vogt wrote:
> 
> Dear all,
> 
> I have removed the console window which appears after starting rxvt from
> msys.bat in line 42 by replacing start with run ( run.exe from
> http://www.neuro.gatech.edu/users/cwilson/cygutils/run/ ).
> 
> :startrxvt
> run rxvt -sl 2500 -fg %FGCOLOR% -bg %BGCOLOR% -sr -fn Courier-12 -tn
> msys -e /bin/sh --login -i
> 
> I have installed MSYS-1.0.7-i686-2.exe on an Athlon 1.4GHz 256MB under
> Windows ME.
> 
> Regards
> 
> Holger Vogt
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Dear all,

I have removed the console window which appears after starting rxvt from 
msys.bat in line 42 by replacing start with run ( run.exe from 
http://www.neuro.gatech.edu/users/cwilson/cygutils/run/ ).

:startrxvt
run rxvt -sl 2500 -fg %FGCOLOR% -bg %BGCOLOR% -sr -fn Courier-12 -tn 
msys -e /bin/sh --login -i

I have installed MSYS-1.0.7-i686-2.exe on an Athlon 1.4GHz 256MB under 
Windows ME.

Regards

Holger Vogt

Daniel Glassey wrote:
> 
> > Check the .m4f file, are the line endings DOS \r\n or UNIX \n style?
> 
> The m4 and m4f files in /share have DOS line endings
> The m4 files in source have UNIX line endings
> 

Ok, so m4 needs some \r\n work (any volunteers?).  You've unarchived
using WinZip, this isn't bad but having WinZip do \n to \r\n autostupid
conversion is.  I suggest you either use `tar zxvf msysDTK....tar.gz' or
turn autostupid line conversion off.

> > P.S.: Where can I download your work so that I can give it a go myself?
> 
> The main source tree is abiword cvs
> CVSROOT=:pserver:an...@cv...:/cvsroot
> password anoncvs
> 
> required modules: abi, wv, psiconv
> modules if you don't already have them: libpng, zlib, libiconv, expat
> optional for plugins: abiword-plugins
> 
> checkout with the tag ABIWORD-1-0-0-STABLE for abi and abiword-plugins
> 
> The patches are archived at:
> http://www.abisource.com/mailinglists/abiword-dev/02/May/0738.html
> http://www.abisource.com/mailinglists/abiword-dev/02/May/0767.html
> 
> configure won't work yet but just plain make does.
> 

Thanks, I'll check it out.

Earnie.

Ok, this abort is within the make.exe itself.  I'll have to get a debug
version of make.exe up to try to locate this problem.  I'll be
contacting you privately for help with this.

Earnie.

Daniel Glassey wrote:
> 
> oops, ok, here it is.
> 
> Regards,
> Daniel
> 
> On 28 May 2002 at 7:06, Earnie Boyd sent forth the message:
> 
> > Post the make.exe.stackdump as an attachment please.
> >
> > Daniel Glassey wrote:
> > >
> > > Hi,
> > > the good news is that AbiWord now successfully builds with mingw/msys :)
> > > The only problem is that the msys make crashes more than half the time during a
> > > build like:
> > >
> > > make[3]: Entering directory `/d/temp/src/abisource-
> > > stable/abi/src/tools/cdump'
> > > Building with [LicensedTrademarks:Off Debug:Off BiDi:On /LTR dominant/
> > > Pspell:Off Scripting:Off].
> > > make  ABI_ROOT=/d/temp/src/abisource-stable/abi -C xp build
> > >       0 [main] make 552 open_stackdumpfile: Dumping stack trace to
> > > make.exe.stackdump
> > > make[3]: *** [build] Error 139
> > > make[3]: Leaving directory `/d/temp/src/abisource-stable/abi/src/tools/cdump'
> > >
> > > It happens in all sorts of directories. I'm 99% sure that I've cleaned things in
> > > /mingw/bin that shouldn't be there now.
> > >
> > > Regards,
> > > Daniel
> > >
> > > _______________________________________________________________
> > >
> > > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > >
> > > _______________________________________________
> > > Mingw-msys mailing list
> > > Min...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 
>   ------------------------------------------------------------------------
> Exception: STATUS_ACCESS_VIOLATION at eip=0040C22A
> eax=00000004 ebx=71111BE4 ecx=710A7CB4 edx=0022ED78 esi=FFFFFFFF edi=00000000
> ebp=0022EDB4 esp=0022ED8C program=d:\toys\msys\1.0\bin\make.exe
> cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0022EDB4  0040C22A  (00000008, 0A0171F8, 000000C8, 00407BBE)
> 0022EDD4  7108FA62  (00000008, 0A0171F8, 000000C8, 00407BEC)
> 0022EE74  00407C09  (0A017058, 0022EE8C, 00407D99, 00407F97)
> 0022EED4  00408154  (0022EF5C, 0022EF60, 00000000, 71063D11)
> 0022EF74  00403B28  (00000000, 0A016396, FFFFFFFF, 710301AD)
> 0022EFA4  0040443E  (0A016396, 00000000, 0000000A, 0041B941)
> 0022F024  0041B9FF  (0022F0FC, 0A016388, 00000002, 00000000)
> 0022F114  004133E5  (0A0165D8, 0000000A, 00000007, 00000000)
> 0022F204  00413345  (00412189, 00000000, 0022F254, 0041E208)
> 0022F254  00412324  (00000000, 00000000, 0022FD74, 0040F0B3)
> 0022FD74  0040F0EF  (00000005, 71110A5C, 0A010008, 00000000)
> 0022FE70  710043D5  (00000000, 00000000, 00000000, 00000000)
> 0022FF40  71004621  (0040E4C4, 00000000, 8201E180, 80004530)
> 0022FF60  71004C9C  (00000000, 00000000, 00000000, 8201E1B0)
> 0022FF90  00420547  (0040E4C4, 8201E020, FFFFFFFF, 8043071C)
> 0022FFC0  0040103D  (00000000, 00000000, 7FFDF000, 00000000)
> End of stack trace (more stack frames may be present)

oops, ok, here it is. 

Regards,
Daniel

On 28 May 2002 at 7:06, Earnie Boyd sent forth the message:

> Post the make.exe.stackdump as an attachment please.
> 
> Daniel Glassey wrote:
> > 
> > Hi,
> > the good news is that AbiWord now successfully builds with mingw/msys :)
> > The only problem is that the msys make crashes more than half the time during a
> > build like:
> > 
> > make[3]: Entering directory `/d/temp/src/abisource-
> > stable/abi/src/tools/cdump'
> > Building with [LicensedTrademarks:Off Debug:Off BiDi:On /LTR dominant/
> > Pspell:Off Scripting:Off].
> > make  ABI_ROOT=/d/temp/src/abisource-stable/abi -C xp build
> >       0 [main] make 552 open_stackdumpfile: Dumping stack trace to
> > make.exe.stackdump
> > make[3]: *** [build] Error 139
> > make[3]: Leaving directory `/d/temp/src/abisource-stable/abi/src/tools/cdump'
> > 
> > It happens in all sorts of directories. I'm 99% sure that I've cleaned things in
> > /mingw/bin that shouldn't be there now.
> > 
> > Regards,
> > Daniel
> > 
> > _______________________________________________________________
> > 
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > 
> > _______________________________________________
> > Mingw-msys mailing list
> > Min...@li...
> > https://lists.sourceforge.net/lists/listinfo/mingw-msys

On 28 May 2002 at 7:08, Earnie Boyd sent forth the message:

> Daniel Glassey wrote:
> > 
> > Hi,
> > In a lot of the apps in msysDTK paths are hard coded e.g.
> > /usr/share/autoconf.
> > But in msys paths are like /share/autoconf
> >  
> /usr and / point to the same path tree, this shouldn't matter.

ok

> > I don't know if this is the reason for failure but when I try and run msys
> > autoconf for abiword-plugins I get:
> > $ autoconf
> > autoconf: warning: both `configure.ac' and `configure.in' are present.
> > autoconf: warning: proceeding with `configure.ac'.
> > NONE:0: /bin/m4: Expecting line feed in frozen file
> > 
> Check the .m4f file, are the line endings DOS \r\n or UNIX \n style?

The m4 and m4f files in /share have DOS line endings
The m4 files in source have UNIX line endings

> P.S.: Where can I download your work so that I can give it a go myself?

The main source tree is abiword cvs
CVSROOT=:pserver:an...@cv...:/cvsroot
password anoncvs

required modules: abi, wv, psiconv
modules if you don't already have them: libpng, zlib, libiconv, expat
optional for plugins: abiword-plugins

checkout with the tag ABIWORD-1-0-0-STABLE for abi and abiword-plugins

The patches are archived at:
http://www.abisource.com/mailinglists/abiword-dev/02/May/0738.html
http://www.abisource.com/mailinglists/abiword-dev/02/May/0767.html

configure won't work yet but just plain make does.

Thanks,
Daniel