PS

[Guillaume MARTIN]

I tried to write "mkdir -p" instead of "mkdirhier", it seems to work, 
but it is really the same ?


Thank you,

Guillaume


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

Looking for mkdirhier !

[Guillaume MARTIN]

Hello,

I'd like to translate Firefox. I don't understand anything in Linux or 
so, I just follow the documentation !


So, I have to execute the command :
MOZ_CO_PROJECT=browser make -f tools/l10n/l10n.mk create-eo

But cygwin writes :
[...]
/bin/sh: line 5: mkdirhier : command not found.
[...]

Effectively, in l10n.mk, it's written :
[...]
mkdirhier ../l10n/$*/$$mod; \
[...]

and I don't find mkdirhier in my cygwin directory...

1) I tried to install mkdirhier in the setup, but I did'nt find it...

2) I tried to search a solution by
mkdirhier site:cygwin.com inurl:ml/cygwin
... but I don't undersand anything in this jungle !!

How could I install mkdir in cygwin ?

Thank you very much for your help !

Guillaume MARTIN



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

Re: My script doesn't work under cygwin cron

[liora milbaum]

Hi Igor,

I have changed the user who runs cron to myself. I think that this should
eliminate all permissions
problems.

Please find attached the output of cygcheck.

Thanks for the assitance,
Liora


Igor Peshansky wrote:
> 
> On Sun, 20 Aug 2006, liora milbaum wrote:
> 
>> It works fine under the cygwin shell not under cron.
>>
>> This is the output of the command:
>>
>> Can't load '/usr/lib/perl5/site_perl/5.8/cygwin/auto/GD/GD.dll' for
>> module GD: No such file or directory at
>> /usr/lib/perl5/5.8/cygwin/DynaLoader.pm line 230.
>>  at /usr/local/bin/cl_graph line 12
>> Compilation failed in require at /usr/local/bin/cl_graph line 12.
>> BEGIN failed--compilation aborted at /usr/local/bin/cl_graph line 12.
> 
> Hi, Liora,
> 
> Cron runs as the SYSTEM user.  Make sure you have enough permissions for
> SYSTEM to access the /usr/lib/perl5/... hierarchy.  You may also have a
> mount issue, where the required mounts are missing for the SYSTEM user
> (e.g., if you initially installed Cygwin for "Just me").
> 
> In fact, you should have read and followed the Cygwin problem reporting
> guidelines at , especially the part that
> asks you to attach the output of "cygcheck -svr" on your machine -- that
> output would have given us the answer to at least the mount question.
>   Igor
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED] | [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  Igor Peshansky, Ph.D. (name changed!)
>  |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends
> compte."
> "But no -- you are no fool; you call yourself a fool, there's proof enough
> in
> that!" -- Rostand, "Cyrano de Bergerac"
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 
> 
http://www.nabble.com/user-files/235708/cgycheck.out cgycheck.out 
-- 
View this message in context: 
http://www.nabble.com/My-script-doesn%27t-work-under-cygwin-cron-tf2135910.html#a5920113
Sent from the Cygwin Users forum at Nabble.com.


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

Re: removing Cygwin: the nuclear option

[Igor Peshansky]

On Mon, 22 Aug 2006, Paul S R Chisholm wrote:

> I'm working on an automated Cygwin install and uninstall. I think I've
> got the uninstall, but I wanted to know if my approach is wise.
>
> The first step is to run "cygrunsrv --list" to find all the Cygwin
> services, and then run "cygrunsrv --stop" and "cygrunsrv --remove" on
> each of them.

Sounds right.  You might also want to terminate any other (non-service)
Cygwin processes while you're at it, and also check for inetd (which runs
without cygrunsrv, and thus won't show up in cygrunsrv's list).

> The second is to remove all the files (this is a line from a Windows
> batch file, not a Cygwin shell script):
>
> rmdir /s /q %CYGWIN_HOME%

As the FAQ mentions, you might have permission issues with the above.  See
below.

> The third is to get rid of all the registry entries:
>
> reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions" /f
> reg delete "HKEY_CURRENT_USER\Software\Cygnus Solutions" /f
>
> The "reg" command is installed on all systems running Windows XP and
> Windows Server 2003, and can be installed on Windows 2000. I understand
> that's not good enough for all cases, but it suits my needs.

FWIW, you can use Cygwin's regtool to accomplish the same (and it won't
need the mounts that are stored in the registry).  Obviously, you'll have
to do this *before* removing the Cygwin root directory.

> Too much, too little, just right?  --PSRC

Basically, if you automate the recipe in
, you should
be fine.
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: cygwin problem - installation halting at 00ash.sh

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ask the list, not me: http://cygwin.com/acronyms/#PPIOSPE

According to Caleb Knoll on 8/20/2006 8:15 PM:
> I know this post was from about a year ago, but I'm having the exact
> same problem as you described in your post:
> 
>  
> 
> http://www.cygwin.com/ml/cygwin/2005-09/msg00164.html
> 
>  
> 
> Did you find a resolution to this problem?
> 
>  

For starters, you didn't follow the directions in that post.  Particularly
the ones about posting the output of 'cygcheck -svr' as a text attachment.

> 
>  
> 
> I'm using the latest (v1.5.21-1) setup and the installation hangs at 98% at
> 
> Running ...
> 
> No package
> 
> /etc/postinstall/00ash.sh
> 
>  
> 
> The same thing as you described?
> 
>  
> 
> Any help would be great!
> 
>  
> 
> Thanks,
> 
> Caleb
> 

Also, there are newer snapshots of setup.exe available, which give better
details in the log file of the setup attempt.  Try using the latest
snapshot, and post your success or failure with it.
http://cygwin.com/setup/snapshots/

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE6nv184KuGfSFAYARAhkoAKCSQhaOBUjzT9wZxTOoPpv5amLlegCgrQIz
f3pWBcgp4MGun/Ply48Q5ZA=
=i5yY
-END PGP SIGNATURE-

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

Installation from hardisk, is it possible?

[steven woody]

hi,

i am going to install a copy of cygwin in my notebook, but for some
reasons the computer can not access internet, so i think i have to
download a full suites of installation files on to my desktop computer
and then transfer them to the notebook before i can install from
there. is it possible and how?  thanks.

--
woody

then sun rose thinly from the sea and the old man could see the other
boats, low on the water and well in toward the shore, spread out
across the current.

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

