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

Earnie Boyd wrote:
> "Jonathan Turkanis" wrote:
>> Earnie Boyd wrote:

>> I'm sorry, but I don't quite understand this. Could you elaborate?
>> For example, if the distribution will be available through SF as a
>> compressed archive, where will the executable installation program be
>> available? Also, if MinGW and MSYS will use a common installer, why
>> will the file name begin with MSYS?

> The installer would be named MinGW-x.x.x.exe and the MSYS file will be
> named MSYS-x.x.x.tar.bz2.  But that all depends on fixing the
> MinGW-x.x.x.exe to be more compliant to the users needs.

Okay, thanks.

>> I apologize for my thickheadedness

> No need to apologize.  Thanks for the advertisement in published
> articles from one of the better (if not the best) publishing
> companies of technical material.

Thanks for the excellent software!

> Earnie

Jonathan

On 4:46:55 am 2005-06-28 "Jonathan Turkanis" <tec...@ka...>
wrote:
> Thanks for the quick response!
>
> Earnie Boyd wrote:
> >  The home page and batch file name are not changing.  The installer
> >  may change but that is undecided at this point.  If it does
> >  change, I'll use a common installer for all packages (MinGW as
> >  well as MSYS) and use a compressed archive for the SF file release
> >  page.  The file name will always begin MSYS and the version number
> >  will always be contained in the file name.
>
> I'm sorry, but I don't quite understand this. Could you elaborate?
> For example, if the distribution will be available through SF as a
> compressed archive, where will the executable installation program be
> available? Also, if MinGW and MSYS will use a common installer, why
> will the file name begin with MSYS?
>

The installer would be named MinGW-x.x.x.exe and the MSYS file will be
named MSYS-x.x.x.tar.bz2.  But that all depends on fixing the
MinGW-x.x.x.exe to be more compliant to the users needs.

> I apologize for my thickheadedness
>

No need to apologize.  Thanks for the advertisement in published articles
from one of the better (if not the best) publishing companies of technical
material.

Earnie

Thanks for the quick response!

Earnie Boyd wrote:
> The home page and batch file name are not changing.  The installer may
> change but that is undecided at this point.  If it does change, I'll
> use a common installer for all packages (MinGW as well as MSYS) and
> use a compressed archive for the SF file release page.  The file name
> will always begin MSYS and the version number will always be
> contained in the file name.

I'm sorry, but I don't quite understand this. Could you elaborate? For example,
if the distribution will be available through SF as a compressed archive, where
will the executable installation program be available? Also, if MinGW and MSYS
will use a common installer, why will the file name begin with MSYS?

I apologize for my thickheadedness

> At the current rate of time I have to
> spend on MSYS changes will not happen before the next six months at
> least and maybe longer.  On the near horizon is an official release
> of MSYS-1.0.11 to the Current package.
>
> Earnie

Jonathan

On 11:04:38 pm 2005-06-27 Jonathan Turkanis <tec...@ka...>
wrote:
> Hi All,
>
> I'm writing a section on MSYS for an O'Reilly C++ book. I don't want
> to include an information which is likely to change in the next year
> or two. I'm interested to know how stable the following elements are:
>
> MSYS homepage: http://www.mingw.org/msys.shtml
> Windows installer name: MSYS-<version>.exe
> Batch file for starting MSYS shell: msys.bat
>
> Any help would be greatly appreciated.
>

The home page and batch file name are not changing.  The installer may
change but that is undecided at this point.  If it does change, I'll use a
common installer for all packages (MinGW as well as MSYS) and use a
compressed archive for the SF file release page.  The file name will always
begin MSYS and the version number will always be contained in the file
name.  At the current rate of time I have to spend on MSYS changes will not
happen before the next six months at least and maybe longer.  On the near
horizon is an official release of MSYS-1.0.11 to the Current package.

Earnie

Hi All,

I'm writing a section on MSYS for an O'Reilly C++ book. I don't want to include 
an information which is likely to change in the next year or two. I'm interested 
to know how stable the following elements are:

