RE: Problem with make

RE: Problem with make

[Brown, Kim]

I have found GNU make to be buggy with some makefiles, especially those
generated by PERL install packages.  I just use nmake from microsoft without
problems.  Anyone else have problems with GNU make?

> 
> Ok, this is a wierd one, so bear with me.
> 
> I've been using cygwin to do some java development with a 
> coworker.  For a
> while, we were just doing "jikes *.java", and had no problems.  As the
> project grew, we split things into packages and added 
> Makefiles to build the
> whole project.  The problem that showed up was that it worked 
> for me, but
> not for him - he'd get an error message each time that said "jikes -
> permission denied".  The same command that make was trying to 
> execute worked
> from the command line though... Perplexing.  We switched to 
> javac - worked
> fine.  
> 
> Anyhow, Turns out that in the directory where jikes.exe is, he had a
> directory named jikes also - make was trying to execute it, 
> but bash wasn't.
> 
> 
> So obviously, this is a bug in make - it must be looking for 
> a program named
> jikes before jikes.exe - I guess.  Either that, or it's not 
> checking to make
> sure it's a directory when it checks.  I don't mind tracking 
> this one down
> and submitting a bug fix, but I thought I ought to find out 
> if it's been
> heard of or fixed, etc.
 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[Don Sharp]

Brown, Kim wrote:
> 
> I have found GNU make to be buggy with some makefiles, especially those
> generated by PERL install packages.  I just use nmake from microsoft without
> problems.  Anyone else have problems with GNU make?
> 

Yes. I am currently trying to isolate a test case to demonstrate a bug
(in 3.77) which takes the form of showing the right set of commands to
execute when you do a

make -n target

without the -n it then tries a build of the dependencies using the
built-in rules, overriding any rules in the Makefile, even if the
dependencies don't need to be re-built.

The main point of interest is that the target must be specified within a
Make variable like

TARGET = me target

DEPENDENCY = son

$(TARGET): $(DEPENDENCY)
	throw $@ and son out of the bar at midnight

and you do a

make me

for instance.

Cheers

Don Sharp


> >
> > Ok, this is a wierd one, so bear with me.
> >
> > I've been using cygwin to do some java development with a
> > coworker.  For a
> > while, we were just doing "jikes *.java", and had no problems.  As the
> > project grew, we split things into packages and added
> > Makefiles to build the
> > whole project.  The problem that showed up was that it worked
> > for me, but
> > not for him - he'd get an error message each time that said "jikes -
> > permission denied".  The same command that make was trying to
> > execute worked
> > from the command line though... Perplexing.  We switched to
> > javac - worked
> > fine.
> >
> > Anyhow, Turns out that in the directory where jikes.exe is, he had a
> > directory named jikes also - make was trying to execute it,
> > but bash wasn't.
> >
> >
> > So obviously, this is a bug in make - it must be looking for
> > a program named
> > jikes before jikes.exe - I guess.  Either that, or it's not
> > checking to make
> > sure it's a directory when it checks.  I don't mind tracking
> > this one down
> > and submitting a bug fix, but I thought I ought to find out
> > if it's been
> > heard of or fixed, etc.
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Problem with make

[Brown, Kim]

I have found GNU make to be buggy with some makefiles, especially those
generated by PERL install packages.  I just use nmake from microsoft without
problems.  Anyone else have problems with GNU make?

> 
> Ok, this is a wierd one, so bear with me.
> 
> I've been using cygwin to do some java development with a 
> coworker.  For a
> while, we were just doing "jikes *.java", and had no problems.  As the
> project grew, we split things into packages and added 
> Makefiles to build the
> whole project.  The problem that showed up was that it worked 
> for me, but
> not for him - he'd get an error message each time that said "jikes -
> permission denied".  The same command that make was trying to 
> execute worked
> from the command line though... Perplexing.  We switched to 
> javac - worked
> fine.  
> 
> Anyhow, Turns out that in the directory where jikes.exe is, he had a
> directory named jikes also - make was trying to execute it, 
> but bash wasn't.
> 
> 
> So obviously, this is a bug in make - it must be looking for 
> a program named
> jikes before jikes.exe - I guess.  Either that, or it's not 
> checking to make
> sure it's a directory when it checks.  I don't mind tracking 
> this one down
> and submitting a bug fix, but I thought I ought to find out 
> if it's been
> heard of or fixed, etc.
 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[Don Sharp]