removing Cygwin: the nuclear option

[Paul S R Chisholm]

I'm working on an automated Cygwin install and uninstall. I think I've got the

uninstall, but I wanted to know if my approach is wise.



The first step is to run "cygrunsrv --list" to find all the Cygwin services,

and then run "cygrunsrv --stop" and "cygrunsrv --remove" on each of them.



The second is to remove all the files (this is a line from a Windows batch

file, not a Cygwin shell script):



rmdir /s /q %CYGWIN_HOME%



The third is to get rid of all the registry entries:



reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions" /f

reg delete "HKEY_CURRENT_USER\Software\Cygnus Solutions" /f



The "reg" command is installed on all systems running Windows XP and Windows

Server 2003, and can be installed on Windows 2000. I understand that's not good

enough for all cases, but it suits my needs.



Too much, too little, just right?  --PSRC

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

attempt at command-line-based Cygwin installation

[Paul S R Chisholm]

I'm trying to do a custom, automated Cygwin install. I've read some earlier

messages on this list and elsewhere, and I thought I knew what to do, but it

hasn't worked out.



I did a manual GUI "download without installing" with the packages I wanted,

into C:\Download\Cygwin; then I ran (all on one line):



setup.exe --local-install --quiet-mode --no-shortcuts --root C:\Cygwin

--local-package-directory C:\Download\Cygwin



Good news: It put some file under C:\Cygwin\etc\ (I can't remember which). Bad

news: It didn't install anything else, and it certainly didn't install any 

packages. On reflection, that kind of makes sense. If I was doing a manual GUI

"Install from local directory", the next thing I would have to do is select

which downloaded packages should be installed; but in my command line

installation, I haven't told it to install any particular packages!



What am I missing?  --PSRC



P.S.: There were other details that didn't work out as well as I'd hoped.

Running setup.exe *starts* the installation; I don't know how to wail until the

installation is complete. I was also surprised that the "local install"

downloaded dozens of packages. Last, and definitely least, I was hoping the GUI

would never appear. I'll address this last issue through a process known as

"managing expectations".-)

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

Re: Update GCC in Cygwin?

[Larry Hall (Cygwin)]

Chuck Chopp wrote:
Are there any issues associated with updating applications that were 
included as part of the Cygwin installation?


I'm just beginning to get familiar with Cygwin, and I have some C++ code 
that is primarily being built using Visual C/C++, but I also need to 
test it for portability for use with GCC on Linux and Mac OS X.  
Initially, I was thinking of just using GCC under Cygwin to do the basic 
compile to make sure that I get a clean compilation pass before I set up 
actual target systems to do a full build on.


What I noticed, though, is that the GCC version that's included with 
Cygwin is older than what will be used on Linux & OS X, so I was 
interested in whether or not there's problems with taking an updated 
distro kit for GCC on  a Linux x86 platform and installing it within 
Cygwin.


Is this something that should be do-able w/o problems?  Or, do I need a 
GCC build that's made explicitly for use in Cygwin?



You need gcc and friends built for the host platform, Cygwin in this case.
Cygwin will not run Linux executables.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

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

Update GCC in Cygwin?

[Chuck Chopp]

Are there any issues associated with updating applications that were 
included as part of the Cygwin installation?


I'm just beginning to get familiar with Cygwin, and I have some C++ code 
that is primarily being built using Visual C/C++, but I also need to test it 
for portability for use with GCC on Linux and Mac OS X.  Initially, I was 
thinking of just using GCC under Cygwin to do the basic compile to make sure 
that I get a clean compilation pass before I set up actual target systems to 
do a full build on.


What I noticed, though, is that the GCC version that's included with Cygwin 
is older than what will be used on Linux & OS X, so I was interested in 
whether or not there's problems with taking an updated distro kit for GCC on 
 a Linux x86 platform and installing it within Cygwin.


Is this something that should be do-able w/o problems?  Or, do I need a GCC 
build that's made explicitly for use in Cygwin?



TIA,

Chuck
--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road  864 801 2774 fax
Greer, SC  29651

"Racing to save lives"
The Leukemia & Lymphoma Society - Team in Training
http://www.active.com/donate/tntsc/tntscCChopp

Do not send me unsolicited commercial email.


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

Re: change in behavior of make from 3.80 to 3.81

[Christopher Faylor]

On Mon, Aug 21, 2006 at 04:40:03PM -0400, William A. Hoffman wrote:
>My suggestion was, to send notice of the coming change before the
>change was made, not after.  That is all.  IMO, the make issue is over.
>I was just trying to make a suggestion to avoid flame wars like this in
>the future.  I don't think it is enjoyable or productive for anyone
>involved.

I guess I can't get away without responding to this.

It is very odd to me that someone who wandered into the discussion late
and is still asking for clarification about what happened (in the
make-w32 mailing list) would feel empowered to suggest that earlier
communication would have helped.  However:

1) I thought (and still do think) that MinGW make was an acceptable
   solution for people who use only MS-DOS paths.

2) The notion that the Cygwin user community would have done something
   proactive and submitted a patch upstream is obviously false. 

  a) You wouldn't have done it since you weren't paying attention.
  b) No one who has responded for the last month has shown any
 inclination towards doing anything proactive like that.

3) Complaints about MS-DOS paths aside, I did want to get a new version
   of make released because people had been reporting fixes in make 3.81
   for some time.  I'm not interested in delaying a release for something
   like MS-DOS paths.  I've frequently gone on record about not caring much
   about using MS-DOSisms in what is supposed to be a UNIX/Linux-like
   environment.

So, as you can see, I do not agree with your suggestion, I have no plans
on doing anything like this for make in the future, and suggest that,
therefore, there is no reason to continue with this "What If" scenario.

cgf

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

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

At 04:24 PM 8/21/2006, Chris Taylor wrote:

>Actually, Dave does have the nub of it. His assertions are accurate in your 
>case.
>
>There have been many messages to this list, as well as the release note that 
>specifically mentioned that MSDOS paths were no longer supported.
>Given that these _were not_ a part of official Make, but were instead 
>implemented by patches maintained by cgf, it's not unreasonable for the 
>maintainer to say enough is enough.
>Even more so given that cygwin is for giving you POSIX functions in windows.. 
>DOS paths have no relevance in a POSIX environment. The underlying OS isn't 
>relevant.