MSYS homepage: http://www.mingw.org/msys.shtml
Windows installer name: MSYS-<version>.exe
Batch file for starting MSYS shell: msys.bat

Any help would be greatly appreciated.

Best Regards,
Jonathan

On 6:05:12 pm 2005-06-26 "Max T. Woodbury" <ma...@mt...> wrote:

> I really could use a copy of your 'config.log' for the findutils.
>

I'll try to get to it tomorrow morning EDT.  Feel free to remind me if it
lags to afternoon.

Earnie

Sorry about the delay on this follow-up.  I've been working on the
findutils problem.  It seems that this package has much the same
problem with the same solution.

Earnie: Unless directed otherwise, I'll simply add this as a comment
to the findutils bug report, with an appropriate change in title if
that is possible.

I'll also check the POSIX standard to see exactly what fchdir is
supposed to do.

I really could use a copy of your 'config.log' for the findutils.

ma...@mt...

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3220051
By: earnie

export TESTPATH=/c/windows/\*.log

If you have pre-made make files with win32 paths try using ``make --win32''
to see if it might help.

I'm still downloading the big pdf.  I didn't see MSYS mentioned anywhere yet.

For the project web page see http://www.mingw.org.  You should be able to find
your way from there.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

SourceForge.net wrote:

>The problem I have found is that Windows environment variables containing paths
>are not translated into posix paths, and thus don't work - for example
>
>in Windows
>set TESTPATH=C:\Windows\*.log
>
>in MSYS
>cp $TESTPATH   .
>
>results in the error
>$ cp $TESTPATH .
>cp: cannot stat `C:\Windows\*.log': No such file or directory
>  
>
Could you use forward slashes in TESTPATH? Are there problems with that?

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3219969
By: casiobearing

I am completely new to MSYS and I am trying to use it so that I can run a build
script within another product called GRLIB  from these people
http://www.gaisler.com/

Their stuff is developed under linux, and it said it would work in windows using
MSYS.

The problem I have found is that Windows environment variables containing paths
are not translated into posix paths, and thus don't work - for example

in Windows
set TESTPATH=C:\Windows\*.log

in MSYS
cp $TESTPATH   .

results in the error
$ cp $TESTPATH .
cp: cannot stat `C:\Windows\*.log': No such file or directory

I have also seen an error where the slashes are removed completely during a
make, resulting in the following error