Brown, Kim wrote:
> 
> I have found GNU make to be buggy with some makefiles, especially those
> generated by PERL install packages.  I just use nmake from microsoft without
> problems.  Anyone else have problems with GNU make?
> 

Yes. I am currently trying to isolate a test case to demonstrate a bug
(in 3.77) which takes the form of showing the right set of commands to
execute when you do a

make -n target

without the -n it then tries a build of the dependencies using the
built-in rules, overriding any rules in the Makefile, even if the
dependencies don't need to be re-built.

The main point of interest is that the target must be specified within a
Make variable like

TARGET = me target

DEPENDENCY = son

$(TARGET): $(DEPENDENCY)
	throw $@ and son out of the bar at midnight

and you do a

make me

for instance.

Cheers

Don Sharp


> >
> > Ok, this is a wierd one, so bear with me.
> >
> > I've been using cygwin to do some java development with a
> > coworker.  For a
> > while, we were just doing "jikes *.java", and had no problems.  As the
> > project grew, we split things into packages and added
> > Makefiles to build the
> > whole project.  The problem that showed up was that it worked
> > for me, but
> > not for him - he'd get an error message each time that said "jikes -
> > permission denied".  The same command that make was trying to
> > execute worked
> > from the command line though... Perplexing.  We switched to
> > javac - worked
> > fine.
> >
> > Anyhow, Turns out that in the directory where jikes.exe is, he had a
> > directory named jikes also - make was trying to execute it,
> > but bash wasn't.
> >
> >
> > So obviously, this is a bug in make - it must be looking for
> > a program named
> > jikes before jikes.exe - I guess.  Either that, or it's not
> > checking to make
> > sure it's a directory when it checks.  I don't mind tracking
> > this one down
> > and submitting a bug fix, but I thought I ought to find out
> > if it's been
> > heard of or fixed, etc.
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[Corinna Vinschen]

On Jun  5 09:00, Lange, Jan-Erik wrote:
> Hello all,
> 
> I tried to make a binary of a softcore processor called J1: http://excamera.com/sphinx/fpga-j1.html
> 
> I installed the latest cygwin version available and all the devel packages. 
> 
> Doing "make j1.bin" I get:
> 
> 3 [main] gforth 4824 dtable::stdio_init: couldn't make stderr distinct from stdout
    ^^^^^^^^^
There should have been more text, along the lines of ", Windows error X"
What's X?  This message occurs if the stdout and stderr handle are the
same, and a DuplicateHandle on the stderr handle failed for reason X.
Apart from that, the message itself is not dangerous and the gforth
binary should run normally, except that stdout == stderr handle under
the hood.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Problem with make

[Lange, Jan-Erik]

Hello all,

I tried to make a binary of a softcore processor called J1: http://excamera.com/sphinx/fpga-j1.html

I installed the latest cygwin version available and all the devel packages. 

Doing "make j1.bin" I get:

3 [main] gforth 4824 dtable::stdio_init: couldn't make stderr distinct from stdout

I'm executing the cygwin terminal directly on my computer. I already searched for a solution in the archive, but only found hints, that it could be an incompatibility issue when updating parts of cygwin (I installed it completely new) or I you execute the bash from a telnet client.

I use Windows 7 Ultimate service pack 1. Do you have an idea how to solve this problem?

Regards,
Jan
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

problem with make

[Jason Morgan]

Hi,


I'm having a problem using Cygwin as a platform for gcc running as a cross
compiler.

When doing make dep on a kernel tree, the following happens.

On the make line dep-files, the make file reads