Do you know what is in the official Make?  The support for windows paths is 
already
in official Make, and has been for some time.  It was just not turned on for 
the cygwin 
build of make.   In the future it will be.

>If a working patch makes it into upstream, or is available for inclusion and 
>is clean, w/o affecting anything else, then I have no doubt that cgf will 
>consider including it in the next release, but if people had actually read the 
>original release notes, then this would not be an issue.

The release notes said the feature was dropped, and to use mingw make.
http://www.cygwin.com/ml/cygwin-announce/2006-07/msg8.html
It did not say if you get the upstream make to add support then the
feature can be maintained.   It did say if you have questions or
comments send them to the cygwin mailing list.   


>Also, Dave commented earlier on your email saying an email should have been 
>sent to the list saying that these changes were going to happen.
>It was. It's called the 'release notes'. They go to cygwin-announce, if I 
>recall correctly.. Maybe you should subscribe to this one?

My suggestion was, to send notice of the coming change before
the change was made, not after.  That is all.  IMO, the make issue
is over.  I was just trying to make a suggestion to avoid
flame wars like this in the future.  I don't think it is enjoyable
or productive for anyone involved.

-Bill


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

Re: change in behavior of make from 3.80 to 3.81

[Igor Peshansky]

On Mon, 21 Aug 2006, Chris Taylor wrote:

> Also, Dave commented earlier on your email saying an email should have
> been sent to the list saying that these changes were going to happen.
> It was. It's called the 'release notes'. They go to cygwin-announce, if
> I recall correctly.. Maybe you should subscribe to this one?

No need -- cygwin-announce messages get forwarded to this list with
[ANNOUNCEMENT] prepended to them.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: change in behavior of make from 3.80 to 3.81

[Chris Taylor]

William A. Hoffman wrote:

At 02:57 PM 8/21/2006, Dave Korn wrote:

On 21 August 2006 18:58, William A. Hoffman wrote:



of, make is changing beware, it may have been noticed.  Let's face make
is not a project you expect to see a bunch of change happening on,
especially a change that breaks existing makefiles.

 Ah.  We have the nub of it.



No I don't think you have the nub of it yet. I still think that a simple
post about a major change being made to make may have helped avoid much of the
pain of this thread.   You have to admit that dropping a whole class of paths
from support is more likely to cause trouble than any of the other minor syntax
changes to gnu make that are not backwards compatible.  I would not expect:



foo: foo.c
   gcc foo.c -o foo



To stop working any time soon in make no matter what changes are made.
The basic format of makefiles is pretty much fixed, and has been around for
20 years or so.  See http://en.wikipedia.org/wiki/Make:



"POSIX includes standardization of the basic features and operation of the make 
utility "
That is the part of make I am talking about when I say the features of make are 
not
changing.



I and others (not exactly sure how many but more than one) did not expect:



foo: c:/foo.c
   cl c:/foo.c 



to stop working the make that came with cygwin.  And in the future it will
again be supported.  



I certainly realize that software changes, and that you have to break backwards
compatibility from time to time.   I am just saying that giving the user 
community
an opportunity to step up and make a fix would have been helpful, not necessary 
or
required, but helpful and not that hard to do. 



-Bill


Actually, Dave does have the nub of it. His assertions are accurate in 
your case.


There have been many messages to this list, as well as the release note 
that specifically mentioned that MSDOS paths were no longer supported.
Given that these _were not_ a part of official Make, but were instead 
implemented by patches maintained by cgf, it's not unreasonable for the 
maintainer to say enough is enough.
Even more so given that cygwin is for giving you POSIX functions in 
windows.. DOS paths have no relevance in a POSIX environment. The 
underlying OS isn't relevant.


If a working patch makes it into upstream, or is available for inclusion 
and is clean, w/o affecting anything else, then I have no doubt that cgf 
will consider including it in the next release, but if people had 
actually read the original release notes, then this would not be an issue.


Also, Dave commented earlier on your email saying an email should have 
been sent to the list saying that these changes were going to happen.
It was. It's called the 'release notes'. They go to cygwin-announce, if 
I recall correctly.. Maybe you should subscribe to this one?




One last thing.. Don't reply to me directly (or Dave for that matter); 
we're both on the list.. I set reply-to for a reason..



Chris/EqUaTe (NOT cgf)

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

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

At 02:57 PM 8/21/2006, Dave Korn wrote:
>On 21 August 2006 18:58, William A. Hoffman wrote:
>
>> of, make is changing beware, it may have been noticed.  Let's face make
>> is not a project you expect to see a bunch of change happening on,
>> especially a change that breaks existing makefiles.
>
>  Ah.  We have the nub of it.

No I don't think you have the nub of it yet. I still think that a simple
post about a major change being made to make may have helped avoid much of the
pain of this thread.   You have to admit that dropping a whole class of paths
from support is more likely to cause trouble than any of the other minor syntax
changes to gnu make that are not backwards compatible.  I would not expect:

foo: foo.c
   gcc foo.c -o foo

To stop working any time soon in make no matter what changes are made.
The basic format of makefiles is pretty much fixed, and has been around for
20 years or so.  See http://en.wikipedia.org/wiki/Make:

"POSIX includes standardization of the basic features and operation of the make 
utility "
That is the part of make I am talking about when I say the features of make are 
not
changing.

I and others (not exactly sure how many but more than one) did not expect:

foo: c:/foo.c
   cl c:/foo.c 

to stop working the make that came with cygwin.  And in the future it will
again be supported.  

I certainly realize that software changes, and that you have to break backwards
compatibility from time to time.   I am just saying that giving the user 
community
an opportunity to step up and make a fix would have been helpful, not necessary 
or
required, but helpful and not that hard to do. 

-Bill




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

Re: gcc-3.4.4 compile dietlibc error on cygwin

[Wang Yiping]

Dear Reads:

In my first letter, I just tried to cross-compiled the dietlibc in
cygwin. In order to cross-compile programs that depends on dietlibc
such as nash, one must get a HOST diet execution from the dietlibc and
then run diet some-arch-gcc yourfile.c.

Although dietlibc supports cross-compile, but It doesn't support
create host diet.exe in cygwin directly from it's Makefile. Just do
the following, you can get diet.exe then you can do cross-compiling
other programs depended on dietlibc.