cp D:\MyProjects\FPGAs\SOC\grlib-eval-1.0/boards//config .config
cp: cannot stat `D:MyProjectsFPGAsSOCgrlib-eval-1.0/boards//config': No such
file or directory
make: *** [config] Error 1

Also... In this website Where on earth do you join this project so you can put
posts into mailgroups... I can't seem to find a 'join this project' button or
page.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

I think Earnie means "all of the compilers", not just the gcc/g++ compiler.

	Paul G.

On 25 Jun 2005 at 22:32, Earnie Boyd wrote:

> On 5:19:23 pm 2005-06-25 David Arnold <da...@no...> wrote:
> > Paul, > > Thanks. But I'd like to have all the necessary files
> downloaded onto > a disk so I can burn a CD for my students who do not
> have internet > access at home or only have dial up. So, what files
> should I download > in addition to the MinGW-4.1.0.exe? >
> 
> http://prdownloads.sf.net/mingw/MinGW-3.2.0-rc-3.exe?download is a
> release candidate that is 50M big and is no longer offered; but SF
> never deletes a file so it is still available.  It will give you GCC
> 3.4.2 version of the compilers and the more recent versions of
> mingw-runtime and w32api.
> 
> Earnie
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________ Mingw-msys mailing
> list Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

Hi David,

On 25 Jun 2005 at 10:19, David Arnold wrote:

> Paul,
> 
> Thanks. But I'd like to have all the necessary files downloaded onto a
> disk so I can burn a CD for my students who do not have internet
> access at home or only have dial up.

	Understood.

> So, what files should I download
> in addition to the MinGW-4.1.0.exe?

	Well, at the sf.net site you can download everything independently, as you probably know.  I do believe, however, that if you 
have a cd-rom burner that you can download using the install (MinGW-4.10.exe) to a special folder/directory and then make an 
image of the folder and then burn the image to the cd.

	If you want to download them independently and not decompress them, then here is what I would download from the current 
selections as the current selections are the most "stable":

	MSys:  Assume you already have this, in case you do not, and you are interested in developing for MSys then the DTK is a 
good start, that combined with Msys-1.0.10.exe (binutils, libs, compiler, etc.) will give you your basic MSys.

	MinGW:
		Mingw-runtime-3.7.tar.gz
		Win32api-32.tar.gz
		binutils-2.15.91.tar.gz
		binutils-2.14.90-info-html.tar.gz
		mingw32-make-3.80.0-3.tar.gz (only if you think you need it, I am not sure if make is still part of binutils or not)
	note: if you are just doing c/c++ application builds then you will only need to download:
		gcc-core-3.4.2-20040916-1.tar.gz
	if you are working on or teaching about the compiler itself (gcc/g++) then:
		gcc-g++-3.4.2-20040916-1-src.tar.gz (which has all the source code for gcc/g++ that is used to build MinGW gcc/g++).
	and finally, I would recommend the completely optional gdb package (customized for MinGW32):
		gdb-5.2.1-1.exe
		Also of note:
			if you choose to download gdb, then I would recommend the mingw-utils-0.3.tar.gz as well.

	I think that MinGW-4.1.0.exe install will download and install "all of the above" (with the exception of Msys, Msys-DTK, 
Mingw utils, gdb and gcc-g++-3.4.2-20040916-1-src.tar.gz) to the directory/folder you want MinGW-4.1.0.exe to "install" MinGW 
"to".

	Hope this helps.

		Paul G.
	
		
> 
> Thanks.
> 
> On Jun 24, 2005, at 10:32 PM, Paul G. wrote:
> 
> > Hi folks,
> >
> > On 24 Jun 2005 at 21:27, David Arnold wrote:
> >
> >> All,
> >>
> >> When I look at MinGW-4.1.0.exe under "Current" on
> >> http://www.mingw.org/download.shtml, I see the file size is 828 kb.
> >>
> >> Is this correct?
> >
> > 	Yes, that is the correct size.
> >
> >> Does this package contain all the binaries it should
> >> contain?
> >
> > 	No.  Even so, it is good to remember that it is a download-install
> > so that when you start the install it automatically begins
> > downloading and installing the necessary binaries, etc. to the
> > directories (folder) that the user defines.
> >
> > 	Personally I think it is great, but then, I have a large bandwidth.
> >  The whole download only takes me a minute or two, if that.
> >>
> >> On comparing it with MinGW-3.1.0.exe under "Previous," I note that
> >> the file size there is 14733kb.
> >>
> >> What's going on?
> >
> > 	;-)
> >
> > 		Paul G.
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is sponsored by: Discover Easy Linux Migration
> >> Strategies from IBM. Find simple to follow Roadmaps,
> >> straightforward articles, informative Webcasts and more! Get
> >> everything you need to get up to speed, fast.
> >> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> >> _______________________________________________ Mingw-msys mailing
> >> list Min...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mingw-msys
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> > Strategies from IBM. Find simple to follow Roadmaps, straightforward
> > articles, informative Webcasts and more! Get everything you need to
> > get up to speed, fast.
> > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________ Mingw-msys mailing
> > list Min...@li...
> > https://lists.sourceforge.net/lists/listinfo/mingw-msys
> >
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________ Mingw-msys mailing
> list Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

On 5:19:23 pm 2005-06-25 David Arnold <da...@no...> wrote:
> Paul,
>
> Thanks. But I'd like to have all the necessary files downloaded onto
> a disk so I can burn a CD for my students who do not have internet
> access at home or only have dial up. So, what files should I download
> in addition to the MinGW-4.1.0.exe?
>

http://prdownloads.sf.net/mingw/MinGW-3.2.0-rc-3.exe?download is a release
candidate that is 50M big and is no longer offered; but SF never deletes a
file so it is still available.  It will give you GCC 3.4.2 version of the
compilers and the more recent versions of mingw-runtime and w32api.

Earnie

Paul,

Thanks. But I'd like to have all the necessary files downloaded onto a 
disk so I can burn a CD for my students who do not have internet access 
at home or only have dial up. So, what files should I download in 
addition to the MinGW-4.1.0.exe?

Thanks.

On Jun 24, 2005, at 10:32 PM, Paul G. wrote:

> Hi folks,
>
> On 24 Jun 2005 at 21:27, David Arnold wrote:
>
>> All,
>>
>> When I look at MinGW-4.1.0.exe under "Current" on
>> http://www.mingw.org/download.shtml, I see the file size is 828 kb.
>>
>> Is this correct?
>
> 	Yes, that is the correct size.
>
>> Does this package contain all the binaries it should
>> contain?
>
> 	No.  Even so, it is good to remember that it is a download-install so 
> that when you start the install it automatically begins
> downloading and installing the necessary binaries, etc. to the 
> directories (folder) that the user defines.
>
> 	Personally I think it is great, but then, I have a large bandwidth.  
> The whole download only takes me a minute or two, if
> that.
>>
>> On comparing it with MinGW-3.1.0.exe under "Previous," I note that the
>> file size there is 14733kb.
>>
>> What's going on?
>
> 	;-)
>
> 		Paul G.
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________ Mingw-msys mailing
>> list Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>

Hi folks,

On 24 Jun 2005 at 21:27, David Arnold wrote:

> All,
> 
> When I look at MinGW-4.1.0.exe under "Current" on 
> http://www.mingw.org/download.shtml, I see the file size is 828 kb.
> 
> Is this correct?

	Yes, that is the correct size.

> Does this package contain all the binaries it should
> contain?

	No.  Even so, it is good to remember that it is a download-install so that when you start the install it automatically begins 
downloading and installing the necessary binaries, etc. to the directories (folder) that the user defines.

	Personally I think it is great, but then, I have a large bandwidth.  The whole download only takes me a minute or two, if 
that.
> 
> On comparing it with MinGW-3.1.0.exe under "Previous," I note that the
> file size there is 14733kb.
> 
> What's going on?

	;-)

		Paul G.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________ Mingw-msys mailing
> list Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

All,

When I look at MinGW-4.1.0.exe under "Current" on 
http://www.mingw.org/download.shtml, I see the file size is 828 kb.

Is this correct? Does this package contain all the binaries it should 
contain?

On comparing it with MinGW-3.1.0.exe under "Previous," I note that the 
file size there is 14733kb.

What's going on?

Earnie Boyd wrote:
> 
> On 11:16:12 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> > Sorry, I meant to keep this off-line.  I was a little too blunt for a
> > public forum.  Sleepy...
> >
> 
> Don't know what you mean by ``blunt'' as I didn't see anything offensive.
> I want this on list; there is no need respond to me personally on the
> subject of MSYS.

Blunt in that I'm arguing with you on the public list.  I've gotten quite a 
bit of negative feedback for doing that in other contexts.

> > Earnie Boyd wrote:
> > >  Please open a bug report with a working sample of this code.  It
> > >  would be MSYS that needs fixed here.  You'll need to include the
> > >  xgetcwd function in the test.
> >
> > The code is from CVS msys/package/findutils/4.1/find.  I have not
> > looked at all closely at it but xgetcwd should be someplace in the
> > findutils directory tree.  I'm trying to say I'm not sure what bug to
> > report.  It's not really a MSYS bug.  It's a 'findutils' bug and
> > 'findutils' is no longer 'current' IIRC.  Isn't it in 'coreutils'
> > these days?  Anyway, xgetcwd works.  It's open (".", O_RDONLY) that
> > fails and it is probably correct that it does even if the error code
> > returned is a bit off the mark.  It might even be an 'autoconf'
> > problem, and we're off-rev there too.  Still I see it's our problem
> > too, but as I said I'm not sure how to report it as a 'MSYS' bug.  I
> > could report it as a 'find' bug with a 'msys' group code so we get to
> > work on it...
> 
> xgetcwd is probably located in the findutils package in a directory named
> lib; haven't looked so not positive on that.  Perhaps it comes from
> libiberty.

It's in msys/packages/findutils/4.1/lib.  I didn't check libiberty.

> The bug you have already reported is a deficiency in MSYS to properly
> fchdir.  It is MSYS that supplies the runtime for fchdir so if there is a
> problem with doing so, the MSYS has a bug.  The test case for the bug
> report would use the code snippet from above with an arugment of a give
> path to open and then change to.

That's most of the problem.  fchdir now works properly.  Apparently it
did not when the distributed find.exe was originally configured.  We'd
have to UNFIX fchdir in order to fix find.  MSYS no longer has a bug.
There's an assumption in find that if you can do fchdir, you can open
a directory read-only.  This is not something we (i.e. you but I'm in
the pot too now) wrote.  I'll report this as a problem to the bug
tracker with msys as to group that should work on it, but I'll phrase
it as a build problem, not as an execution defect, and I'll mention
my work-around.

Max

On 11:16:12 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> Sorry, I meant to keep this off-line.  I was a little too blunt for a
> public forum.  Sleepy...
>

Don't know what you mean by ``blunt'' as I didn't see anything offensive. 
I want this on list; there is no need respond to me personally on the
subject of MSYS.

> Earnie Boyd wrote:
> >
> >  On 4:55:57 am 2005-06-23 "Max T. Woodbury" <ma...@mt...>
> > >  wrote: Earnie Boyd wrote:
> > > >
> > > >   You must not be doing something correctly.  I've never had to
> > > do that!
> > >  Follow up from my previous reply...
> > >
> > >  I was trying to think of a way to tell which way the 'official'
> > >  find was built - with or without 'fchdir' and I realized the
> > >  snippet I included could be the basis of that test...
> > >
> > >  #ifndef HAVE_FCHDIR
> > >    starting_dir = xgetcwd ();
> > >    if (starting_dir == NULL)
> > >      error (1, errno, "cannot get current directory");
> > >  #else
> > >    starting_desc = open (".", O_RDONLY);
> > >    if (starting_desc < 0)
> > >      error (1, errno, "cannot open current directory");
> > >  #endif
> > >
> > >  The strings in the error messages are different and long enough
> > >  to make a good match test.  I used 'grep' (twice) to look for
> > >  both strings in your find.exe.  It only found a match on the
> > >  'get' form, not the 'open' form, which is a good argument that
> > >  HAVE_FCHDIR was not defined when you built it.  Why it got
> > >  defined on my system and not your's is a good question but the
> > >  right answer is still to not have it defined.  Forcing a 'no'
> > >  into the cache for that question is the way to do that.
> >
> >  Please open a bug report with a working sample of this code.  It
> >  would be MSYS that needs fixed here.  You'll need to include the
> >  xgetcwd function in the test.
>
> The code is from CVS msys/package/findutils/4.1/find.  I have not
> looked at all closely at it but xgetcwd should be someplace in the
> findutils directory tree.  I'm trying to say I'm not sure what bug to
> report.  It's not really a MSYS bug.  It's a 'findutils' bug and
> 'findutils' is no longer 'current' IIRC.  Isn't it in 'coreutils'
> these days?  Anyway, xgetcwd works.  It's open (".", O_RDONLY) that
> fails and it is probably correct that it does even if the error code
> returned is a bit off the mark.  It might even be an 'autoconf'
> problem, and we're off-rev there too.  Still I see it's our problem
> too, but as I said I'm not sure how to report it as a 'MSYS' bug.  I
> could report it as a 'find' bug with a 'msys' group code so we get to
> work on it...
>

xgetcwd is probably located in the findutils package in a directory named
lib; haven't looked so not positive on that.  Perhaps it comes from
libiberty.

The bug you have already reported is a deficiency in MSYS to properly
fchdir.  It is MSYS that supplies the runtime for fchdir so if there is a
problem with doing so, the MSYS has a bug.  The test case for the bug
report would use the code snippet from above with an arugment of a give
path to open and then change to.

Earnie

On 4:55:57 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> Earnie Boyd wrote:
> >
> >  On 2:58:45 am 2005-06-23 "Max T. Woodbury" <ma...@mt...>
> > >  wrote: This is a follow-up on the problem with 'find'.  As noted
> > >  the resulting program was not usable.  I found a way around the
> > >  problem. 'configure' has to be told not to use 'fchdir'.  If you
> > >  are doing the configure by hand, include ac_cv_func_fchdir='no'
> > >  at the beginning of the line where you invoke 'configure'.  With
> > >  the driver script, use the new details file attached.
> >
> >  You must not be doing something correctly.  I've never had to do
> that!
>
> Follow up from my previous reply...
>
> I was trying to think of a way to tell which way the 'official' find
> was built - with or without 'fchdir' and I realized the snippet I
> included could be the basis of that test...
>
> #ifndef HAVE_FCHDIR
>   starting_dir = xgetcwd ();
>   if (starting_dir == NULL)
>     error (1, errno, "cannot get current directory");
> #else
>   starting_desc = open (".", O_RDONLY);
>   if (starting_desc < 0)
>     error (1, errno, "cannot open current directory");
> #endif
>
> The strings in the error messages are different and long enough to
> make a good match test.  I used 'grep' (twice) to look for both
> strings in your find.exe.  It only found a match on the 'get' form,
> not the 'open' form, which is a good argument that HAVE_FCHDIR was
> not defined when you built it.  Why it got defined on my system and
> not your's is a good question but the right answer is still to not
> have it defined.  Forcing a 'no' into the cache for that question
> is the way to do that.
>

Please open a bug report with a working sample of this code.  It would be
MSYS that needs fixed here.  You'll need to include the xgetcwd function in
the test.

> It's 1:00 AM here.  I think I'll go to bed early...
>

I worked from 11:00PM Saturday to 10:00 AM Sunday if it helps you any. :)

Earnie

Earnie Boyd wrote:
> 
> On 2:58:45 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> > This is a follow-up on the problem with 'find'.  As noted the
> > resulting program was not usable.  I found a way around the problem.
> > 'configure' has to be told not to use 'fchdir'.  If you are doing the
> > configure by hand, include ac_cv_func_fchdir='no' at the beginning of
> > the line where you invoke 'configure'.  With the driver script, use
> > the new details file attached.
> 
> You must not be doing something correctly.  I've never had to do that!

Follow up from my previous reply...

I was trying to think of a way to tell which way the 'official' find was
built - with or without 'fchdir' and I realized the snippet I included
could be the basis of that test...

#ifndef HAVE_FCHDIR
  starting_dir = xgetcwd ();
  if (starting_dir == NULL)
    error (1, errno, "cannot get current directory");
#else
  starting_desc = open (".", O_RDONLY);
  if (starting_desc < 0)
    error (1, errno, "cannot open current directory");
#endif

The strings in the error messages are different and long enough to
make a good match test.  I used 'grep' (twice) to look for both 
strings in your find.exe.  It only found a match on the 'get' form, 
not the 'open' form, which is a good argument that HAVE_FCHDIR was 
not defined when you built it.  Why it got defined on my system and 
not your's is a good question but the right answer is still to not
have it defined.  Forcing a 'no' into the cache for that question
is the way to do that.

It's 1:00 AM here.  I think I'll go to bed early...

On 2:58:45 am 2005-06-23 "Max T. Woodbury" <ma...@mt...> wrote:
> This is a follow-up on the problem with 'find'.  As noted the
> resulting program was not usable.  I found a way around the problem.
> 'configure' has to be told not to use 'fchdir'.  If you are doing the
> configure by hand, include ac_cv_func_fchdir='no' at the beginning of
> the line where you invoke 'configure'.  With the driver script, use
> the new details file attached.

You must not be doing something correctly.  I've never had to do that!

Earnie

This is a follow-up on the problem with 'find'.  As noted the resulting
program was not usable.  I found a way around the problem.  'configure'
has to be told not to use 'fchdir'.  If you are doing the configure by
hand, include ac_cv_func_fchdir='no' at the beginning of the line where
you invoke 'configure'.  With the driver script, use the new details
file attached.

Joel Salomon wrote:
>=20
> I noticed that some of the MSys reconstruction stuff had a note to =
the effect that
>
>> The package builds without problems other than the fact that the
>> resulting executable lacks the .exe suffix.
>
> IIRC, I could run executable files from the command line (bash or c=
md.exe) under WinXP Pro,
> so this is not a *problem*=97for me, at least. In fact, is there so=
me way to set this as the
> default on my own system?  I'm willing to attempt a complete rebuil=
d of MinGW and MSys if
> someone will give me some pointers.
>
> Thanks, --Joel

There are parts of the msys-1.0.dll that tack the .exe on without com=
ment and the same
is even more true of cmd.exe.  Not having the correct suffix does cau=
se problems.  The=20
driver script includes ways to fix that and other problems.

As for the rebuild, take the scripts and data files provided and use =
them.  You'll
need to change the symbols that tell the script where to find the tar=
-balls but I
tried to make the whole thing as 'hands off' as possible.  Be warned =
that it can
tie up your machine for hours.  (Of course I'm using an ancient and s=
low machine.
A new machine might be 10 or 20 x faster, but that would still use up=
 an hour or
so.)

I haven't done MinGW yet.  I'm probably going to work with Earnie on =
another test
of the 1.0.11 release first.  I think another guy does MinGW and I ha=
ve not talked
to him a lot yet.

Max

On 4:08:46 pm 2005-06-22 Joel Salomon <joe...@gm...> wrote:
> I noticed that some of the MSys reconstruction stuff had a note to the
> effect that
> >  The package builds without problems other than the fact that the
> >  resulting executable lacks the .exe suffix.
> >
> IIRC, I could run executable files from the command line (bash or
> cmd.exe) under WinXP Pro, so this is not a *problem*—for me, at least.
>  In fact, is there some way to set this as the default on my own
> system?  I'm willing to attempt a complete rebuild of MinGW and MSys
> if someone will give me some pointers.
>

It is GCC you need to modify and rebuild.  Binutils ld has a switch to
enable .exe suffix which is on by default.  You could also use ld directly
and specify all of the libraries and library paths by hand.

Earnie

--
       MinGW - http://www.mingw.org/
        Wiki - http://www.mingw.org/MinGWiki/
  Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435
Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435
  SF Project - http://sourceforge.net/projects/mingw
 Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643
 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223

SSBub3RpY2VkIHRoYXQgc29tZSBvZiB0aGUgTVN5cyByZWNvbnN0cnVjdGlvbiBzdHVmZiBoYWQg
YSBub3RlIHRvIHRoZQplZmZlY3QgdGhhdAo+IFRoZSBwYWNrYWdlIGJ1aWxkcyB3aXRob3V0IHBy
b2JsZW1zIG90aGVyIHRoYW4gdGhlIGZhY3QgdGhhdCB0aGUKPiByZXN1bHRpbmcgZXhlY3V0YWJs
ZSBsYWNrcyB0aGUgLmV4ZSBzdWZmaXguCj4gCklJUkMsIEkgY291bGQgcnVuIGV4ZWN1dGFibGUg
ZmlsZXMgZnJvbSB0aGUgY29tbWFuZCBsaW5lIChiYXNoIG9yCmNtZC5leGUpIHVuZGVyIFdpblhQ
IFBybywgc28gdGhpcyBpcyBub3QgYSAqcHJvYmxlbSqXZm9yIG1lLCBhdCBsZWFzdC4KIEluIGZh
Y3QsIGlzIHRoZXJlIHNvbWUgd2F5IHRvIHNldCB0aGlzIGFzIHRoZSBkZWZhdWx0IG9uIG15IG93
bgpzeXN0ZW0/ICBJJ20gd2lsbGluZyB0byBhdHRlbXB0IGEgY29tcGxldGUgcmVidWlsZCBvZiBN
aW5HVyBhbmQgTVN5cwppZiBzb21lb25lIHdpbGwgZ2l2ZSBtZSBzb21lIHBvaW50ZXJzLgoKVGhh
bmtzLAotLUpvZWwK