dep-files:
	scripts/mkdep archdep include/linux/version.h
	scripts/mkdep -- init/*.c > .depend
	scripts/mkdep -- `find $(FINDHPATH) -name SCCS -prune -o -follow
-name \*.h ! -name modversions.h -print` > .hdepend
	$(MAKE) $(patsubst %,_sfdep_%,$(SUBDIRS))
_FASTDEP_ALL_SUB_DIRS="$(SUBD
ifdef CONFIG_MODVERSIONS
	$(MAKE) update-modverfile
endif


Its the third line causing the problem where the result of find
scripts/mkdep is a result of a find.

The error is:
scripts/mkdep: error 22

This error seems to come from the shell (bash)

The 'find' works OK on its own, and the previous two 'mkdep's' do as well.
So the only conslusion is the resulting
command line from the find is upsetting the shell when it passes the
parameters into mkdep.

Isolating this one line into a shell script seem to support this theory.

Bash in my cygwin is version 2.05a.0(3)



Any help appreciated,

Jason.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problem with make

[Earnie Boyd]

Ralf Habacker wrote:
> 
> > -----Original Message-----
> > From: cygwin-apps-owner@cygwin.com
> > [mailto:cygwin-apps-owner@cygwin.com]On Behalf Of Christopher Faylor
> > Sent: Tuesday, December 04, 2001 4:57 PM
> > To: cygwin-apps@cygwin.com
> > Subject: Re: problem with make
> >
> >
> > On Tue, Dec 04, 2001 at 08:14:04PM +1100, Robert Collins wrote:
> > >----- Original Message -----
> > >From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > >>
> > >> Does anyone have an idea for fixing this ? I have no problem to fix
> > >this, if somebody could
> > >> give me a direction where I have to look on.
> > >
> > >Use linux or get the KDE team to fix their makefiles. You _could_ try
> > >the cygwin=case_insensitive (spelling?) flag. The core problem though is
> > >that that use they are making of the filesystem is invalid for case
> > >insensitive filesystems - and windows isn't the only one around.
> >
> > Also, please use cygwin@cygwin.com for this type of bug reporting.  This
> > is not an applicable topic for cygwin-apps.
> >
> >From the mailing list page: cygwin-apps: a by-approval developers list for discussing issues
> regarding applications that are distributed with the Cygwin DLL.
> 
> Is "make" an application distributed with cygwin ? :-)
> 

Again, wrong list.  This isn't discussing the applications that are
being developed or ported by or to Cygwin.  To ask this question tells
me you are not a developer or maintainer of Cygwin applications so posts
to this list are off limits.  General questions about Cygwin or
applications distributed via the Cygwin setup are to be posted to
cygwin@cygwin.com.  I'm sure Chris would be more than happy to block
anyone with repeated offenses.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problem with make

[Christopher Faylor]

On Wed, Mar 14, 2001 at 07:54:21PM -0700, Mark Paulus wrote:
>[snip]under linux, make is calling g++ by default for files with a .cc
>extension, but under cygwin, make is calling gcc by default.  Does
>anyone know what the rationale is for this "exceptional" behaviour
>under cygwin??

Yep.  It's a bug in the Cygwin version of make.  It looks like there is
a typo in the make sources (specifically default.c).  I thought I'd
corrected this in the past but somehow it slipped by.

I've fixed this and it should be in the next version of cygwin make.  I
don't have a release date for this but it should be in the next couple
of weeks.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Problem with make

[Mark Paulus]

I have noticed a problem with make.  Here goes:

I have a small program, hello.cc:

-------------------[ code ]-------------------------------------------
#include <iostream.h>
#include <stdio.h>

void main (void)
{
    cout << "Hello World!!" << endl;
}
-------------------[ end code ]-------------------------------------

Now, when I do a 'make hello', 
under debian everything works fine, and I get an
executable called hello. which I can run.
Under cygwin, I do not see the same behaviour.
Instead, what I see is:

gcc     hello.cc   -o hello
/cygdrive/c/WINDOWS/TEMP/ccYbTAo7.o(.text+0x1f):hello.cc: undefined reference to
 `endl(ostream &)'
/cygdrive/c/WINDOWS/TEMP/ccYbTAo7.o(.text+0x2c):hello.cc: undefined reference to
 `cout'
/cygdrive/c/WINDOWS/TEMP/ccYbTAo7.o(.text+0x31):hello.cc: undefined reference to
 `ostream::operator<<(char const *)'
collect2: ld returned 1 exit status
make: *** [hello] Error 1

After further investigation, what is going on is that under linux, make is calling g++ by default
for files with a .cc extension, but under cygwin, make is calling gcc by default.  Does anyone 
know what the rationale is for this "exceptional" behaviour under cygwin??



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: problem with make

[Lassi A. Tuura]

> It preserves the trailing spaces when the quotes are not used and I believe
> it shouldn't.  I wrote the email with quotes to emphasize the trailing
> zeros.

(Spaces, not zeros.)  Actually I answered wrong earlier, the fact that
you get spaces has nothing to do with the comment at the end of the
line.  GNU make simply preserves trailing white-space in a variable
value.  In the manual at "Using Variables" -> "Flavors", you'll find:

>>  You can also use [simply expanded variables] to introduce
>>  controlled leading whitespace into variable values.  Leading
>>  whitespace characters are discarded from your input before
>>  substitution of variable references and function calls; this
>>  means you can include leading spaces in a variable value by
>>  protecting them with variable references, like this:
>>
>>     nullstring :=
>>     space := $(nullstring) # end of the line
>>
>>  Here the value of the variable `space' is precisely one
>>  space.  The comment `# end of the line' is included here
>>  just for clarity.  Since trailing space characters are *not*
>>  stripped from variable values, just a space at the end of
>>  the line would have the same effect (but be rather hard to
>>  read).  If you put whitespace at the end of a variable
>>  value, it is a good idea to put a comment like that at the
>>  end of the line to make your intent clear.  Conversely, if
>>  you do *not* want any whitespace characters at the end of
>>  your variable value, you must remember not to put a random
>>  comment on the end of the line after some whitespace, such
>>  as this:
>>
>>     dir := /foo/bar    # directory to put the frobs in
>>
>>  Here the value of the variable `dir' is `/foo/bar    ' (with
>>  four trailing spaces), which was probably not the intention.
>>  (Imagine something like `$(dir)/file' with this definition!)

Live and learn.  Hope that clarifies the issue.  If you have further
questions on this, it would be better to continue the discussion on the
GNU make lists (help-make@gnu.org or bug-make@gnu.org), not here.

Cheers,
//lat
-- 
I am ready to meet my Maker.  Whether my Maker is prepared for the
great ordeal of meeting me is another matter.  --Winston Churchill

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: problem with make

[Brian Pollard]

It preserves the trailing spaces when the quotes are not used and I believe
it shouldn't.  I wrote the email with quotes to emphasize the trailing
zeros.

thanx
	Brian

so
hehe=.                #comment
makes hehe stored as ".               "
when i think it should only store "." as make does in solarias




-----Original Message-----
From: Lassi A. Tuura [ mailto:lassi.tuura@cern.ch ]
Sent: Wednesday, August 16, 2000 11:01 PM
To: Heribert Dahms
Cc: Brian Pollard; cygwin@sourceware.cygnus.com
Subject: Re: problem with make


> I never used trailing comments and $(strip) is also new to me,
> but is it really true that the obvious quoted
> var="value      "
> does NOT preserve trailing spaces?

Well, it does preserve the spaces -- but only because as far as make is
concerned, $(var) is `"value      "', quotes and all.  In other words,
there are no trailing spaces in your example :-)

Cheers and have a great week,
//lat
-- 
C makes it too easy to slice your fingers off, and programmers all
over the world are doing so with great regularity.  --Steven Bellovin

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problem with make

[Lassi A. Tuura]

> I never used trailing comments and $(strip) is also new to me,
> but is it really true that the obvious quoted
> var="value      "
> does NOT preserve trailing spaces?

Well, it does preserve the spaces -- but only because as far as make is
concerned, $(var) is `"value      "', quotes and all.  In other words,
there are no trailing spaces in your example :-)

Cheers and have a great week,
//lat
-- 
C makes it too easy to slice your fingers off, and programmers all
over the world are doing so with great regularity.  --Steven Bellovin

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: problem with make

[Noel L Yap]

heribert_dahms@icon-gmbh.de on 2000.08.16 16:09:02
>I never used trailing comments and $(strip) is also new to me,
>but is it really true that the obvious quoted
>var="value      "
>does NOT preserve trailing spaces?

Yes.  The double quotes will be part of $(var) so there are no trailing spaces.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problem with make

[Noel L Yap]

lassi.tuura@cern.ch on 2000.08.16 07:34:25
>>         hehe=.           #some comment
>> hehe stores ".            " instead of "./"
>
>This is documented make behaviour -- and in fact the only way to get
>trailing space to a variable value.  As someone else already replied, if
>that's not what you want, just move the comment to another line or use
>$(strip).

Well, ..., actually, you can:
BLANK:=
SPACE:=$(BLANK) $(BLANK)
STUFF:=.$(SPACE)$(SPACE)

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: problem with make

[Heribert Dahms]

Hi,

I never used trailing comments and $(strip) is also new to me,
but is it really true that the obvious quoted
var="value      "
does NOT preserve trailing spaces?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Lassi A. Tuura [SMTP:lassi.tuura@cern.ch]
> Sent:	Wednesday, August 16, 2000 13:34
> To:	Brian Pollard
> Cc:	cygwin@sourceware.cygnus.com
> Subject:	Re: problem with make
> 
> >         hehe=.           #some comment
> > hehe stores ".            " instead of "./"
> 
> This is documented make behaviour -- and in fact the only way to get
> trailing space to a variable value.  As someone else already replied,
> if
> that's not what you want, just move the comment to another line or use
> $(strip).
> 
> Hope this helps,
> //lat
> -- 
> A new scientific truth does not triumph by convincing its
> opponents and making them see the light, but rather because
> its opponents eventually die, and a new generation grows up
> that is familiar with it.  --Planck, 1949
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problem with make

[Lassi A. Tuura]

>         hehe=.           #some comment
> hehe stores ".            " instead of "./"

This is documented make behaviour -- and in fact the only way to get
trailing space to a variable value.  As someone else already replied, if
that's not what you want, just move the comment to another line or use
$(strip).

Hope this helps,
//lat
-- 
A new scientific truth does not triumph by convincing its
opponents and making them see the light, but rather because
its opponents eventually die, and a new generation grows up
that is familiar with it.  --Planck, 1949

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problem with make

[Avraham H. Fraenkel]

You can do :

1) put the remark in the line before.
   in such case no trilling balnks are added to the macro.
2) if you are using GNU make , there is  a function called strip, so you
   can do:
 	$(strip $(hehe))/mine.h


     Avraham

-------------------------------------
Avraham H. Fraenkel 

comMATCH: www.comMATCH.com
-------------------------------------

On Tue, 15 Aug 2000, Brian Pollard wrote:

> when using a make file, assignment statements such as:
> 
> 	hehe=.           #some comment
> 
> 	$(hehe)/mine.h
> hehe stores ".            " instead of "./"
> 
> this causes problems when accessing something such as:
> 
> 
> because it is interpreted as ".           /mine.h"
> 
> 
> I would guess that the source code needs to be modified, any suggestions???
> 
> Thanks,
> 	Brian
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

problem with make

[Brian Pollard]

when using a make file, assignment statements such as:

	hehe=.           #some comment

hehe stores ".            " instead of "./"

this causes problems when accessing something such as:

	$(hehe)/mine.h

because it is interpreted as ".           /mine.h"


I would guess that the source code needs to be modified, any suggestions???

Thanks,
	Brian

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[Phil Edwards]

> Anyhow, Turns out that in the directory where jikes.exe is, he had a
> directory named jikes also - make was trying to execute it, but bash wasn't.

Bash knows better, is all.  It seems to add ".exe" to program calls just
fine.  Make isn't aware that it's running under Lose32, so when it looks
for "jikes" that's what it finds.

> So obviously, this is a bug in make - it must be looking for a program named
> jikes before jikes.exe - I guess.  Either that, or it's not checking to make
> sure it's a directory when it checks.  

It's both of those.  The first is not really a bug per se (I bet that if your
makefile called jikes.exe instead, both you and your coworker would be okay).
The second should probably be tweaked, although that would usually just be
unnecessary overhead.

I am not knowledgeble about the ways of Cygwin.  Perhaps there is a better
way when building GNU make to change that behavior.  I have "solved" a
number of GNU make problems by just running it inside bash.exe than from
cmd.exe directly.


phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[N8TM]

In a message dated 6/9/99 9:45:12 AM Pacific Daylight Time, Kim.Brown@wl.com 
writes:

> I have found GNU make to be buggy with some makefiles, especially those
>  generated by PERL install packages.  I just use nmake from microsoft 
without
>  problems.  Anyone else have problems with GNU make?

Do you mean gnu make as in b20.1?  It has serious problems with recursive 
makefiles (e.g. egcs configure and build).  For my purposes, replacing it 
with make-3.77 has been satisfactory,  at least when running NT or W2K.  We 
have had hints here that a modified make-3.77 will be in the next major 
version of cygwin.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Problem with make

[Blob, Dave]

Ok, this is a wierd one, so bear with me.

I've been using cygwin to do some java development with a coworker.  For a
while, we were just doing "jikes *.java", and had no problems.  As the
project grew, we split things into packages and added Makefiles to build the
whole project.  The problem that showed up was that it worked for me, but
not for him - he'd get an error message each time that said "jikes -
permission denied".  The same command that make was trying to execute worked
from the command line though... Perplexing.  We switched to javac - worked
fine.  

Anyhow, Turns out that in the directory where jikes.exe is, he had a
directory named jikes also - make was trying to execute it, but bash wasn't.


So obviously, this is a bug in make - it must be looking for a program named
jikes before jikes.exe - I guess.  Either that, or it's not checking to make
sure it's a directory when it checks.  I don't mind tracking this one down
and submitting a bug fix, but I thought I ought to find out if it's been
heard of or fixed, etc.

Thanks,
Dave

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Problem with make

[Brown, Kim]

My version of GNU make is 3.75 (supplied with b20.1 I think).  I did not
know there was a 3.77 out there.  Looks like I need to upgrade and see if my
problems with makefiles go away.

> -----Original Message-----
> From: N8TM@aol.com [ mailto:N8TM@aol.com ]
> Sent: Thursday, June 10, 1999 2:12 AM
> To: Kim.Brown@wl.com; Dave.Blob@gs.com; cygwin@sourceware.cygnus.com
> Subject: Re: Problem with make
> 
> 
> In a message dated 6/9/99 9:45:12 AM Pacific Daylight Time, 
> Kim.Brown@wl.com 
> writes:
> 
> > I have found GNU make to be buggy with some makefiles, 
> especially those
> >  generated by PERL install packages.  I just use nmake from 
> microsoft 
> without
> >  problems.  Anyone else have problems with GNU make?
> 
> Do you mean gnu make as in b20.1?  It has serious problems 
> with recursive 
> makefiles (e.g. egcs configure and build).  For my purposes, 
> replacing it 
> with make-3.77 has been satisfactory, 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Problem with make

[Brown, Kim]

My version of GNU make is 3.75 (supplied with b20.1 I think).  I did not
know there was a 3.77 out there.  Looks like I need to upgrade and see if my
problems with makefiles go away.

> -----Original Message-----
> From: N8TM@aol.com [ mailto:N8TM@aol.com ]
> Sent: Thursday, June 10, 1999 2:12 AM
> To: Kim.Brown@wl.com; Dave.Blob@gs.com; cygwin@sourceware.cygnus.com
> Subject: Re: Problem with make
> 
> 
> In a message dated 6/9/99 9:45:12 AM Pacific Daylight Time, 
> Kim.Brown@wl.com 
> writes:
> 
> > I have found GNU make to be buggy with some makefiles, 
> especially those
> >  generated by PERL install packages.  I just use nmake from 
> microsoft 
> without
> >  problems.  Anyone else have problems with GNU make?
> 
> Do you mean gnu make as in b20.1?  It has serious problems 
> with recursive 
> makefiles (e.g. egcs configure and build).  For my purposes, 
> replacing it 
> with make-3.77 has been satisfactory, 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[N8TM]

In a message dated 6/9/99 9:45:12 AM Pacific Daylight Time, Kim.Brown@wl.com 
writes:

> I have found GNU make to be buggy with some makefiles, especially those
>  generated by PERL install packages.  I just use nmake from microsoft 
without
>  problems.  Anyone else have problems with GNU make?

Do you mean gnu make as in b20.1?  It has serious problems with recursive 
makefiles (e.g. egcs configure and build).  For my purposes, replacing it 
with make-3.77 has been satisfactory,  at least when running NT or W2K.  We 
have had hints here that a modified make-3.77 will be in the next major 
version of cygwin.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem with make

[Phil Edwards]

> Anyhow, Turns out that in the directory where jikes.exe is, he had a
> directory named jikes also - make was trying to execute it, but bash wasn't.

Bash knows better, is all.  It seems to add ".exe" to program calls just
fine.  Make isn't aware that it's running under Lose32, so when it looks
for "jikes" that's what it finds.

> So obviously, this is a bug in make - it must be looking for a program named
> jikes before jikes.exe - I guess.  Either that, or it's not checking to make
> sure it's a directory when it checks.  

It's both of those.  The first is not really a bug per se (I bet that if your
makefile called jikes.exe instead, both you and your coworker would be okay).
The second should probably be tweaked, although that would usually just be
unnecessary overhead.

I am not knowledgeble about the ways of Cygwin.  Perhaps there is a better
way when building GNU make to change that behavior.  I have "solved" a
number of GNU make problems by just running it inside bash.exe than from
cmd.exe directly.


phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Problem with make

[Blob, Dave]

Ok, this is a wierd one, so bear with me.

I've been using cygwin to do some java development with a coworker.  For a
while, we were just doing "jikes *.java", and had no problems.  As the
project grew, we split things into packages and added Makefiles to build the
whole project.  The problem that showed up was that it worked for me, but
not for him - he'd get an error message each time that said "jikes -
permission denied".  The same command that make was trying to execute worked
from the command line though... Perplexing.  We switched to javac - worked
fine.  

Anyhow, Turns out that in the directory where jikes.exe is, he had a
directory named jikes also - make was trying to execute it, but bash wasn't.


So obviously, this is a bug in make - it must be looking for a program named
jikes before jikes.exe - I guess.  Either that, or it's not checking to make
sure it's a directory when it checks.  I don't mind tracking this one down
and submitting a bug fix, but I thought I ought to find out if it's been
heard of or fixed, etc.

Thanks,
Dave

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problem with make

[Pete Jordan]

Stuart <stuart@its.washington.edu> wrote:

> javac Applet.java -d e:/public_html
> 
> which says compile Applet.java to Applet.class, putting the class file
> in directory e:/public_html
> 
> Now, even with mount points and/or the use of the //e/public_html
> syntax, javac refuses to recognise this form of path.  I expected the
> mount point not to work and it says on the Cygwin32 web page that only
> cygwin32 tools know about mounting, and the JDK isnt such a toolset.
> So I guess I'm stuffed!

You could try wrapping javac in my debash program (you'll find it at 
http://www.horus.cix.co.uk/download/debash-1.1.tar.gz ) which is intended 
to deal with exactly this problem, translating GNU-Win32 pathnames into 
DOS format.

HTH,

Pete Jordan ~ Horus Communications Ltd ~ http://www.horus.cix.co.uk/

"There a few things that a committee can do well. There are very many
 more things that a committee will always do badly. And killing a boar
 is one of the things that no committee should ever try at all."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: problem with make

[Stuart]

Hi all and thanks for the help.  I still haven't found a solution to my
make problem, but I think I need to expand on the prob as it mixes
cygwin32 and non-cygwin32 tools:

The topic is java development, using Sun's JDK for Windoze.  A typical
compiler invocation would be

javac Applet.java -d e:/public_html

which says compile Applet.java to Applet.class, putting the class file
in directory e:/public_html

Now, even with mount points and/or the use of the //e/public_html
syntax, javac refuses to recognise this form of path.  I expected the
mount point not to work and it says on the Cygwin32 web page that only
cygwin32 tools know about mounting, and the JDK isnt such a toolset.
So I guess I'm stuffed!

Any more pointers and/or inspiration well appreciated. cheers

-- 
Stuart Maclean, Research Associate
University of Washington
ITS Research Program, College of Engineering
Box 352500
Seattle, WA 98195-2500
Tel: (206) 543-0637
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

problem with make

[Stuart]

Hi all, I'm a newbie on this list, and to Windoze in general.  Porting
some make stuff over from Unix, I've stumbled across a makefile syntax
problem.  To declare a generic rule, I'd do

%.class : %.java

now, the class file may be in a diff directory.  I am used to

DEPDIR = /home/stu/files/stuff

$(DEPDIR)/%.class : %.java
	build class file from java src

of course on bloody NT, DEPDIR may contain a colon, e.g

DEPDIR = e:\files\stuff

this blows up make since the substituted line reads

e:\files\stuff\%.class : %.java

which has a colon where one is not expected.  I could remove the
depdir from the target name and do a manual move of the class file
after compiling it but I feel that's messy.

I have tried all sorts to escape the colon but nothing works.  The
make error is "missing separator"

Any help gratefully appreciated...


-- 
Stuart Maclean, Research Associate
University of Washington
ITS Research Program, College of Engineering
Box 352500
Seattle, WA 98195-2500
Tel: (206) 543-0637
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".