1. patch the diet.c
$ diff -Nur diet.c diet-cygwin.c
--- diet.c  2004-07-29 06:40:21.0 -0400
+++ diet-cygwin.c   2006-08-19 22:27:13.46875 -0400
@@ -3,8 +3,8 @@
#include 
#include 
#include 
-#include 
-
+//#include 
+#define __write2 printf
#include "dietfeatures.h"

/* goal:

2. compile the diet.exe
$ i686-pc-cygwin-gcc diet-cygwin.c -I./include -DDIETHOME=\"/tmp/dietlibc-0.27\
" -DVERSION=\"dietlibc-0.27\" -o diet-cygwin

3. in your programs, change the diet name to your newly diet.exe
e.g. in  /tmp/mkinitrd-3.5.13/nash/Makefile
CC:=/tmp/dietlibc-0.27/diet-cygwin $(CC)
then do the cross-compiling, you will get the nash


Best Regards

Andy

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

RE: octave compiled with gcc-3.4.4-2 - error messages during make check

[Dave Korn]

On 21 August 2006 19:10, John W. Eaton wrote:

> On 21-Aug-2006, Dave Korn wrote:
> 
>> Then, keeping the
>> dll constant, try rolling your gcc install back to 3.4.4-1, building in a
>> fresh object dir, and running make check there.  Please let us know what
>> results you get.
> 
> This won't work for Octave because it is a victim of the std::string
> bug in the 3.4.4-1 package.  Without some fix for that problem, Octave
> segfaults on startup.

  Ah, so it would only fail every single test.  Fair enough; it would be very
hard to try and deduce if there was a problem caused by the -2 bugfix from
that limited evidence!

  Still worth trying a few different dll versions, though.  

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: change in behavior of make from 3.80 to 3.81

[Dave Korn]

On 21 August 2006 18:58, William A. Hoffman wrote:

> of, make is changing beware, it may have been noticed.  Let's face make
> is not a project you expect to see a bunch of change happening on,
> especially a change that breaks existing makefiles.

  Ah.  We have the nub of it.

  Make is not a project that /you/ expect to see a bunch of changes happening
on.  However, you speak only for yourself.

  Anyone who has read the docs or NEWS file or even the recent cygwin package
announcement, or visited the make homepage or read any of the mailing lists,
will be aware of the active development work on make.  There are half-a-dozen
*other* non-backwardly compatible changes in the pipeline coming up, which
nobody here has mentioned anything that would suggest they were even aware of,
but they were all listed in that recent announcement.

  In short, anyone whose opinion is based on research and fact, rather than
guesswork and wishful thinking, DOES expect make to be changing.

  Software *does* change.  It /needs/ to.  Developers like to do what they can
to keep backward compatibility, but sometimes it's best for the future
development of an application to just let some old feature go.  There has
never been any guarantee that nothing will ever change and everything will
work for ever, and that is why it is reckless and negligent to regularly use
setup.exe to indiscriminately upgrade all and everything you have installed
and running on a given system.

  So, your problem is that you were expecting reality to conform to your
unverified assumptions, and got all het up when it didn't, and now insist that
it is reality itself that is at fault for not being how you expected it to be,
and demand that nobody ever do anything and nothing ever change, so that you
need not be inconvenienced by your non-preparation.  That's not a reasonable
nor practical demand, and you should be able to understand why it gets short
shrift.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: octave compiled with gcc-3.4.4-2 - error messages during make check

[John W. Eaton]

On 21-Aug-2006, Dave Korn wrote:

| Then, keeping the
| dll constant, try rolling your gcc install back to 3.4.4-1, building in a
| fresh object dir, and running make check there.  Please let us know what
| results you get.

This won't work for Octave because it is a victim of the std::string
bug in the 3.4.4-1 package.  Without some fix for that problem, Octave
segfaults on startup.

jwe

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

Re: problem with malloc/realloc. Pls help.

[Mark Fisher]

On 8/21/06, Omololu wrote:

Hi,
 i have the following code. it compiles with gcc in Cygwin but the contents of
the array ifitQ that I get after the call to the subroutine readCharges2 is
gibberish.


looks like a passing by reference problem. if you add debug to look
at the address of ifitQ at all stages, you'll notice that the copy pointer
in readCharges2 gets changed, but that isn't the same pointer as in
the calling block.

see section 2.17 of http://www.lysator.liu.se/c/c-faq/c-2.html

i don't understand how linux is getting it right tbh.

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

Re: problem with malloc/realloc. Pls help.

[Igor Peshansky]

On Mon, 21 Aug 2006, Igor Peshansky wrote:

> On Mon, 21 Aug 2006, Omololu wrote:
>
> > Hi,
> >  i have the following code. it compiles with gcc in Cygwin but the
> > contents of the array ifitQ that I get after the call to the subroutine
> > readCharges2 is gibberish.
>
> This is expected behavior.  Read on.
>
> > The code compiles with gcc under Linux and it runs correctly. it also
> > compiles and runs correctly with windows visual studio. Pls help. The
> > resuls i get with Cygwin is:
> >
> > isumNatms = 5
> > rrr 13
> > rrr 14
> > rrr 15
> > rrr 16
> > *** 1628693268
> > *** 1628693268
> > *** 16
> > *** 1034
> >
> > instead of:
> > isumNatms = 5
> > rrr 13
> > rrr 14
> > rrr 15
> > rrr 16
> > *** 13
> > *** 14
> > *** 15
> > *** 16
> >
> > the code is:
>
> Ouch.  Indentation issues aside, you have a bug in this program.
>
> > #include 
> > #include 
> >
> > void readCharges2(int *, int *, int *);
> > int main()
> > {
> > static int *ifitQ;
> > int *ipUniqAtms, *ipindexToFit;
> > int j;
> > int x,y;
> > ipUniqAtms =&x;
> > ipindexToFit=&y;
> >ifitQ = (int *) malloc(sizeof(int));
> >if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
> >exit(EXIT_FAILURE);}
> > readCharges2(ifitQ,ipUniqAtms,ipindexToFit);
>
> Note that ifitQ is passed *by value*, and any changes you make to it
> inside readCharges2() will be lost when you come back to main.  So, you
> realloc it inside readCharges2(), and store values in the new array, but
> in main(), you print the values in the *old* array (which are, as you
> said, gibberish, as the memory has been released to the system).
>
> >for(j=0; j< *ipUniqAtms ; j++)
> >{
> >   printf("*** %d\n",ifitQ[j]);
> >}
> >
> > return 0;
> > }
> >
> > void readCharges2(int *ifitQ, int * ipUniqAtms, int * ipindexToFit)
> > {
> >int  j, isumNatms=0;
> >isumNatms=5;
> >printf("isumNatms = %d \n",isumNatms);
> >ifitQ = (int *) realloc(ifitQ,isumNatms*sizeof(int));
> >if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
> >exit(EXIT_FAILURE);}
> >
> >ifitQ[0]=13;
> >ifitQ[1]=14;
> >ifitQ[2]=15;
> >ifitQ[3]=16;
> > *ipUniqAtms =  4;
> > *ipindexToFit =  3;
> >for(j=0; j< *ipUniqAtms ; j++)
> >{
> >   printf("rrr %d\n",ifitQ[j]);
> >}
> > }
>
> The reason it probably worked on Linux is because in Linux, realloc will
> try hard to keep the array at the same address if it can simply bump the
> size of the pointer.  Cygwin's realloc doesn't.

s/pointer/memory block/.  Sorry for the typo.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Re: problem with malloc/realloc. Pls help.

[Igor Peshansky]

On Mon, 21 Aug 2006, Omololu wrote:

> Hi,
>  i have the following code. it compiles with gcc in Cygwin but the
> contents of the array ifitQ that I get after the call to the subroutine
> readCharges2 is gibberish.

This is expected behavior.  Read on.

> The code compiles with gcc under Linux and it runs correctly. it also
> compiles and runs correctly with windows visual studio. Pls help. The
> resuls i get with Cygwin is:
>
> isumNatms = 5
> rrr 13
> rrr 14
> rrr 15
> rrr 16
> *** 1628693268
> *** 1628693268
> *** 16
> *** 1034
>
> instead of:
> isumNatms = 5
> rrr 13
> rrr 14
> rrr 15
> rrr 16
> *** 13
> *** 14
> *** 15
> *** 16
>
> the code is:

Ouch.  Indentation issues aside, you have a bug in this program.

> #include 
> #include 
>
> void readCharges2(int *, int *, int *);
> int main()
> {
> static int *ifitQ;
> int *ipUniqAtms, *ipindexToFit;
> int j;
> int x,y;
> ipUniqAtms =&x;
> ipindexToFit=&y;
>ifitQ = (int *) malloc(sizeof(int));
>if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
>exit(EXIT_FAILURE);}
> readCharges2(ifitQ,ipUniqAtms,ipindexToFit);

Note that ifitQ is passed *by value*, and any changes you make to it
inside readCharges2() will be lost when you come back to main.  So, you
realloc it inside readCharges2(), and store values in the new array, but
in main(), you print the values in the *old* array (which are, as you
said, gibberish, as the memory has been released to the system).

>for(j=0; j< *ipUniqAtms ; j++)
>{
>   printf("*** %d\n",ifitQ[j]);
>}
>
> return 0;
> }
>
> void readCharges2(int *ifitQ, int * ipUniqAtms, int * ipindexToFit)
> {
>int  j, isumNatms=0;
>isumNatms=5;
>printf("isumNatms = %d \n",isumNatms);
>ifitQ = (int *) realloc(ifitQ,isumNatms*sizeof(int));
>if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
>exit(EXIT_FAILURE);}
>
>ifitQ[0]=13;
>ifitQ[1]=14;
>ifitQ[2]=15;
>ifitQ[3]=16;
> *ipUniqAtms =  4;
> *ipindexToFit =  3;
>for(j=0; j< *ipUniqAtms ; j++)
>{
>   printf("rrr %d\n",ifitQ[j]);
>}
> }

The reason it probably worked on Linux is because in Linux, realloc will
try hard to keep the array at the same address if it can simply bump the
size of the pointer.  Cygwin's realloc doesn't.
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

At 01:35 PM 8/21/2006, Dave Korn wrote:
>On 21 August 2006 18:28, William A. Hoffman wrote:
>
>
>> However, one thing that might have averted this thread would have been an
>> email 
>> to the cygwin list, (prior to the release announcement) that described the
>> change you were going to make.
>
>  The hypothesis that someone who doesn't bother watching out for one kind of
>announcement related to make is going to be watching out for another kind of
>announcement related to make seems implausible to me.

Perhaps, but that benefit was not one of the two I listed.  I agree, that
it most likely would have been missed.  However, as a separate subject line
of, make is changing beware, it may have been noticed.  Let's face make
is not a project you expect to see a bunch of change happening on, especially
a change that breaks existing makefiles.  

-Bill



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

RE: change in behavior of make from 3.80 to 3.81

[Dave Korn]

On 21 August 2006 18:28, William A. Hoffman wrote:


> However, one thing that might have averted this thread would have been an
> email 
> to the cygwin list, (prior to the release announcement) that described the
> change you were going to make.

  The hypothesis that someone who doesn't bother watching out for one kind of
announcement related to make is going to be watching out for another kind of
announcement related to make seems implausible to me.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

At 11:12 AM 8/21/2006, Christopher Faylor wrote:
>Your messages and those from the other couple of vocal people here have
>done nothing to convince me that this decision was wrong for me.  It has
>done a lot to reinforce my belief that there are vocal people on this
>mailing list who, even when talking about free software, really do not
>"get it".  And, this makes me think that those people could stand a
>little fish teaching.
I am not sure what "fish teaching" is?

However, one thing that might have averted this thread would have been an email
to the cygwin list, (prior to the release announcement) that described the
change you were going to make.

Something like:   make - no longer going to accept non-posix paths.
I have been maintaining a cygwin specific patch to make for a long time
now, and I am no longer interested in doing that.   It is too much work,
and I do not use anything buy POSIX paths in my makefiles anyway.   If anyone
needs/wants this functionality to continue, please post to a fix for make
on make-w32 that will allow for a cygwin build of make to support Windows native
paths.   

It would have done two things:

1. It would be a good link to provide anyone that complained about the missing
feature.

2. It would have let any developer know that you were not opposed to non-POSIX 
path
support in make, you just did not want to do it in a cygwin specific patch to 
make
you had been using.  Basically, it is not a waste of time to create the patch 
because
it will be used.

I don't think it is against the principals of free software to announce changes 
that
will affect backwards compatibility.  As it was the announcement came after the 
change
was made.

-Bill


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

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

At 12:56 PM 8/21/2006, Christopher Faylor wrote:
>On Mon, Aug 21, 2006 at 12:25:58PM -0400, William A. Hoffman wrote:
>>There is now an upstream patch for make with Chris's blessing.  
>
>This does not exactly have my "blessing".  I have just tried to be as
>diligent as possible in making sure that the change makes sense and that
>the patch is as small as possible.

OK, I will rephrase, Chris has seen the patch and will not oppose its adoption 
into
make or the next release of cygwin make.  

>It would behoove people for whom this change is important to test it,
>though.

Please do, it works for my use case and passes all the make tests, but
that is about as much as was tested.   The patch allows makefiles to recognize
windows and Posix paths.   All of the following will work:
c:\foo\bar.txt and c:/foo/bar.txt and /cygdrive/c/foo/bar.txt.

It is not really new functionality to the upstream make.   make already had
support for this, but it was not enabled when building for cygwin.  It now is.

-Bill


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

Re: change in behavior of make from 3.80 to 3.81

[Christopher Faylor]

On Mon, Aug 21, 2006 at 12:25:58PM -0400, William A. Hoffman wrote:
>There is now an upstream patch for make with Chris's blessing.  

This does not exactly have my "blessing".  I have just tried to be as
diligent as possible in making sure that the change makes sense and that
the patch is as small as possible.

It would behoove people for whom this change is important to test it,
though.

cgf

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

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

There is now an upstream patch for make with Chris's blessing.  
It can be found here:
http://article.gmane.org/gmane.comp.gnu.make.windows/2136

If anyone wants to try it, and make sure it creates a make
that does what you expect, now is the time.   To use the
patch you will have to run autoconf and autoheader before you
run configure.   

-Bill


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

Re: group"S-1-2-0"(users who login locally)in ssh;windows 2003

[Tom Rodman]

On Fri 8/18/06 16:28 +0200 cygwin@cygwin.com wrote:
> On Aug 18 08:35, Tom Rodman wrote:
> > On Fri 8/18/06 8:58 +0200 cygwin@cygwin.com wrote:
> > > On Aug 17 18:49, Tom Rodman wrote:
> > > > 
> > > > tried that.. no joy, take a look:
> > > > --v-v--C-U-T---H-E-R-E-v-v-- 
> > > >   $ $WINDIR/system32/whoami /all #we're in an ssh session before edits 
> > > > made to /etc/group
> > > >   
> > > >   USER INFORMATION
> > > >   
> > > >   
> > > >   User Name  SID
> > > >   == =
> > > >   DOMxx1\adm_usr1 S-1-5-21-1390067357-1202660629-682003330-5774
> > > 
> > > Must be a password logon session, otherwise you would not see this
> > > user name here, but sshd_server.
> > 
> > Your right, it is a *password authenticated* logon session, such sessions 
> > are
> > fine w/me for system administration work. On a separate issue, rightly
> > or wrongly we use an expect script w/cron to schedule cron jobs that
> > access and change files on network shares.
> 
> That's bad.  The user token created by cron is the same style as the
> user token created with ssh /w pubkey authentication.  The main problem
> is that the token has no network credentials.  There's no way around
> that, not for the time being, not ever.  

Our automated workaround is using a cron lauched expect script wrapper
to ssh back to the local host, sending the username and password, so
that a new ssh *password authenticated* session is used in the cron job.

> The only way to access network
> shares using a cron job is to access public shares, or the cron job has
> access to the necessary user/password combination and calls `net use'
> directly.  And even then, you can only access the shares directly
> (//server/share), not with drive letters.

right, we use UNC PATHs; also our mount table contains mounts w/UNC paths

> But, Tom, this is all not new.  This has been talked about in this list
> for years, really.  You should be able to find that information eaasily
> by googling.

I've known about the password authentication requirement for access to
network shares for years.  We've been using ssh sessions w/password
authentication, that therefore allows us to write to network shares, for years. 
:->

> > again - A home dir on a network share, works fine for us w/password
> > authentication, so the original post/problem is for the password
> > authentication case - sorry I did not make that clear :-<
> 
> The trick using /etc/group only works for password-LESS authentication,
> sorry for not mentioning it, but usually the problems reported here are
> with passwordless authentication so I just assumed this is the case here, 
> too.  

A trick using /etc/group *does* work for password authentication - at
least for domain groups. We edit /etc/group, every day via a cron job -
we merge in a comma delimited list of usernames for all domain groups
a given ssh user is in; we do this for all users that need ssh access.
This became a requirement after we moved to a much larger domain -
without this workaround, even password authenticated ssh sessiosn did
not get write access to network shares.

  Related thread: http://cygwin.com/ml/cygwin/2005-07/msg01287.html

The following approach was inspired by Pierre A. Humblet; if I were to
get /etc/group configured correctly in a manual approach for just 1 user;
I would log in as the user that needs an ssh account, run this in a
console or RDP bash session:

  echo $(id -G|tr ' ' \\n|awk '$1 > '|sort -n|tr \\n ,)|sed 's~,$~~'
# "> " because this approach is only applicable (or required) for 
domain groups AFAIK

  Ex:
$ echo $(id -G|tr ' ' \\n|awk '$1 > '|sort -n|tr \\n ,)|sed 's~,$~~'
10513,16024,16025,16026,16027,19858,19968

Next edit /etc/group to append the respective username to each of the
above groups in the comma delimited list.  If this is done correctly,
then `id -G` lists the same groups at the console, as it does in a password
authenticated ssh session, and the user can write to network drives.
  
I'm not sure if it matters, but our domain has quite a few domain local groups,
and many of these are not seen by "mkgroup -l" or "mkgroup -d".  Pierre
speculated that our IT department may have done something to cause this - I
did some asking around but got no where on that.

> The /etc/group trick can work, though.  The code is just not in
> Cygwin.  I put this on my TODO list for an upcoming Cygwin version, but
> don't hold your breath.

thx/great

New Info:

  Over the weekend I ssh'd into the same w2k3 server w/password
  authentication using a local user account (all the cases I showed
  earlier were domain accounts). This local account, was an administrator,
  and this username does *not* show up anywhere in /etc/group. Windows
  "whoam /all" *did* show membership in S-1-2-0. Does that help the
  analysis at all?

> > It would be interesting to see if you or otheres can duplica

problem with malloc/realloc. Pls help.

[Omololu]

Hi,
 i have the following code. it compiles with gcc in Cygwin but the contents of
the array ifitQ that I get after the call to the subroutine readCharges2 is
gibberish.
The code compiles with gcc under Linux and it runs correctly. it also compiles
and runs correctly with windows visual studio. Pls help. The resuls i get with
Cygwin is:
isumNatms = 5 
rrr 13
rrr 14
rrr 15
rrr 16
*** 1628693268
*** 1628693268
*** 16
*** 1034

instead of:
isumNatms = 5 
rrr 13
rrr 14
rrr 15
rrr 16
*** 13
*** 14
*** 15
*** 16

the code is:

#include 
#include 

void readCharges2(int *, int *, int *);
int main()
{
static int *ifitQ;
int *ipUniqAtms, *ipindexToFit;
int j;
int x,y;
ipUniqAtms =&x;
ipindexToFit=&y;
   ifitQ = (int *) malloc(sizeof(int));
   if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
   exit(EXIT_FAILURE);}
readCharges2(ifitQ,ipUniqAtms,ipindexToFit);
   for(j=0; j< *ipUniqAtms ; j++)
   {
  printf("*** %d\n",ifitQ[j]);
   }

return 0;
}

void readCharges2(int *ifitQ, int * ipUniqAtms, int * ipindexToFit)
{
   int  j, isumNatms=0;
   isumNatms=5;
   printf("isumNatms = %d \n",isumNatms);
   ifitQ = (int *) realloc(ifitQ,isumNatms*sizeof(int));
   if(ifitQ==NULL){printf("Unable to allocate matrix ifitQ\n");
   exit(EXIT_FAILURE);}

   ifitQ[0]=13;
   ifitQ[1]=14;
   ifitQ[2]=15;
   ifitQ[3]=16;
*ipUniqAtms =  4;
*ipindexToFit =  3;
   for(j=0; j< *ipUniqAtms ; j++)
   {
  printf("rrr %d\n",ifitQ[j]);
   }
}



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

Re: change in behavior of make from 3.80 to 3.81

[Christopher Faylor]

On Sun, Aug 20, 2006 at 11:02:06PM -0700, Joachim Achtzehnter wrote:
>Dave Korn wrote:
>>>Because I do not agree with your suggestion.
>>
>>You don't agree that this is the cygwin list, not the mingw list?
>
>Some people are trying to solve an issue with cygwin's build of make by
>discussing possible solutions.  Those who have nothing to contribute to
>this effort would do well to just ignore this thread instead of
>responding to every second posting with remarks like this.  We know
>that you dislike DOS paths (and people who use DOS paths with cygwin
>too?), so there is no need to repeatly point this out.  On the specific
>point above, it is rather disingenious if MingW make is proposed as a
>solution to somebody's problem and when it is then explained that this
>isn't the case the topic becomes inappropriate.  It is also not nice,
>to say the least, to omit crucial detail from quoted text, such as
>this:
>
>>>You mentioned MinGW as an alternative, it does not work.  Also, someone
>>>on this list asked me a question, and I answered it.
>
>If MinGW is off-topic it is off-topic for everybody, not just those on
>one side of the argument.
>
>Again, my main point: It is ok to ignore a thread you're not interested
>in.

Your main point is flawed.

I administer both this mailing list and make.  When I suggest that someone
should go elsewhere, listening to me is not "optional".

In this case, following my advice IS the right way to solve the problem.
Given that the OP did not have very much knowledge about MinGW or
(apparently) MSYS, it makes an excruciating amount of sense that this
would not be the place to pick it up.  It really is not productive to
argue that you want to talk about MinGW here.

OTOH, it would be wonderful if the OP had gone away to discuss the
problem with the experts and THEN returned with a summary which either
showed the solution or informed us all that there was still a problem.
And, given the discussion in the make-w32 mailing list, maybe that will
still happen (I still think that there would have been a more
comprehensive response if the mingw mailing list had been used,
however).

Joachim, I have been trying to respond to your messages as politely as I
can but your email is getting quite old now.  This thread has seen a lot
of counterproductive content.  Messages which suggest that people are
being "emotional", claim to speak for a large number of users, suggest
forking the project (for make!), contain polemics on the philosophy of
free software, accuse cygwin developers of saying things they haven't
said, or suggest that people should ignore discussions which have been
tagged as off-topic are not going to convince me to do anything.  And,
at the end of the day, this isn't a "change to Cygwin philosophy".  It
is just a decision on my part to stop supporting a "small" 400+ line
patch.

Your messages and those from the other couple of vocal people here have
done nothing to convince me that this decision was wrong for me.  It has
done a lot to reinforce my belief that there are vocal people on this
mailing list who, even when talking about free software, really do not
"get it".  And, this makes me think that those people could stand a
little fish teaching.

So, you can continue to send email but I want to point out that your
messages are not having the effect that you may desire.

cgf

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

Re: Those nasty bundled Cygwin's

[Larry Hall (Cygwin)]

Eric Hanchrow wrote:

"Larry" == Larry Hall (Cygwin)  writes:



. Thanks.




Larry> This has also been discussed before.  If you'd like to
Larry> understand the options, I'd recommend reviewing the email
Larry> archives for threads on this issue.

Thanks; I assume you mean the thread that starts with this message

http://article.gmane.org/gmane.os.cygwin/22549

?



Yes, that is one.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

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

Re: program fails to find it's DLL

[Igor Peshansky]

On Mon, 21 Aug 2006, Eric Thomas wrote:

> Hi all,
>
> I've got an issue here with some command line programs, all from the
> same editor.
>
> Commands are issued from bash 3.0.16-14 / cygwin 1.5.18-1 on a
> computer running W2K SP4.
> Everything was ok until someone introduced an invalid path in the
> default PATH that bash inherits from cmd.exe .
> Let's say that PATH is made of 3 parts:
> A : valid path
> B : invalid path ("invalid" means that it raise my issue)
> C : valid path
>
> Since, those programs raise a pop-up to complain that some DLL is
> missing in "path displayed".
> But "path displayed" is incomplete. In fact "path displayed" is only the
> A part.
> The missing DLL belongs to one dir of the C part.
> So, this invalid value prevents the program to look further in the last
> part of PATH.
>
> Well, one would think that the problem is only on the program's side
> (and maybe it is). But there are other arguments to look at too.
>
> Only some kind of path format can raise the issue.
> Let's say that
> /cygdrive/c/a   is a directory
> /cygdrive/c/b   is a regular file
> /cygdrive/c/c   does not exist
>
> Issue raised with
> /cygdrive/c/b/
> /cygdrive/c/b/anyfilename_or_dirname
>
> It will also happen with a true invalid path like this one:
> /cygdrive/sure_I_am_an_invalid_path
>
> But the following won't:
> /cygdrive/c/a
> /cygdrive/c/b
> /cygdrive/c/c
> everything that doesn't start with /cygdrive
>
> Facts:
> - I didn't managed to reproduce the problem when issuing the command
> directly from a cmd.exe, excepted by setting PATH to "" of course. But
> an invalid path placed in PATH does not hurt.
> - I didn't managed to reproduce the problem with any other program that
> would requiere some DLL (excel for instance)
>
> So it makes me think that It could be related to cygwin in some way,
> even if it occurs only with those programs because they probably behave
> differently from other programs...
>
> I've done a fresh installation of cygwin (bash 3.1-6 / cygwin 1.5.21-2)
> on another computer.
> Some changes with this one:
> - no more pop-up, but the program still fails to run due to its missing
> DLL
> - now "/regular_file/" will also raise the problem (at least this point
> is consistent now)
>
> Could those programs explicitly load some DLL after they start-up ? and
> rely on PATH to do it on purpuse ?
> If so, they manage to deal with invalid path when running from cmd.exe.
> Something must be different when run from bash.
>
> Just in case you wonder: same behaviour with ash.
>
> Any comment welcome and appreciated

Known issue.  It's not the shell, actually -- it's Cygwin's path
conversion.  It will stop converting the path as soon as it encounters an
invalid directory.  This also arises when some broken installers put
quotes in the PATH.

I believe I've had a patch for this somewhere, though don't recall whether
it was applied or not.  You might want to search the cygwin-patches
archive and look at path.cc in Cygwin sources.  I'll try to locate the
patch file and resubmit.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

RE: program fails to find it's DLL

[Dave Korn]

On 21 August 2006 08:39, Eric Thomas wrote:



> Any comment welcome and appreciated

  You've given us too much analysis and guesswork at what is happening, but
unfortunately it has not come across well in translation, and what we really
need most is a step-by-step recipe to reproduce the problem.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: octave compiled with gcc-3.4.4-2 - error messages during make check

[Dave Korn]

On 19 August 2006 23:28, James R. Phillips wrote:

> I've built a test version of octave 2.1.73 on cygwin using the experimental
> gcc-3.4.4-2 compiler.  Thanks to Brian Dessent for pointing out a packaging
> problem with the compiler and a workaround:
> http://www.cygwin.com/ml/cygwin/2006-07/msg00620.html .

  Thanks for helping test the new compiler package!

> The build is successful, but several of the tests executed during "make
> check" issue error messages like the following:
> 
> Running
> /home/dad/sources/octave/octave-2.1.73/test/octave.test/quad/quad.exp ...
> 102 [main] octave 1252 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code
>  0x80, errno 11
> 
> Interestingly, none of these tests actually fail in the summary report.
> 
> The only hits I get with Google on this error message ["died waiting for
> longjmp before initialization, retry 0"] relate to relatively recent issues
> with the cygwin dll.  I'm not sure how to classify this issue, i.e. whether
> it is a cygwin issue, a compiler issue, or an octave issue.  Also I'm not
> sure how serious it is, since the tests it occurred on appeared to complete
> successfully.
> 
> Any help with analysis of these questions would be appreciated.

  Change one parameter at a time.  Keep all others constant.  See what
changes.

  First thing would be to experiment with a few different versions of the
cygwin dll, including the most recent snapshot.  Re-run "make check" in the
exact same object dir without rebuilding the application.  Then, keeping the
dll constant, try rolling your gcc install back to 3.4.4-1, building in a
fresh object dir, and running make check there.  Please let us know what
results you get.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

program fails to find it's DLL

[Eric Thomas]

Hi all,

I've got an issue here with some command line programs, all from the 
same editor.


Commands are issued from bash 3.0.16-14 / cygwin 1.5.18-1 on a
computer running W2K SP4.
Everything was ok until someone introduced an invalid path in the 
default PATH that bash inherits from cmd.exe .

Let's say that PATH is made of 3 parts:
A : valid path
B : invalid path ("invalid" means that it raise my issue)
C : valid path

Since, those programs raise a pop-up to complain that some DLL is
missing in "path displayed".
But "path displayed" is incomplete. In fact "path displayed" is only the
A part.
The missing DLL belongs to one dir of the C part.
So, this invalid value prevents the program to look further in the last
part of PATH.

Well, one would think that the problem is only on the program's side
(and maybe it is). But there are other arguments to look at too.

Only some kind of path format can raise the issue.
Let's say that
/cygdrive/c/a   is a directory
/cygdrive/c/b   is a regular file
/cygdrive/c/c   does not exist

Issue raised with
/cygdrive/c/b/
/cygdrive/c/b/anyfilename_or_dirname

It will also happen with a true invalid path like this one: 
/cygdrive/sure_I_am_an_invalid_path


But the following won't:
/cygdrive/c/a
/cygdrive/c/b
/cygdrive/c/c
everything that doesn't start with /cygdrive

Facts:
- I didn't managed to reproduce the problem when issuing the command
directly from a cmd.exe, excepted by setting PATH to "" of course. But
an invalid path placed in PATH does not hurt.
- I didn't managed to reproduce the problem with any other program that
would requiere some DLL (excel for instance)

So it makes me think that It could be related to cygwin in some way,
even if it occurs only with those programs because they probably behave
differently from other programs...

I've done a fresh installation of cygwin (bash 3.1-6 / cygwin 1.5.21-2)
on another computer.
Some changes with this one:
- no more pop-up, but the program still fails to run due to its missing
DLL
- now "/regular_file/" will also raise the problem (at least this point
is consistent now)

Could those programs explicitly load some DLL after they start-up ? and
rely on PATH to do it on purpuse ?
If so, they manage to deal with invalid path when running from cmd.exe.
Something must be different when run from bash.

Just in case you wonder: same behaviour with ash.

Any comment welcome and appreciated

Regards,
Eric


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