RE: Strange behavior of MSVC's printf under cygwin shell?

[Robert Collins]

> -Original Message-
> From: Pietro Toniolo [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, March 26, 2002 7:04 PM

> Is it an "undefined behavior" of the c compiler?
> But why a different default behavior, with and without the flag?

You get a different C library with, and without the flag.

'nuff said.

Rob

--
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: Strange behavior of MSVC's printf under cygwin shell?

[Pietro Toniolo]

"Larry Hall (RFK Partners, Inc)" wrote:

> The problem must be at your end.  I don't see it here.  Looks like you'll
> need to debug it more.

Nay, I campiled the proposed program (every package on my side is in the
"Last" status) and, with -no-cygwin, I do have an unbuffered stdout.

Is it an "undefined behavior" of the c compiler?
But why a different default behavior, with and without the flag?



--
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: cygwin1.dll bug in ftime

[J. J. Farrell]

From: "Wu Yongwei" <[EMAIL PROTECTED]>
> 
> This is from the glibc documentation (is glibc meaningless to the Cygwin
> project?):

I'm not sure what you mean by "meaningless", but glibc is of no
particular relevance to Cygwin.

> ...
>  The GNU operating system does not support using struct
>  timezone to represent time zone information; that is an
>  obsolete feature of 4.3 BSD. Instead, use the facilities
>  described in 21.4.8 Functions and Variables for Time Zones.

You quote documentation that tells you not to do what you are doing.

> I do not understand you quite clearly. And I want to emphasize again that IT
> USED TO WORK! Do I need to write patches so that the code is unpatched?

If anything is going to change, somebody has to write patches.
If you're the one that wants it to change, it seems reasonable
that you should be the one who writes the patches.

> Also notes the usage of "unspecified". "Unspecified" means the standard does
> not say anything about the implementation, and, IMHO, the implementors are
> free to choose the best practices. I think it is obviously a good way to
> follow BSD.
> 
> Am I wrong?

You're wrong to say that it's obvious. Why is it better to follow
BSD than any other version of UNIX? Why is it better to do anything
in particular with an obsolete feature that has been deprecated for
many many years?

> Thank you for your suggestions. The points are:
> 
> 1) Cygwin did very well, but not now;
> 
> 2) I was not using ftime to get time, but to get timezone information.
> 
> 3) timezone variable is not usable in Cygwin.
> 
> So timezone is now not portable. Cygwin broke some "unportable" code.

Is that a surprise? Unportable code, by definition, is likely to
break between different releases of an OS, and between different
OSes. Instead of spending time complaining here, you'd be better
off generating patches to introduce the behaviour you want. Even
better, spend the time changing your code to use the standard
portable ways of doing what you want to do.



--
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/

GLUI/GLUT setup...

[cygwin]

Hey, does anyone know a good link for setting up GLUI and GLUT with cygwin?  I"m 
having some path problems...probably related to my makefile.  
 
If anyone knows something about setting this up, I'd love to hear from you.
 
Thanks, 
Matt

___


--
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: cygwin1.dll bug in ftime (patch included)

[Wu Yongwei]

OK, here is the patch for src/winsup/cygwin/times.cc:


--- times.cc.oldTue Mar 26 11:36:53 2002
+++ times.ccTue Mar 26 11:53:42 2002
@@ -156,4 +156,5 @@
 {
   static hires gtod;
+  static tzflag;
   LONGLONG now = gtod.usecs (false);
   if (now == (LONGLONG) -1)
@@ -162,4 +163,15 @@
   tv->tv_sec = now / 100;
   tv->tv_usec = now % 100;
+
+  if (tz != NULL)
+{
+  if (!tzflag) {
+tzset();
+tzflag = 1;
+  }
+  tz->tz_minuteswest = _timezone / 60;
+  tz->tz_dsttime = _daylight;
+}
+
   return 0;
 }


I did not submit a patch because I did not think you will accept it. Writing
the patch itself is easy: it was already there in an old CVS version. Or
almost so. Notice that I do not always call tzset. My previous experience
with MSVC indicates that calling tzset is costly. I am not sure of the case
with Cygwin. However, it is just there for you to review.

Best regards,

Wu Yongwei

--- Original Message from Christopher Faylor ---

On Tue, Mar 26, 2002 at 10:45:32AM +0800, Wu Yongwei wrote:
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.

I guess I wasn't clear enough.

SUPPLY A PATCH TO FIX THE BEHAVIOR.

If you want me, or anyone else to fix it, you'll undoubtedly have a long
wait.  Especially since you have now polarized me by arguing points when
you could have been investigating the code and supplying a fix.

No arguments in the world work better than an actual patch.

cgf


--
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/

timezone bug and possible patch

[Wu Yongwei]

time.h, l. 77

#if timezonevar
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
#else
char *_EXFUN(timezone, (void));
#endif

So by default timezone is defined as a function. I am not sure whether this
is a violation of standards. If it is, maybe we could use:

#ifndef timezonefunc
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
#else
char *_EXFUN(timezone, (void));
#endif

Best regards,

Wu Yongwei


--
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: cygwin1.dll bug in ftime

[Wu Yongwei]

When I write new code, _I_ will not use ftime again. In fact, I have fixed
my synctime program with an ugly "ifndef __CYGWIN__" macro and replaced
code using ftime with _timezone (timezone). However, breaking legacy code
is not good behaviour for a (runtime) environment.

Also, I don't intend my code will run on any platforms. In fact, seldom
will any code with a little complexity without real-environment test. I DO
want my code to run flawlessly on frequently-used x86 Unix enviroments,
Linux, FreeBSD, Cygwin, etc.

Sorry that I do not understand your English very well. But I hope I have
expressed my meanings.

Best regards,

Wu Yongwei

--- Original Message from Randall R Schulz ---

Yongwei,

At 18:45 2002-03-25, you wrote:
>...
>
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.

No. You're asking to be let off the hook for either writing intrinsically
portable code or of featuring it with conditional compilation directives
so that it functions as you want it to on all platforms you want to claim to
support.


--
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: cygwin1.dll bug in ftime

[Randall R Schulz]

Yongwei,

At 18:45 2002-03-25, you wrote:
>...
>
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.

No. You're asking to be let off the hook for either writing intrinsically 
portable code or of featuring it with conditional compilation directives so 
that it functions as you want it to on all platforms you want to claim to 
support.


>Best regards,
>
>Wu Yongwei


Randall Schulz
Mountain View, CA USA


--
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: cygwin1.dll bug in ftime

[Christopher Faylor]

On Tue, Mar 26, 2002 at 10:45:32AM +0800, Wu Yongwei wrote:
>Hope I am clear enough. I am arguing here for a BETTER Cygwin.

I guess I wasn't clear enough.

SUPPLY A PATCH TO FIX THE BEHAVIOR.

If you want me, or anyone else to fix it, you'll undoubtedly have a long
wait.  Especially since you have now polarized me by arguing points when
you could have been investigating the code and supplying a fix.

No arguments in the world work better than an actual patch.

cgf

--
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: cygwin1.dll bug in ftime

[Wu Yongwei]

First I'll answer your question 3. Having defined timezone does not mean it
will work.


#include 
#include 

int main()
{
tzset();
printf("%ld\n", timezone);
printf("%ld\n", _timezone);
return 0;
}

$ gcc -Wall test.c
test.c: In function `main':
test.c:7: warning: long int format, pointer arg (arg 2)

$ ./a
4198632
-28800


Enough? (Not well tested, uh?)

Second, no one should ignore backward compatibility (M$'s success is partly
owing to this, as well as Unix's popularity), as long as it does not violate
the design rules (standards-conformance, etc.). I don't think, say,
respecting the second argument of gettimeofday is a sin; those not wanting
it can simply pass NULL.

There is a SERIOUS misunderstanding about standards conformance here. An
unusable timezone is a violation, but well-behaved ftime and gettimeofday
are NOT.

Just as the morale of network protocol implementation is: Be generous to
accept, and be prudent to send. So I think in programming we also should
make environments (run-times, librabries) as compatible as possible, and
write applications as portable as possible.

A standard should specify what we SHOULD do, but it never restricts what we
COULD do. Not to mention that what I asked for has long been there in the
UNIX tradition already.

As I have said already, "unspecified" in a standard means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose from the best practices. Better practices mean better
compatibility, don't they?

Summary of my points. Making ftime and gettimeofday get timezone information
is not a violation of any standards, and will make Cygwin only better
(unless someone thinks better compatibility is a sin).

Hope I am clear enough. I am arguing here for a BETTER Cygwin.

Best regards,

Wu Yongwei

--- Original Message from Karsten Fleischer ---

> Thank you for your suggestions. The points are:
>
> 1) Cygwin did very well, but not now;

That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.

> 2) I was not using ftime to get time, but to get timezone information.

OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:

--->>
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
<<---

[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.

> 3) timezone variable is not usable in Cygwin.

Why not?

In my installation 1.3.10 installation I see this in the  header
file:

--->>
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
<<---

And _timezone is declared some lines above:

--->>
extern __IMPORT time_t _timezone;
<<---

This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:

--->>
The following are declared as variables:


extern int   daylight;
extern long int  timezone;
extern char *tzname[];
<<---

SUSv3 says:

--->>
The following shall be declared as variables:

extern intdaylight;
extern long   timezone;

extern char  *tzname[];
<<---

timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.


> So timezone is now not portable. Cygwin broke some "unportable" code.

It didn't talk about "unportable" code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.

Karsten


--
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/

Setup.exe: bugfix

[Robert Collins]

I've uploaded a new setup.exe that fixes the crashing problem
experienced by some folk.

Many thanks to Pavel Tsekov for solving this.

Rob

--
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: Strange behavior of MSVC's printf under cygwin shell?

[Pietro Toniolo]

Wirawan Purwanto wrote:

> Why does the screen output displayed using MSVC's printf subroutine not get
> shown immediately under Cygwin shell (bash, specifically)? Rather, it would
> wait for a long time before showing the text lines (many lines at once). How
> to change this behavior?

With -mno-cygwin, stdout is buffered. You can realize it if you put a
fflush(stdout) after the printf: the behavior is what you expect.

But, why this difference? I don't know.



--
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: missing telnet, solution

[Robert Collins]

> -Original Message-
> From: mstucky5 [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, March 26, 2002 10:10 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: missing telnet, solution
> 
> 
> This whole thread got me thinking about possible ways
> to avoid this "xxx is missing" problem...
> 
> I thought that I'd throw an idea out for discussion...
> 
> Would it make sense to have setup install a dummy
> script for some of the common utilities and then
> overwrite that script with the actual utility if
> it is selected from the gui as it should be?

In debian, there is a package that will do this - I think it that when a
binary is not found it queries dpkg to see if a package that can provide
it exists.

Anyway, I think that an _automated_ approach to this could be quite
useful, but not a manual one. (I realise that you didn't imply either,
I'm simply getting there first :}).

Rob

--
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: Perl module DBD::ODBC 0.39 wont compile on CYGWIN

[Gerrit P. Haase]

Hallo Paul,

Am 2002-03-25 um 23:33 schriebst du:

> DBD::ODBC Version 0.38 builds and passes the tests, but 0.39 wont even 
> compile. Here are the error messages:

> $ make
> cp ODBC.pm blib/lib/DBD/ODBC.pm
> /usr/bin/perl -p -e "s/~DRIVER~/ODBC/g" < 
> /usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI/Driver.xst > ODBC.xsi
> /usr/bin/perl -I/usr/lib/perl5/5.6.1/cygwin-multi -I/usr/lib/perl5/5.6.1 
> /usr/lib/perl5/5.6.1/ExtUtils/xsubpp  -typemap
> /usr/lib/perl5/5.6.1/ExtUtils/typemap ODBC.xs > ODBC.xsc && mv ODBC.xsc ODBC.c
> gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI 
> -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include 
> -DUSEIMPORTLIB -O2   -DVERSION=\"0.39\" 
> -DXS_VERSION=\"0.39\"  -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE  ODBC.c
> gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI 
> -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include 
> -DUSEIMPORTLIB -O2   -DVERSION=\"0.39\" 
> -DXS_VERSION=\"0.39\"  -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE  dbdimp.c
> dbdimp.c: In function `odbc_db_login6':
> dbdimp.c:211: `SQL_ATTR_ODBC_VERSION' undeclared (first use in this function)
> dbdimp.c:211: (Each undeclared identifier is reported only once
> dbdimp.c:211: for each function it appears in.)
> dbdimp.c:211: `SQL_IS_INTEGER' undeclared (first use in this function)
> dbdimp.c: At top level:
> dbdimp.c:1644: warning: `_dbd_rebind_ph' was declared implicitly `extern' 
> and later `static'
> dbdimp.c:1190: warning: previous declaration of `_dbd_rebind_ph'
> make: *** [dbdimp.o] Error 1


> When I look, the undeclared symbols are really, truly undefined. 
> SQL_ATTR_ODBC_VERSION does not even appear to exist in version 0.38.

Siebenschlaefer@LORELEY /usr/include
$ grep -r SQL_IS_INTEGER *
w32api/sqlext.h:#define SQL_IS_INTEGER (-6)

Siebenschlaefer@LORELEY /usr/include
$ grep -r SQL_ATTR_ODBC_VERSION *
w32api/sqlext.h:#define SQL_ATTR_ODBC_VERSION 200


> (BTW, as far as I can tell, the patch file used some time ago by CYGWIN 
> users to fix the Makefile.pl has been fully incorporated into more recent 
> builds, so I know that is not the problem.)

It seems that there was no Cygwin user working on this module;)
Try to include , ah at first take a look at this old patch,
look how Eric Fifer solved the issue (windows.h needs to be included
but immediatly after that WIN32 is undefined):
http://testers.cpan.org/search?request=dist&dist=DBD-ODBC&macid=130



Gerrit
-- 
=^..^=


--
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: missing telnet, solution

[mstucky5]

This whole thread got me thinking about possible ways
to avoid this "xxx is missing" problem...

I thought that I'd throw an idea out for discussion...

Would it make sense to have setup install a dummy
script for some of the common utilities and then
overwrite that script with the actual utility if
it is selected from the gui as it should be?

Assume that the missing utility is called "ttt.exe"
Have setup create

   /bin/missing

and link "ttt.exe" to missing

   ln -s /bin/missing /bin/telnet.exe


stuckymb [547] > ls -l missing ttt.exe
-rwxr-xr-x1 stuckymb mygroup   214 Mar 25 18:00 missing
lrwxrwxrwx1 stuckymb mygroup94 Mar 25 17:58 ttt.exe ->
missing
stuckymb [548] >
stuckymb [548] >
stuckymb [548] >
stuckymb [548] > cat missing
#!/bin/sh

echo "If you are seeing this message, it means that the"
echo " "
echo "   $0"
echo " "
echo 'still needs to be selected from within "setup"'
echo " "
echo 'Please re-run "setup"'
echo " "


stuckymb [549] >
stuckymb [549] >
stuckymb [549] >
stuckymb [549] > ttt.exe
If you are seeing this message, it means that the

   ./ttt.exe

still needs to be selected from within "setup"

Please re-run "setup"




When setup is re-run to download the actual ttt.exe
the dummy ttt.exe could be deleted and then replaced
with the correct executable.

Just my 0.02 cents worth...

--Mark



- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 23, 2002 9:46 PM
Subject: Re: missing telnet, solution


> On Sat, Mar 23, 2002 at 06:18:05PM +0100, Palic, Darko wrote:
> >Hello Christopher,
> >
> >okay it is nice to follow the request of the users, but why isn't a
> >selectbox available, there something like "basic/minimal,
common/typical and
> >complete" could be selected instead of changing the whole setup? It
would
> >help!
>
> What answer are you expecting?  It's a volunteer project.  We make
> changes as time permits and as people are inclined.  We thought the
> current setup with categories would be an improvement and apparently
it
> wasn't.  It never occurred to us that people wouldn't be able to
figure
> out that you could click on things and see packages to install.  But,
> that was the case.
>
> Once it became clear that there was a problem and that people didn't
> like having to select things individually, I would have liked to see
an
> immediate resolution of the problem but it just didn't happen.  It's
not
> like I can fire anyone for not improving setup for you.  I'm just damn
> grateful that Robert and others are spending time working on it at
all.
>
> Anyway, the new, just released, version of setup has some improvements
> for selecting whole categories.  That should make things much easier.
>
> We're discussing other alternatives all of the time but the basic
> problem is that we have a lot of people who just ask aggrieved
questions
> like the above or who repeat the same observations that have been made
> countless times before, and very few people who are actually willing
to
> help make things better.
>
> If you want to contribute (and apparently you do), then setup.exe
discussions
> are happening in the cygwin-apps mailing lists.  If you have further
questions,
> you should (after reviewing the mail archives there) send them there.
>
> cgf
>
> > I think the change you're referring to was that we added, at the
request
> > of many users, a minimal install.  It's based on the debian "base"
> > category, which does not include bzip2.  The default installation is
a
> > really basic one and it's looking like we need to change that.
> >
> > Anyway, I'll try to keep in this in mind if we change something in
the
> > future that impacts Cygwin/XFree86.  It never occurred to me that
this
> > would be an issue.
>


--
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: Shared libraries.

[Gerrit P. Haase]

Hallo Wiebe,

Am 2002-03-25 um 16:12 schriebst du:

> I'm trying to build and use shared libraries with Cygwin under Windows 2000.
> The first step, i.e. building the library, succeeds. I get a libmylib.so
> (together with libmylib.so.1 and limmylib.so.1.0.0). However, linking is a
> problem. I've written a small program which uses libmylib.so and try to link
> it as follows:

> g++ -o testprogram.exe testprogram.o -L/usr/src/DynLib -lmylib

> This results in the error:


> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lmylib

> For information the entire output when executing make clean:

> rm -f   PrintTest.o  PrintTest.exe.exe PrintTest.d *~
> make
> make[1]: Entering directory `/usr/src/dynlibtest'
> g++ -M  -Wall  PrintTest.cpp > PrintTest.d
> g++ -M  -Wall  PrintTest.cpp | sed s/\\.o/.d/ >> PrintTest.d
> make[1]: Leaving directory `/usr/src/dynlibtest'
> make[1]: Entering directory `/usr/src/dynlibtest'
> g++ -Wall-c -o PrintTest.o PrintTest.cpp
> g++  -o PrintTest.exe   PrintTest.o  -L/usr/src/DynLib -lmylib
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lmylib
> collect2: ld returned 1 exit status
> make[1]: *** [PrintTest.exe] Error 1
> make[1]: Leaving directory `/usr/src/dynlibtest'
> make: *** [clean] Error 2

> When using:

> g++ -o PrintTest.exe PrintTest.o libmylib.so

> I get the error:

> collect2: ld terminated with signal 11 [Segmentation fault]

> Can someone tell me what I'm doing wrong?

You cannot act with windows like with linux.  On windows shared libs
are dynamic link libraries (mylib.dll), and you cannot use symlinks to
point to a dll.  Say mylib-0.1.dll is you lib and mylib.dll is the
symlink then it is not possible to link against the symlink, windows
doesn't accept this as a library.  Anyway, we don't use the .dll's to
link against, but a special library called import library.
Looks like this (Cygwin default name) libmylib.dll.a, so we can have
also libmylib.a as the static lib.
Now if you link against this lib you write: gcc -o prog -I/lib -lmylib
The linker looks at first for libmylib.dll.a, then if there is no
importlib it looks for a static lib.
I always try to build a static lib at first.
If it succeeds it is just one step to get a dynamic link library from
these objects:
gcc -shared -o cyg${module}.dll -Wl,--out-implib=lib${module}.dll.a \
  -Wl,--export-all-symbols \
  -Wl,--enable-auto-import \
  -Wl,--whole-archive $old_lib \
  -Wl,--no-whole-archive ${dependency_libs}

The last (-Wl,--no-whole-archive) is important, even if you have no
dependency_libs.  Don't miss it!
${module} is 'mylib' to stay with your example and $old_lib is libmylib.a,
the static lib.  As an alternativ you can list all the objects here instead
of a static lib which is in fact just a bundle of object files.


HTH,

Gerrit
-- 
=^..^=
Maybe Charles will find some time to finish his docu about creating dll's;)


--
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: gdb and win32

[Larry Hall (RFK Partners, Inc)]

At 05:55 PM 3/25/2002, William Hubbard wrote:
>I am using a virtual serial port driver (from ddiusa.com) to connect gdb to a target 
>simulation through the virtual serial ports.  gdb hangs whenever I attempt to 
>connect.  It works fine when using the *real* serial ports, but hangs whenever I 
>attempt to use the virtual ports.
>The virtual port software works with other win32 applications, and the docs say they 
>drivers do not support DOS apps.  Is gdb considered a DOS app?  Does it use the win32 
>API to talk to the serial ports?  All I can find in the code is calls to open, read 
>and write, not OpenFile, ReadFile or WriteFile as I would expect for a win32 
>application.


gdb that comes with Cygwin is not considered a DOS app.  It is a Win32 app.
The gdb code itself is ported to Win32 using the Cygwin DLL so you won't
find Win32 calls made in the gdb source.  You'll need to look at the Cygwin
DLL source to find those calls.

I haven't the foggiest idea what the problem is when using your virtual 
serial port driver.  You may need to debug gdb to find the problem.  Or
talk to the vendor and get some details about how it works and what it
expects.  That might help lead you in the right direction.





Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: cygwin1.dll bug in ftime

[Karsten Fleischer]

> Thank you for your suggestions. The points are:
> 
> 1) Cygwin did very well, but not now;

That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.

> 2) I was not using ftime to get time, but to get timezone information.

OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:

--->>
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
<<---

[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.

> 3) timezone variable is not usable in Cygwin.

Why not?

In my installation 1.3.10 installation I see this in the  header
file:

--->>
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
<<---

And _timezone is declared some lines above:

--->>
extern __IMPORT time_t _timezone;
<<---

This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:

--->>
The following are declared as variables: 


extern int   daylight;
extern long int  timezone;
extern char *tzname[];
<<---

SUSv3 says:

--->>
The following shall be declared as variables:

extern intdaylight;
extern long   timezone;

extern char  *tzname[];
<<---

timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.


> So timezone is now not portable. Cygwin broke some "unportable" code.

It didn't talk about "unportable" code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.

Karsten


--
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: Strange behavior of MSVC's printf under cygwin shell?

[Keen Wayne A Contr AFRL/MNGG]

I have frequently seen unpredictable behavior of C prints in terms of their
timing.  (I'm
an old guy and I still debug with prints from time to time).  The only way I
got predictable
results was to do a buffer flush immediately after the print.  In my case,
if I didn't do that,
and the program crashed, sometimes I would never see my diagnostic prints.

I have seen this on the SGI and the PC, but I can't swear that the PC was
using VC++,
it may have been Borland, or Cygwin or...

Wayne Keen

--
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/

gdb and win32

[William Hubbard]

I am using a virtual serial port driver (from ddiusa.com) to connect gdb to 
a target simulation through the virtual serial ports.  gdb hangs whenever I 
attempt to connect.  It works fine when using the *real* serial ports, but 
hangs whenever I attempt to use the virtual ports.
The virtual port software works with other win32 applications, and the docs 
say they drivers do not support DOS apps.  Is gdb considered a DOS 
app?  Does it use the win32 API to talk to the serial ports?  All I can 
find in the code is calls to open, read and write, not OpenFile, ReadFile 
or WriteFile as I would expect for a win32 application.

Bill


--
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/

ocdemon & gdbinit mpc860T upm init

[Jon Miller]

Hello -

I am trying to work with cygwin & ocdemon & a custom MPC860T board with
SDRAM.

I need to create a command file to initialize the 860T UPM so that I can
download code into RAM.

Are there any examples available?   The gdbinit_823FADS example is not
enough!

Thanks, Jon Miller 805-564-3119

(My goal is setup free tools to burn PPCBOOT into custom MPC8xx boards.)

$powerpc-elf-gdb -- command=gdbinit_860Tregs_upm  <-- gdb startup?




--
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/

setup.exe crash

[Colman Curtin]

Hi
I have setup.exe point to a local network mapping for its local Package
directory.
I noticed when I rebooted, not having the mapping set up to reconnect, that
setup.exe crashed when it tried to move on from that screen with the
following error;
"The exception unknown software exception (0xc0fd) occurred in the
application at location 0x77f7f12a.
That was the only trouble its given me.

setup.exe version 2.194.2.15
Wint4 sp6a

-Coley.

--
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/

Perl module DBD::ODBC 0.39 wont compile on CYGWIN

[Paul A. Chernoch]

DBD::ODBC Version 0.38 builds and passes the tests, but 0.39 wont even 
compile. Here are the error messages:

$ make
cp ODBC.pm blib/lib/DBD/ODBC.pm
/usr/bin/perl -p -e "s/~DRIVER~/ODBC/g" < 
/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI/Driver.xst > ODBC.xsi
/usr/bin/perl -I/usr/lib/perl5/5.6.1/cygwin-multi -I/usr/lib/perl5/5.6.1 
/usr/lib/perl5/5.6.1/ExtUtils/xsubpp  -typemap
/usr/lib/perl5/5.6.1/ExtUtils/typemap ODBC.xs > ODBC.xsc && mv ODBC.xsc ODBC.c
gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI 
-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include 
-DUSEIMPORTLIB -O2   -DVERSION=\"0.39\" 
-DXS_VERSION=\"0.39\"  -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE  ODBC.c
gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI 
-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include 
-DUSEIMPORTLIB -O2   -DVERSION=\"0.39\" 
-DXS_VERSION=\"0.39\"  -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE  dbdimp.c
dbdimp.c: In function `odbc_db_login6':
dbdimp.c:211: `SQL_ATTR_ODBC_VERSION' undeclared (first use in this function)
dbdimp.c:211: (Each undeclared identifier is reported only once
dbdimp.c:211: for each function it appears in.)
dbdimp.c:211: `SQL_IS_INTEGER' undeclared (first use in this function)
dbdimp.c: At top level:
dbdimp.c:1644: warning: `_dbd_rebind_ph' was declared implicitly `extern' 
and later `static'
dbdimp.c:1190: warning: previous declaration of `_dbd_rebind_ph'
make: *** [dbdimp.o] Error 1


When I look, the undeclared symbols are really, truly undefined. 
SQL_ATTR_ODBC_VERSION does not even appear to exist in version 0.38.

(BTW, as far as I can tell, the patch file used some time ago by CYGWIN 
users to fix the Makefile.pl has been fully incorporated into more recent 
builds, so I know that is not the problem.)

I just upgraded today to the latest version of CYGWIN, and with it comes 
perl v5.6.1.

   - Paul
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paul Anton Chernoch
Zeborg, Inc.
500 West Cummings Park
Woburn, MA 01801

t: 781.759.0105
f: 781.935.5090
c: 781.606.7382

http://www.zeborg.com
This message is a personal and confidential communication. If you are not
the intended recipient, please do not read, copy, or use it, and do not
disclose it to others. Please notify the sender of the delivery error by
replying to this message, and then delete it from your system. Thank you.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



--
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: Strange behavior of MSVC's printf under cygwin shell?

[Larry Hall (RFK Partners, Inc)]

At 04:38 PM 3/25/2002, Wirawan Purwanto wrote:
>Hi,
>
>Why does the screen output displayed using MSVC's printf subroutine not get
>shown immediately under Cygwin shell (bash, specifically)? Rather, it would
>wait for a long time before showing the text lines (many lines at once). How
>to change this behavior?
>
>I used the following (simple) code as an example:
>
>#include
>int main() {
> for (int i=0; i < 50; ++i) {
> printf("%d %d\n", i, i*i);
> for (int j=0; j < 1000; ++j); /* just for delay */
> }
> return 0;
>}
>
>Try to compile it using: gcc -mno-cygwin sample.c , then run it: ./a.exe. If
>you remove "-mno-cygwin", this strange behavior disappears. Under MS-DOS
>shell, this behavior does not exist.



The problem must be at your end.  I don't see it here.  Looks like you'll
need to debug it more.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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/

Strange behavior of MSVC's printf under cygwin shell?

[Wirawan Purwanto]

Hi,

Why does the screen output displayed using MSVC's printf subroutine not get
shown immediately under Cygwin shell (bash, specifically)? Rather, it would
wait for a long time before showing the text lines (many lines at once). How
to change this behavior?

I used the following (simple) code as an example:

#include
int main() {
for (int i=0; i < 50; ++i) {
printf("%d %d\n", i, i*i);
for (int j=0; j < 1000; ++j); /* just for delay */
}
return 0;
}

Try to compile it using: gcc -mno-cygwin sample.c , then run it: ./a.exe. If
you remove "-mno-cygwin", this strange behavior disappears. Under MS-DOS
shell, this behavior does not exist.

Thanks,
Wirawan

--
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: Visual debugging tools for Cygwin.

[Larry Hall (RFK Partners, Inc)]

At 04:03 PM 3/25/2002, Warren Postma wrote:

>Are there any semi-visual front ends for GDB, like RHIDE, for Cygwin?  I
>seem to remember Cygnus/RedHat used to sell one, is it still for sale, or
>now available elsewhere?


Can you be more specific?  What constitutes a "semi-visual front end" for 
gdb?  Should we assume that Insight isn't what you're looking for?



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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/

Visual debugging tools for Cygwin.

[Warren Postma]

Are there any semi-visual front ends for GDB, like RHIDE, for Cygwin?  I
seem to remember Cygnus/RedHat used to sell one, is it still for sale, or
now available elsewhere?


Warren


--
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: Programs fail to recognize paths.

[Andrew Markebo]

/ Michael Labhard <[EMAIL PROTECTED]> wrote:
| While trying to use cvs on cygwin (Windows XP) the command "cvs -d 
| /usr/local/cvs-repository update" returns the error "directory 
| /usr/local/cvs-repostory does not exist".  "ls" has no problem finding the 

Well the cvs you use has to be compiled with cygwin, sounds like it is
not, try to ask it to look in c:/cygwin/usr/local/cvs-repository or
with dos-ish backslashes.. 

/Andy

-- 
 The eye of the beholder rests on the beauty!

--
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: link error - missing user32?

[Larry Hall (RFK Partners, Inc)]

Good.  But you shouldn't need to do this unless the w32api package you 
downloaded is not current.  If it contains './' at the start of the paths in 
the tar file, then it's not current.  You would need to either do what you did 
or  delete and redownload a new w32api package, perhaps from a different 
mirror.  However, the current problem with setup that caused this issue has
been worked-around by repackaging w32api with the './' parts removed so
you shouldn't see this problem with any current download of w32api.

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX



At 02:56 PM 3/25/2002, Mark Rubin wrote:
>I resolved the issue by following the course of action listed in:
>
>http://www.cygwin.com/ml/cygwin/2002-03/msg01262.html
>
>I am not sure if this the best approach, but it worked.
>
>
>-Original Message-
>From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]]
>Sent: Monday, March 25, 2002 11:43 AM
>To: Mark Rubin; [EMAIL PROTECTED]
>Subject: Re: link error - missing user32?
>
>
>At 02:28 PM 3/25/2002, Mark Rubin wrote:
> >I just installed cygwin for the first time and I am having trouble linking hello.c 
>on Win2k. I read the FAQ and did a search in the archives for similar errors. 
>Although I found references to the same problem, I was not able to resolve it by 
>follow the same course of action as the other users. So far I have:
> >
> >-reinstalled everything
> >-reinstalled the w32 libs
> >
> >
> >Error is below:
> >
> >$ gcc hello.c
> >/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann
> >ot find -luser32
> >collect2: ld returned 1 exit status
> >
> >Any other suggestions?
>
>
>You'll need to be more specific about what you did and saw if you want 
>reasonable suggestions.  There's only two things I can suggest you try
>at this point:
>
>1. Use the setup from www.cygwin.com if you did not.
>2. Debug the problem.
>
>
>
>Larry Hall  [EMAIL PROTECTED]
>RFK Partners, Inc.  http://www.rfk.com
>838 Washington Street   (508) 893-9779 - RFK Office
>Holliston, MA 01746 (508) 893-9889 - FAX


--
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: link error - missing user32?

[Mark Rubin]

I resolved the issue by following the course of action listed in:

http://www.cygwin.com/ml/cygwin/2002-03/msg01262.html

I am not sure if this the best approach, but it worked.


-Original Message-
From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 25, 2002 11:43 AM
To: Mark Rubin; [EMAIL PROTECTED]
Subject: Re: link error - missing user32?


At 02:28 PM 3/25/2002, Mark Rubin wrote:
>I just installed cygwin for the first time and I am having trouble linking hello.c on 
>Win2k. I read the FAQ and did a search in the archives for similar errors. Although I 
>found references to the same problem, I was not able to resolve it by follow the same 
>course of action as the other users. So far I have:
>
>-reinstalled everything
>-reinstalled the w32 libs
>
>
>Error is below:
>
>$ gcc hello.c
>/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann
>ot find -luser32
>collect2: ld returned 1 exit status
>
>Any other suggestions?


You'll need to be more specific about what you did and saw if you want 
reasonable suggestions.  There's only two things I can suggest you try
at this point:

   1. Use the setup from www.cygwin.com if you did not.
   2. Debug the problem.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: link error - missing user32?

[Larry Hall (RFK Partners, Inc)]

At 02:28 PM 3/25/2002, Mark Rubin wrote:
>I just installed cygwin for the first time and I am having trouble linking hello.c on 
>Win2k. I read the FAQ and did a search in the archives for similar errors. Although I 
>found references to the same problem, I was not able to resolve it by follow the same 
>course of action as the other users. So far I have:
>
>-reinstalled everything
>-reinstalled the w32 libs
>
>
>Error is below:
>
>$ gcc hello.c
>/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann
>ot find -luser32
>collect2: ld returned 1 exit status
>
>Any other suggestions?


You'll need to be more specific about what you did and saw if you want 
reasonable suggestions.  There's only two things I can suggest you try
at this point:

   1. Use the setup from www.cygwin.com if you did not.
   2. Debug the problem.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: HELP: rxvt configuration

[Philippe Bastiani]

Thanks for your reply :)

I think that I understood my error concerning the menus in RXVT:

In my .Xdefaults file, I set the '.path' resource  to '$HOME'...when, rxvt
read this file, the HOME and the USER variables don't seem to be still
defined... so, rxvt cannot open my menu :(
This explains also why, when I open rxvt from rxvt terminal, the menu is
properly displayed: in this case, rxvt can use the current values of theses
variables...

Now, I set the '.path' resource to '/home/Philippe' and all seems ok... but,
I think that it is not the best solution...
How you resolved this problem ?

a+
Philippe



--
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/

link error - missing user32?

[Mark Rubin]

I just installed cygwin for the first time and I am having trouble linking hello.c on 
Win2k. I read the FAQ and did a search in the archives for similar errors. Although I 
found references to the same problem, I was not able to resolve it by follow the same 
course of action as the other users. So far I have:

-reinstalled everything
-reinstalled the w32 libs


Error is below:

$ gcc hello.c
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann
ot find -luser32
collect2: ld returned 1 exit status

Any other suggestions?



--
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: New version of setup.exe broken when running with WINE

[Christopher Faylor]

On Mon, Mar 25, 2002 at 06:50:35PM +0100, Sylvain Petreolle wrote:
>>Sorry, but it is not.  When an emulation environment does not properly
>>emulate Windows and causes a problem with a program, then it is not the
>>program's fault.
>
>I agree with you, but in that case, setup.exe wouldn't have function by
>the past ...

Sorry, but I can't parse this sentence.

If you are saying that a previous version setup used to work in Wine, then
the answer to that is "So?"   We're not going to confine ourselves to only
using things which work on Wine.

>>I really don't understand this line of thinking.  If you had a problem
>>running Powerpoint under Wine would you report it to Microsoft?
>
>Has been made many times by us...  and then more web sites are talking
>about compatibility of their programs with Wine.  Let's take HeadLight
>Software example.  After a few bug reports, they put a page about Wine
>and GetRight ...  it's running properly under Wine today.

That's just great for them.  As I said, this isn't a goal for cygwin.
Or, rather, if there are ways to configure wine such that it works
better with cygwin, then, sure, we can make that information available.
We're not going to modify cygwin to accomodate Wine.

>>Yeah, these are people reporting problems in *Wine*.
>>
>Not only.  Cygwin Bash is doing (maybe ?) unwanted access to COM1 port
>when run under Wine for example

Again, the answer is "So?" If bash is working correctly in its native
environment (Windows 9x/Me/NT/2000/XP), then it is working as designed.
If it is not working well on Wine, then it is very likely to be A WINE
PROBLEM.

If there is a real problem lurking somewhere that only manifests on Wine
for some reason, then you're welcome to debug it and submit a patch.
Since it doesn't seem to be affecting any of the audience for which
Cygwin was targetted, it is a non-issue for me, right now.

This is partially a practical matter.  Debugging a system like Wine
complicates things enormously.  Even if cygwin was doing something
strange with com ports, it could potentially take a lot of time
convincing oneself that this wasn't actually a Wine problem.  That
would mean debugging Wine to see what was going on.  Personally, I
have no interest and no time for such an undertaking.

>>I'd certainly reject any patch that I saw whose sole purpose was to add
>>Wine support to cygwin.  To answer your question: Cygwin is the power
>>company.  Wine is the hair dryer.  Fix the hair dryer.
>>
>Please give me a try : Cygwin & Wine are 2 power companies...  It would
>be great to make a dialog to fix problems of the BOTH parts, not only
>one...  You 'll only have benefit

As far as analogies go, the concept of two power companies doesn't work
anyway.

Anyway, to reiterate for the final time, if you want problems fixed that
manifest in Wine, you're probably on your own.  That's not a big deal
however.  The source code is available.  If you find an actual bug there
is no reason why you can't fix it.

By and large, this is how free software development works.  If you see
a need, it is much much more likely to get filled if you volunteer the
time to do it yourself.  That is what the miniscule number of people
working on this project are doing.

And, please don't come back with the "Not a programmer, don't have time,
it's to your benefit" argument.  None of those are relevant.  If you are
unable to do the work yourself then continuing to assert that it is of
some nebulous benefit to cygwin is fruitless.  Your best (and sometimes
only) leverage in a free software project is your own contribution.
Contributing arguments is often just a polarizing activity.  It doesn't
get any work done and just ends up pulling people away from things that
they could be doing.

It's possible that Wine *is* of some importance to someone who is
working on setup.exe or cygwin.  If it is, more power to them.  If this
mythical person starts submitting patches, however, I'm certainly going
to be inspecting them closely to make sure that we aren't adding
workarounds just for Wine.

If the patch entailed a way of doing things that worked around a problem
in Wine without impacting the code in any way either performance-wise or
clarity-wise, I'd probably accept it.

That's it.  I think I've made myself very clear on this issue.  I won't
be responding further.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.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: Make 'include' directive with Cygnus bash - path problem

[Christopher Faylor]

On Mon, Mar 25, 2002 at 05:52:48PM -, Ronnie Shipman wrote:
>More info:

We don't need more info:

http://sources.redhat.com/ml/cygwin/2002-03/msg01428.html
http://sources.redhat.com/ml/cygwin/2002-03/msg01432.html

The first reference tells you what you need to do if this was a
cygwin problem.

The second reference points out that you are not running a cygwin
version of make.  Don't expect a non-cygwin version of make to
understand /cygdrive constructions.

Let's end this thread now.

cgf

--
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: Make 'include' directive with Cygnus bash - path problem

[Larry Hall (RFK Partners, Inc)]

At 12:52 PM 3/25/2002, Ronnie Shipman wrote:
>More info:
>
>$ mount
>C:\cygwin\bin on /usr/bin type system (binmode)
>C:\cygwin\lib on /usr/lib type system (binmode)
>C:\cygwin on / type system (binmode)
>b: on /cygdrive/b type user (binmode,noumount)
>c: on /cygdrive/c type user (binmode,noumount)
>l: on /cygdrive/l type user (binmode,noumount)
>r: on /cygdrive/r type user (binmode,noumount)
>s: on /cygdrive/s type user (binmode,noumount)
>t: on /cygdrive/t type user (binmode,noumount)
>u: on /cygdrive/u type user (binmode,noumount)
>v: on /cygdrive/v type user (binmode,noumount)
>
>$ type make
>make is hashed (/cygdrive/c/ris/bin/make)
>
>$ cygcheck make
>Found: c:\ris\bin\make.exe
>Found: c:\Tornado\host\x86-win32\bin\make.exe
>Found: c:\gcc-2.95.2\bin\make.exe
>Found: c:\mks\mksnt\make.exe
>c:\ris\bin\make.exe
>   C:\WINNT\System32\KERNEL32.dll
> C:\WINNT\System32\NTDLL.DLL
>   C:\WINNT\System32\USER32.dll
> C:\WINNT\System32\GDI32.DLL


OK.  Just as I thought and as Johan Bezem picked up on with the previous 
information you sent.  Your problem is as he states.  Use the Cygwin version
of make and you won't have the problem you're reporting.


Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: Make 'include' directive with Cygnus bash - path problem

[Ronnie Shipman]

More info:

$ mount
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
b: on /cygdrive/b type user (binmode,noumount)
c: on /cygdrive/c type user (binmode,noumount)
l: on /cygdrive/l type user (binmode,noumount)
r: on /cygdrive/r type user (binmode,noumount)
s: on /cygdrive/s type user (binmode,noumount)
t: on /cygdrive/t type user (binmode,noumount)
u: on /cygdrive/u type user (binmode,noumount)
v: on /cygdrive/v type user (binmode,noumount)

$ type make
make is hashed (/cygdrive/c/ris/bin/make)

$ cygcheck make
Found: c:\ris\bin\make.exe
Found: c:\Tornado\host\x86-win32\bin\make.exe
Found: c:\gcc-2.95.2\bin\make.exe
Found: c:\mks\mksnt\make.exe
c:\ris\bin\make.exe
  C:\WINNT\System32\KERNEL32.dll
C:\WINNT\System32\NTDLL.DLL
  C:\WINNT\System32\USER32.dll
C:\WINNT\System32\GDI32.DLL

Use -h to see help about each section

$ echo $MAKE_MODE
unix

And to answer to obvious question:

$ ls -la /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test
-rw-r--r--1 Administ None   39 Mar 25 14:40
/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test

$ ls -la c:/RIS/Software/3G_Platform_2_5_make/makefile.test
-rw-r--r--1 Administ None   39 Mar 25 14:40
c:/RIS/Software/3G_Platform_2_5_make/makefile.test




> -Original Message-
> From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]]
> Sent: 25 March 2002 17:44
> To: Ronnie Shipman; '[EMAIL PROTECTED]'
> Subject: Re: Make 'include' directive with Cygnus bash - path problem
> 
> 
> Send the following to the list:
> 
>1. Output of 'mount'.
>2. Output of 'type make'
>3. Output of 'cygcheck make'
>4. Output of 'echo $MAKE_MODE'
> 
> Larry Hall  [EMAIL PROTECTED]
> RFK Partners, Inc.  http://www.rfk.com
> 838 Washington Street   (508) 893-9779 - RFK Office
> Holliston, MA 01746 (508) 893-9889 - FAX
> 
> 
> 
> At 12:27 PM 3/25/2002, Ronnie Shipman wrote:
> > > I have encountered a problem including makefiles.
> > > Here are two very simple example makefiles:
> > > 
> > > *** First simple makefile: makefile
> > > 
> > > TEMP=$(shell pwd)
> > > export
> > > 
> > > # Including this works
> > > include c:/RIS/Software/3G_Platform_2_5_make/makefile.test
> > > 
> > > #  Including this fails
> > > #include 
> /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test
> > > 
> > > 
> > > *** Second simple makefile (included by the first): makefile.test
> > > 
> > > all:
> > >   echo Hello World.
> > >   echo $(TEMP)
> > > 
> > > 
> > > This is the good case:
> > > 
> > > $ make all
> > > echo Hello World.
> > > Hello World.
> > > echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> > > /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> > > 
> > > If I include the bash path /cygdrive/c/... etc I get the 
> following error:
> > > 
> > > $ make all
> > > makefile:4: 
> /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test:
> > > No such file or directory
> > > c:\ris\bin\make.exe: *** No rule to make target
> > > 
> `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'.  Stop.
> > > 
> > > Is this a bug in make? Or bash? Or am I missing something here.
> > > 
> > > Please help.
> > > 
> > > 
> > > 
> > > My set up:
> > > 
> > > GNU make, Cygnus bash running on MS Windows 2000.
> > > 
> > > !::='::\'
> > > !C:='C:\cygwin\bin'
> > > ALLUSERSPROFILE='C:\Documents and Settings\All Users'
> > > APPDATA='C:\Documents and Settings\ubirs\Application Data'
> > > BASH=/usr/bin/bash
> > > BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="3" [4]="release"
> > > [5]="i686-pc-cygwin")
> > > BASH_VERSION='2.05a.0(3)-release'
> > > BIN_PATH='C:\RIS\bin'
> > > 
> C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\l
> ib;.;C:\ti\c
> > > 
> 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\incl
> ude;C:\ti\c6
> > > 000\rtdx\lib'
> > > 
> C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\l
> ib;.;C:\ti\c
> > > 
> 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\incl
> ude;C:\ti\c6
> > > 000\rtdx\lib'
> > > COLUMNS=80
> > > COMMONPROGRAMFILES='C:\Program Files\Common Files'
> > > COMPUTERNAME=UBI-DEV1
> > > COMSPEC='C:\WINNT\system32\cmd.exe'
> > > DIRSTACK=()
> > > EUID=500
> > > GROUPS=()
> > > HISTFILE=/home/Administrator/.bash_history
> > > HISTFILESIZE=500
> > > HISTSIZE=500
> > > HOME=/home/Administrator
> > > HOMEDRIVE=C:
> > > HOMEPATH='\'
> > > HOSTNAME=UBI-DEV1
> > > HOSTTYPE=i686
> > > IFS=$' \t\n'
> > > LINES=25
> > > LOGONSERVER='\\CAMATH01'
> > > MACHTYPE=i686-pc-cygwin
> > > MAILCHECK=60
> > > MAKESHELL=/usr/bin/sh
> > > MAKE_MODE=unix
> > > NUMBER_OF_PROCESSORS=1
> > > OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build
> > > OPTERR=1
> > > OPTIND=1
> > > OS=Windows_NT
> > > OS2LIBPATH='C:\WINNT\system32\os2\dll;'
> > > OSTYPE=cygwin
> > > 
> PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/

Re: Make 'include' directive with Cygnus bash - path problem

[Johan Bezem]

Hi Ronnie,

Ronnie Shipman wrote:
> 
> > I have encountered a problem including makefiles.

> > # Including this works
> > include c:/RIS/Software/3G_Platform_2_5_make/makefile.test
> >
> > #  Including this fails
> > #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test

> > PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi
> > n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin:
> > /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy
> > gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:
> > /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program
> > Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c
> > ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk
> > Shared/:/cygdrive/c/vslick/win'

> > ROOTDIR=c:/mks

> > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> > Built for Windows32


You seem to be running a non-cygwin version of GNU make 3.79.1. The CygWin version 
says:
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-cygwin
--^^

That version will not know about /cygdrive/...
Try the cygwin version.

Regards,

Johan Bezem
CSK Software AG

--
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: New version of setup.exe broken when running with WINE

[Sylvain Petreolle]

> Sorry, but it is not.  When an emulation environment
> does not properly
> emulate Windows and causes a problem with a program,
> then it is
> not the program's fault.
I agree with you, but in that case, setup.exe wouldn't
have function by the past ...

> I really don't understand this line of thinking.  If
> you had a problem
> running Powerpoint under Wine would you report it to
> Microsoft?
Has been made many times by us... and then more web
sites are talking about compatibility of their
programs
with Wine. Let's take HeadLight Software example.
After a few bug reports, they put a page about Wine
and GetRight ... it's running properly under Wine
today.

> Yeah, these are people reporting problems in *Wine*.
> 
Not only. Cygwin Bash is doing (maybe ?) unwanted
access to COM1 port when run under Wine for example

> I'd certainly reject any patch
> that I saw whose sole
> purpose was to add Wine support to cygwin.
> To answer your question: Cygwin is the power
> company.  Wine is the hair
> dryer.  Fix the hair dryer.
> 
Please give me a try : Cygwin & Wine are 2 power
companies... It would be great to make a dialog to fix
problems of the BOTH parts, not only one...
You 'll only have benefit


Note that I use both Wine and cygwin today...


___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.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: 1.3.10 gcc/g77 won't install, won't work

[FrancisDomoney]

Thanks Larry

as the instgructions about the mailing list says "you don't half feel 
virtuous when it goes in the end without having to ask for help"

"per ardua ad astra" as they say.

Regards

Frank

--
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: Make 'include' directive with Cygnus bash - path problem

[Larry Hall (RFK Partners, Inc)]

Send the following to the list:

   1. Output of 'mount'.
   2. Output of 'type make'
   3. Output of 'cygcheck make'
   4. Output of 'echo $MAKE_MODE'

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX



At 12:27 PM 3/25/2002, Ronnie Shipman wrote:
> > I have encountered a problem including makefiles.
> > Here are two very simple example makefiles:
> > 
> > *** First simple makefile: makefile
> > 
> > TEMP=$(shell pwd)
> > export
> > 
> > # Including this works
> > include c:/RIS/Software/3G_Platform_2_5_make/makefile.test
> > 
> > #  Including this fails
> > #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test
> > 
> > 
> > *** Second simple makefile (included by the first): makefile.test
> > 
> > all:
> >   echo Hello World.
> >   echo $(TEMP)
> > 
> > 
> > This is the good case:
> > 
> > $ make all
> > echo Hello World.
> > Hello World.
> > echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> > /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> > 
> > If I include the bash path /cygdrive/c/... etc I get the following error:
> > 
> > $ make all
> > makefile:4: /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test:
> > No such file or directory
> > c:\ris\bin\make.exe: *** No rule to make target
> > `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'.  Stop.
> > 
> > Is this a bug in make? Or bash? Or am I missing something here.
> > 
> > Please help.
> > 
> > 
> > 
> > My set up:
> > 
> > GNU make, Cygnus bash running on MS Windows 2000.
> > 
> > !::='::\'
> > !C:='C:\cygwin\bin'
> > ALLUSERSPROFILE='C:\Documents and Settings\All Users'
> > APPDATA='C:\Documents and Settings\ubirs\Application Data'
> > BASH=/usr/bin/bash
> > BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="3" [4]="release"
> > [5]="i686-pc-cygwin")
> > BASH_VERSION='2.05a.0(3)-release'
> > BIN_PATH='C:\RIS\bin'
> > C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c
> > 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6
> > 000\rtdx\lib'
> > C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c
> > 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6
> > 000\rtdx\lib'
> > COLUMNS=80
> > COMMONPROGRAMFILES='C:\Program Files\Common Files'
> > COMPUTERNAME=UBI-DEV1
> > COMSPEC='C:\WINNT\system32\cmd.exe'
> > DIRSTACK=()
> > EUID=500
> > GROUPS=()
> > HISTFILE=/home/Administrator/.bash_history
> > HISTFILESIZE=500
> > HISTSIZE=500
> > HOME=/home/Administrator
> > HOMEDRIVE=C:
> > HOMEPATH='\'
> > HOSTNAME=UBI-DEV1
> > HOSTTYPE=i686
> > IFS=$' \t\n'
> > LINES=25
> > LOGONSERVER='\\CAMATH01'
> > MACHTYPE=i686-pc-cygwin
> > MAILCHECK=60
> > MAKESHELL=/usr/bin/sh
> > MAKE_MODE=unix
> > NUMBER_OF_PROCESSORS=1
> > OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build
> > OPTERR=1
> > OPTIND=1
> > OS=Windows_NT
> > OS2LIBPATH='C:\WINNT\system32\os2\dll;'
> > OSTYPE=cygwin
> > PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi
> > n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin:
> > /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy
> > gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:
> > /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program
> > Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c
> > ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk
> > Shared/:/cygdrive/c/vslick/win'
> > PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
> > PIPESTATUS=([0]="2")
> > PPID=1
> > PROCESSOR_ARCHITECTURE=x86
> > PROCESSOR_IDENTIFIER='x86 Family 15 Model 1 Stepping 2, GenuineIntel'
> > PROCESSOR_LEVEL=15
> > PROCESSOR_REVISION=0102
> > PROGRAMFILES='C:\Program Files'
> > PROMPT='$P$G'
> > PS1=$'\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h
> > \\[\\033[33m\\w\\033[0m\\]\n$ '
> > PS2='> '
> > PS4='+ '
> > PWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make
> > ROOTDIR=c:/mks
> > SHELL=/usr/bin/sh
> > SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comme
> > nts:emacs
> > SHLVL=1
> > SYSTEMDRIVE=C:
> > SYSTEMROOT='C:\WINNT'
> > TEMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp
> > TERM=cygwin
> > TI_DIR='C:\ti'
> > TMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp
> > TMPDIR=/cygdrive/c/WINNT/TEMP
> > UID=500
> > USER=Administrator
> > USERDOMAIN=UK-MAIN
> > USERNAME=UBIRS
> > USERPROFILE='C:\Documents and Settings\ubirs'
> > WINDIR='C:\WINNT'
> > _=all
> > i='/etc/profile.d/*.sh'
> > 
> > 
> > 
> > 
> > 
> > 
> > GNU bash, version 2.05a.0(3)-release (i686-pc-cygwin)
> > Copyright 2001 Free Software Foundation, Inc.
> > 
> > 
> > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> > Built for Windows32
> > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 200

Re: Make 'include' directive with Cygnus bash - path problem

[Christopher Faylor]

On Mon, Mar 25, 2002 at 05:27:39PM -, Ronnie Shipman wrote:
>FYI: I have sent the same email to GNU...

GNU doesn't support the version of make that comes from cygwin.

If you want to see a problem fixed, you're going to have to debug make,
fix it, and send a ChangeLog/patch here.

cgf

--
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: 1.3.10 gcc/g77 won't install, won't work

[Ryu Myungsunn]

Sorry for the font difficulty.
I didn't test if binutils is working properly. But it shows its current version
as 20011002-1 in cygwin's 'packages to install' list -- unlike the gcc package.
And I didn't install g77 separately. I'm using g77 as the default subset of gcc
package. And the problem is not limited to g77; gcc shows the same symptom.
My trials do not include building g77 or gcc from source package. I only tried
installing pre-compiled binaries. So I do not understand what you mean by
'spurious -lm in the default setup... does not extend to a separate version of
gcc/g77 installed from source'.
I know the version is NOT the problem; I said I saw the very version working on
other machine.
I mostly suspect the new setup.exe(v2.195.2.15). Can I get the old
setup.exe(v2.125.2.10)?

Tim Prince wrote:

> On Monday 25 March 2002 06:06, Ryu Myungsunn wrote:
> > Recently I updated cygwin to 1.3.10 and got "installation incomplete
> > Check /setup.log.full" message. but no /setup.log.full was found.
> >
> > Later I discovered that g77(v0.5.25) won't produce .exe files while
> > producing .o files.
> > This was the same with gcc(v2.95.3-5).
> > The same versions of gcc and g77 work nicely on solaris7-sparc
> > environment.
> >
> Your font is quite difficult to read here.
> It's not your g77 version.  You may have somehow introduced breakage
> (possibly in more than one place) in your g77 linkage setup.  Since you give
> no particulars, anyone trying to help you would be guessing.  You haven't
> even revealed whether you got binutils installed.  One of the common problems
> with the cygwin setup is the introduction of a spurious -lm in the default
> g77 setup.  Such breakage in the g77 version installed by cygwin does not
> necessarily extend to a separate version of gcc/g77 installed from source.
> --
> Tim Prince

--
??
   Ryu Myungsunn, Organic EL Group
  +82-2-526-4498
LG Elite
??



--
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/

Make 'include' directive with Cygnus bash - path problem

[Ronnie Shipman]

> I have encountered a problem including makefiles.
> Here are two very simple example makefiles:
> 
> *** First simple makefile: makefile
> 
> TEMP=$(shell pwd)
> export
> 
> # Including this works
> include c:/RIS/Software/3G_Platform_2_5_make/makefile.test
> 
> #  Including this fails
> #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test
> 
> 
> *** Second simple makefile (included by the first): makefile.test
> 
> all:
>   echo Hello World.
>   echo $(TEMP)
> 
> 
> This is the good case:
> 
> $ make all
> echo Hello World.
> Hello World.
> echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> /cygdrive/c/RIS/Software/3G_Platform_2_5_make
> 
> If I include the bash path /cygdrive/c/... etc I get the following error:
> 
> $ make all
> makefile:4: /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test:
> No such file or directory
> c:\ris\bin\make.exe: *** No rule to make target
> `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'.  Stop.
> 
> Is this a bug in make? Or bash? Or am I missing something here.
> 
> Please help.
> 
> 
> 
> My set up:
> 
> GNU make, Cygnus bash running on MS Windows 2000.
> 
> !::='::\'
> !C:='C:\cygwin\bin'
> ALLUSERSPROFILE='C:\Documents and Settings\All Users'
> APPDATA='C:\Documents and Settings\ubirs\Application Data'
> BASH=/usr/bin/bash
> BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="3" [4]="release"
> [5]="i686-pc-cygwin")
> BASH_VERSION='2.05a.0(3)-release'
> BIN_PATH='C:\RIS\bin'
> C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c
> 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6
> 000\rtdx\lib'
> C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c
> 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6
> 000\rtdx\lib'
> COLUMNS=80
> COMMONPROGRAMFILES='C:\Program Files\Common Files'
> COMPUTERNAME=UBI-DEV1
> COMSPEC='C:\WINNT\system32\cmd.exe'
> DIRSTACK=()
> EUID=500
> GROUPS=()
> HISTFILE=/home/Administrator/.bash_history
> HISTFILESIZE=500
> HISTSIZE=500
> HOME=/home/Administrator
> HOMEDRIVE=C:
> HOMEPATH='\'
> HOSTNAME=UBI-DEV1
> HOSTTYPE=i686
> IFS=$' \t\n'
> LINES=25
> LOGONSERVER='\\CAMATH01'
> MACHTYPE=i686-pc-cygwin
> MAILCHECK=60
> MAKESHELL=/usr/bin/sh
> MAKE_MODE=unix
> NUMBER_OF_PROCESSORS=1
> OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build
> OPTERR=1
> OPTIND=1
> OS=Windows_NT
> OS2LIBPATH='C:\WINNT\system32\os2\dll;'
> OSTYPE=cygwin
> PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi
> n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin:
> /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy
> gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:
> /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program
> Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c
> ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk
> Shared/:/cygdrive/c/vslick/win'
> PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
> PIPESTATUS=([0]="2")
> PPID=1
> PROCESSOR_ARCHITECTURE=x86
> PROCESSOR_IDENTIFIER='x86 Family 15 Model 1 Stepping 2, GenuineIntel'
> PROCESSOR_LEVEL=15
> PROCESSOR_REVISION=0102
> PROGRAMFILES='C:\Program Files'
> PROMPT='$P$G'
> PS1=$'\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h
> \\[\\033[33m\\w\\033[0m\\]\n$ '
> PS2='> '
> PS4='+ '
> PWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make
> ROOTDIR=c:/mks
> SHELL=/usr/bin/sh
> SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comme
> nts:emacs
> SHLVL=1
> SYSTEMDRIVE=C:
> SYSTEMROOT='C:\WINNT'
> TEMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp
> TERM=cygwin
> TI_DIR='C:\ti'
> TMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp
> TMPDIR=/cygdrive/c/WINNT/TEMP
> UID=500
> USER=Administrator
> USERDOMAIN=UK-MAIN
> USERNAME=UBIRS
> USERPROFILE='C:\Documents and Settings\ubirs'
> WINDIR='C:\WINNT'
> _=all
> i='/etc/profile.d/*.sh'
> 
> 
> 
> 
> 
> 
> GNU bash, version 2.05a.0(3)-release (i686-pc-cygwin)
> Copyright 2001 Free Software Foundation, Inc.
> 
> 
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> Built for Windows32
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
>   Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> Report bugs to <[EMAIL PROTECTED]>.
> 
> 
FYI: I have sent the same email to GNU...

--
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: Networking problem

[Larry Hall (RFK Partners, Inc)]

At 12:06 PM 3/25/2002, Christopher Faylor wrote:
>On Mon, Mar 25, 2002 at 09:46:50AM -0500, Larry Hall (RFK Partners, Inc) wrote:
> >At 01:02 AM 3/25/2002, Rajaraman B wrote:
> >>There is no support for IP_HDRINCL socket option.  Many header files
> >
> >Check out Winsock capabilities in this area.  Cygwin's socket support
> >is dependent on Winsock functionality.
>
>Of course patches to augment Cygwin are always cheerfully accepted, too.
>If Winsock can do it, then Cygwin should be able to do it.



Good point.  Thanks for picking up on this rather large omission of the
facts on my part.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: New version of setup.exe broken when running with WINE

[Christopher Faylor]

On Mon, Mar 25, 2002 at 03:07:55PM +0100, Sylvain Petreolle wrote:
>Seriously, Trying to run cygwin under WINE environment is a good
>testcase for both power companies (ie cygwin and wine :)).

Sorry, but it is not.  When an emulation environment does not properly
emulate Windows and causes a problem with a program, then it is
not the program's fault.

I really don't understand this line of thinking.  If you had a problem
running Powerpoint under Wine would you report it to Microsoft?

>The goal of a bug entry created for wine is to run bash/sh in WINE
>environment.  If someone is interested you can look at
>http://bugs.codeweavers.com/show_bug.cgi?id=443

Yeah, these are people reporting problems in *Wine*.

>Various cygwin programs function at this day (mount,ls, and several
>others).
>
>Thanks by advance, Sylvain.

What are you thanking for?  I'm pretty sure that no one who is working
on cygwin or setup.exe is interested in expending effort to get things
working on Wine.  I'd certainly reject any patch that I saw whose sole
purpose was to add Wine support to cygwin.

To answer your question: Cygwin is the power company.  Wine is the hair
dryer.  Fix the hair dryer.

cgf

--
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: Networking problem

[Christopher Faylor]

On Mon, Mar 25, 2002 at 09:46:50AM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 01:02 AM 3/25/2002, Rajaraman B wrote:
>>There is no support for IP_HDRINCL socket option.  Many header files
>
>Check out Winsock capabilities in this area.  Cygwin's socket support
>is dependent on Winsock functionality.

Of course patches to augment Cygwin are always cheerfully accepted, too.
If Winsock can do it, then Cygwin should be able to do it.

cgf

--
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: Fwd: 1.3.10 gcc/g77 won't install, won't work

[Larry Hall (RFK Partners, Inc)]

At 11:41 AM 3/25/2002, you wrote:
>  
>Return-path: <[EMAIL PROTECTED]>
>From: [EMAIL PROTECTED]
>Full-name: Francis  Domoney
>Message-ID: <[EMAIL PROTECTED]>
>Date: Mon, 25 Mar 2002 09:52:35 EST
>Subject: Re: 1.3.10 gcc/g77 won't install, won't work
>To: [EMAIL PROTECTED]
>MIME-Version: 1.0
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>X-Mailer: AOL 7.0 for Windows UK sub 52
>
>Hi
>
>I had an awful week fighting with install.  I kept getting the same error to 
>do with being unable to find -user32.  Folowing the isnstuctions about not 
>sending messages to the list about old problems I persevered.
>
>The archive told me that this was to do with an incomplete download, so I 
>tried and tried again from one of the Uk mirrors.  (for five days)
>
>Eventually in desperation I tried a German mirror and reinstalled gcc. 
>because the intelligent istall knows what files to install. The German mirror 
>downloaded a half dozen files I didnt seem to have got from the Uk mirror.
>
>Boy was I glad when I finally got hello world to compile and run.
>
>I am a newby so I am by no means accusing any mirror of anything.  I just 
>found the simple download and isntall of all damn difficult.


Sorry for your problems.  There is a bug in the current setup that causes it
trouble when it installs packages in a form that it doesn't expect.  This 
issue has been worked-around by repackaging the "offending" packages.  You
shouldn't see the -luser32 problem anymore but it may take some time to 
propagate to all the mirrors.  Trying other mirrors if this problem occurs
for you is a good strategy.  The w32api package is the one at "fault" and is
the only one you should need to redownload and reinstall if this problem 
occurs for you.

There also may be an issue with the new setup's ability to correctly handle
symbolic links.  This has recently been reported as a possible cause of the
problems people have been having getting g++ to properly install.  The jury
is still out on this one and the only work-around I can think of in the
meantime if you're caught by this one is to install the gcc tar file manually
(using tar, not WinZip!)





Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: cygwin1.dll bug in ftime

[Christopher Faylor]

On Mon, Mar 25, 2002 at 04:48:49PM +0800, Wu Yongwei wrote:
>This is from the glibc documentation (is glibc meaningless to the Cygwin
>project?):

Yes.

cgf

--
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/

Fwd: 1.3.10 gcc/g77 won't install, won't work

[FrancisDomoney]

 

--- Begin Message ---

Hi

I had an awful week fighting with install.  I kept getting the same error to 
do with being unable to find -user32.  Folowing the isnstuctions about not 
sending messages to the list about old problems I persevered.

The archive told me that this was to do with an incomplete download, so I 
tried and tried again from one of the Uk mirrors.  (for five days)

Eventually in desperation I tried a German mirror and reinstalled gcc. 
because the intelligent istall knows what files to install. The German mirror 
downloaded a half dozen files I didnt seem to have got from the Uk mirror.

Boy was I glad when I finally got hello world to compile and run.

I am a newby so I am by no means accusing any mirror of anything.  I just 
found the simple download and isntall of all damn difficult.

Regards

Frank


--- End Message ---

--
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/

sed problem with procmail

[Andrew DeFaria]

I have procmail reciepes such as the following:

:0
* !^From:.*@.com
* !^From:.*@.com
{
# Fall through
}

:0 E
| formail -rf -I "X-Mailer: AD Spam Canceller" \
   -i "Subject: Your mail is suspected of being SPAM and has been filtered! (24)"
  | \
   cat - "$SPAMREPLY" | sendmail -t

Where  and  are domains that I filter out totally. $SPAMREPLY is 
defined to
point to a file and sendmail is setup to be exim.

Now the filtering works except I see the following in my procmail log:


 From @.com  Sun Mar 24 13:21:35 2002
  Subject: NO OTHER Spy/Security CD Like THIS
   Folder:  formail -rf -I "X-Mailer: AD Spam Canceller" \   -i "Subjec 1484
sed: -e expression #1, char 11: No previous regular expression

Hmmm... I didn't call sed at all here! Why's it complaining? Also, sometimes I get the 
following:

Usage: formail [-vbczfrktqY] [-D nnn idcache] [-p prefix] [-l folder]
 [-xXaAiIuU field] [-R ofield nfield]
Or: formail [+nnn] [-nnn] [-bczfrktedqBY] [-D nnn idcache] [-p prefix]
 [-n [nnn]] [-m nnn] [-l folder] [-xXaAiIuU field] [-R ofield nfield]
 -s [prg [arg ...]]

But that *is* how I am calling formail. Again, any ideas as to why this is happening?

I know that these are more procmail questions than Cygwin questions except this whole 
setup was
transfered from my domain which was running FreeBSD and did not exhibit these problems.




--
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: procmail locking problem warning (was Re: procmail on cygwin)

[Jason Tishler]

Greg,

On Sun, Mar 24, 2002 at 05:50:32AM +0800, Greg Matheson wrote:
> On Fri, 22 Mar 2002, Jason Tishler wrote:
> > Occasionally, I would get errors such as the following in my procmail.log
> > file:
> 
> > procmail: Error while writing to "/var/spool/mail/jt"
> > procmail: Truncated file to former size
> 
> Mmh. I see one such error in my procmail log.

I guess that you are lucky then or your MUA only uses dotlocking (i.e.,
does not use fcntl).  What MUA are you using?  My MUA is mutt 1.3.24i
and it uses both fcntl() and dotlocking.

> > I have temporarily "fixed" the problem by commented out the "#define
> > NOfcntl_lock" in autoconf.h while I wade through the obfuscated procmail
> > coding style.
> 
> An alternative would be not to look at your mail while
> downloading it. 

IMO, the above is unacceptable -- it defeats the whole purpose of
running fetchmail as a daemon.

> Is there any reason for not crossposting your message to a
> procmail list, eg [EMAIL PROTECTED] or
> [EMAIL PROTECTED]?

Just laziness.

> The number of people on both
> procmail and cygwin lists must be very small, but the procmail
> developers (ie Philip Guenther) should be made aware of the
> autoconf problem.

Agreed, but I give no ETA.  Although, note that this is important to
me so it will probably happen sooner rather than later.  Nevertheless,
you are welcome to beat me to it.  If so, then please CC me so I won't
duplicate the effort.

Thanks,
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: no exec files from gcc and c++

[John Marshall]

Jean-Marc Nuzillard wrote:
> g++ -c hello.cpp
> -> g++ not found, took some time to think to try c++

I think at least this part of your problems is due to another bug in
setup.exe 2.194.2.15.  (I've looked briefly for relevant discussion here
and on cygwin-apps and seen none -- sorry if this is already known.)

According to http://www.cygwin.com/packages/, the gcc package contains

72192 2001-06-17 22:02:45 usr/bin/c++.exe
35328 2001-06-17 22:02:45 usr/bin/c++filt.exe
72704 2001-06-17 22:02:45 usr/bin/cpp.exe
0 2001-06-17 22:02:45 usr/bin/g++.exe link to usr/bin/c++.exe

If you look in setup.log.full I suspect you'll see that extraction of
g++.exe failed.  I suspect current setup.exe is not dealing with links
in tarball packages correctly.

One of my users alerted me to this problem in my prc-tools package
today.  Files listed as "link to [previous file in tarball]" were not
being extracted by setup.exe 2.194.2.15, and would be absent from the
resulting installation.  OTOH setup.exe 2.125.2.10 given the same
tarball extracted them correctly.

John

--
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/

Recreating gcc package

[Lars Munch]

Hi

Could someone provide me with information on how to recreate the gcc
package? I could not find any information in /usr/doc/gcc or in the gcc
source tarball.

Thanks a lot
Lars Munch

--
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/

Programs fail to recognize paths.

[Michael Labhard]

While trying to use cvs on cygwin (Windows XP) the command "cvs -d 
/usr/local/cvs-repository update" returns the error "directory 
/usr/local/cvs-repostory does not exist".  "ls" has no problem finding the 
directory and it is possible to cd to the directory.  Thought this might be 
due to installing the cvs binary so downloaded and build/installed cvs from 
souce in cygwin.  No improvement.

While using gvim (started from a cygwin command prompt) if there is a Windows 
directory c:\cygwin\usr\wx2 that has been mounted as /usr/wx2, gvim can see 
the directory but cannot see the files in it or subdirectories of it. 
 If one first cd's to the /usr/wx2 then gvim can see all files in the 
directory.

Any help understanding and correcting these problems would be greatly 
appreciated.  Thank you.

-- Michael

--
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: Cygwin/DJGPP and memory

[Larry Hall (RFK Partners, Inc)]

There is no imposed limit on memory in Cygwin beyond heap_chunk_in_mb
(which defaults to 128MB).  You should be able to allocate either the amount 
indicated by heap_chunk_in_mb or total available memory, whichever
is less.

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX



At 09:54 AM 3/25/2002, G.Spagnuolo wrote:
>Thanks for your reply.
>So, the total memory is the only limit. I'm reading about a mysterious 256MB limit of 
>cygwin: what about it?
>With respect to DJGPP, by cygwin I am able to use the virtual memory. Is this true?
>Thanks again
>
>gs
>
>
>At 09.48 25/03/2002 -0500, you wrote:
>>At 08:54 AM 3/25/2002, G.Spagnuolo wrote:
>> >Dear all,
>> >I'm browsing the mailing list archive about the limits on memory allocation under 
>cygwin, but I've not yet a complete picture.
>> >What is the real limit when I use new[] in a C++ program? The one I set in 
>windows2000 register heap_chunk_in_mb?
>>
>>
>>Yep!  Assuming, of course, that you have that much total memory (physical +
>>swap) space available for use.
>>
>>
>>
>>Larry Hall  [EMAIL PROTECTED]
>>RFK Partners, Inc.  http://www.rfk.com
>>838 Washington Street   (508) 893-9779 - RFK Office
>>Holliston, MA 01746 (508) 893-9889 - FAX
>
>--
>Dr. Giovanni Spagnuolo, Ph.D.
>Assistant Professor
>University of Salerno
>Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica (D.I.I.I.E.)
>Via Ponte Don Melillo
>84084 Fisciano - Salerno - Italy
>phone: +39 089 964258
>fax: +39 089 964218
>e-mail: [EMAIL PROTECTED]
>
>"You can tell whether a man is clever by his answers.
>You can tell whether a man is wise by his questions."
>Naguib Mahfouz
>
>
>--
>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/


--
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/

Your (Our) Problem

[Keen Wayne A Contr AFRL/MNGG]

I am having a similar problem to what you describe, and I think it is the
same as a
thread from earlier in the weekend about gcc and perl etc. not installing.

On my home machine, I tried many times to get gcc to install from the new
setup
(install over the internet anyway).  Each time I got the same incomplete
installation
message.  The log file by the way, at least for me, was down in my regular
Cygwin
directories.  I did not see anything in there of the nature of "this did not
work". Each
time I would try again to install, gcc would be marked as "skip".  There
would be
no "uninstall" option either, just skip or install.

One additional point.  When I would perform gcc -v, it would pull up my
secondary
install of gcc-3.0.4, and doing 

which g++

yields the version in /usr/local/bin, which is again, the gcc-3.0.4.

It may be that having the secondary install of gcc is causing a problem for
the
new version of setup.  In which case the problem is not the fault of setup,
but mine.

There did appear to be an unofficial looking consensus on a thread this
weekend
that some of the problems in this area could be fixed by downloading the
distribution to the local drive, then using an older version of setup to do
the
install. I have not tried this.

Wayne Keen

--
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: [ANNOUNCEMENT] Setup.exe update

[Gaethofs, Danny]

aha, 

Current version downloaded is 2.194.2.15.

A few days (19 march 2002) before we still had 2.125.2.10.

Danny

-Original Message-
From: David Starks-Browning [mailto:[EMAIL PROTECTED]]
Sent: maandag 25 maart 2002 16:14
To: Gaethofs, Danny
Cc: [EMAIL PROTECTED]
Subject: RE: [ANNOUNCEMENT] Setup.exe update


On Monday 25 Mar 02, Gaethofs, Danny writes:
> Dear David,
> 
> I earlier posted a mail of setup creating new menu entries in my install
> directory. I have looked at the setup version that was being used and
found,
> just downloaded it today, version: 2.194.2.15, while I was under the
> impression using an other version. 

(huh?)

> Can somebody elaborate on which version we currently are?

Can't you just download  and run it?  It
should tell you what version it is.

David


--
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: [ANNOUNCEMENT] Setup.exe update

[David Starks-Browning]

On Monday 25 Mar 02, Gaethofs, Danny writes:
> Dear David,
> 
> I earlier posted a mail of setup creating new menu entries in my install
> directory. I have looked at the setup version that was being used and found,
> just downloaded it today, version: 2.194.2.15, while I was under the
> impression using an other version. 

(huh?)

> Can somebody elaborate on which version we currently are?

Can't you just download  and run it?  It
should tell you what version it is.

David


--
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/

Shared libraries.

[Wiebe de Vries]

Hello,

I'm trying to build and use shared libraries with Cygwin under Windows 2000.
The first step, i.e. building the library, succeeds. I get a libmylib.so
(together with libmylib.so.1 and limmylib.so.1.0.0). However, linking is a
problem. I've written a small program which uses libmylib.so and try to link
it as follows:

g++ -o testprogram.exe testprogram.o -L/usr/src/DynLib -lmylib

This results in the error:


/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lmylib

For information the entire output when executing make clean:

rm -f   PrintTest.o  PrintTest.exe.exe PrintTest.d *~
make
make[1]: Entering directory `/usr/src/dynlibtest'
g++ -M  -Wall  PrintTest.cpp > PrintTest.d
g++ -M  -Wall  PrintTest.cpp | sed s/\\.o/.d/ >> PrintTest.d
make[1]: Leaving directory `/usr/src/dynlibtest'
make[1]: Entering directory `/usr/src/dynlibtest'
g++ -Wall-c -o PrintTest.o PrintTest.cpp
g++  -o PrintTest.exe   PrintTest.o  -L/usr/src/DynLib -lmylib
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lmylib
collect2: ld returned 1 exit status
make[1]: *** [PrintTest.exe] Error 1
make[1]: Leaving directory `/usr/src/dynlibtest'
make: *** [clean] Error 2

When using:

g++ -o PrintTest.exe PrintTest.o libmylib.so

I get the error:

collect2: ld terminated with signal 11 [Segmentation fault]

Can someone tell me what I'm doing wrong?

Kind regards, Wiebe de Vries.



Pecoma *  ICT-professionals *  http://www.pecoma.nl

Is deze e-mail niet voor u bedoeld? Laat het ons even weten. Bij voorbaat dank. Dit 
e-mailbericht is gecontroleerd op computervirussen met MIMEsweeper.

--
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: Networking problem

[Jesper Eskilson]

"Larry Hall (RFK Partners, Inc)" <[EMAIL PROTECTED]> writes:

> Check out Winsock capabilities in this area.  Cygwin's socket support is 
> dependent on Winsock functionality.

If you want to be able to send and receive raw ethernet frames, your best
be is to take a look at WinPcap. (Use Google; I don't have the exact URL in
my head).

-- 
/Jesper


--
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: crypt command

[Mark Himsley]

On Mon, 25 Mar 2002 09:22:28 -0500 you wrote:

>I looked at it.  The crypt that comes with cygwin appears to do something
>different than [I, Sanjay] expected, at least on at least Sanjay's system 
>and mine.

[snip]
>I conclude that this crypt is designed to only print out a key for a given
>salt/password.
>
>Am I correct?

yes

>If so, what is this utility generally used for?

It is generally used for creating the one-way crypt of a password used in
unix /etc/passwd files or Apache on Unix authentication files. The cygwin
version also allows the passing of a salt. Both the password and the salt
must be passed on the command line and not on stdin, the resulting crypt is
available on stdout.

Its very easy to knock your self up a crypt. Perl has a crypt function so it
should be very easy to create a crypt that takes the plain text password on
stdin. It would also very easy to do in 'C' (although it appears that mcrypt
will do the job).

-- 
Mark Himsley
In Acton

--
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: [ANNOUNCEMENT] Setup.exe update

[Gaethofs, Danny]

Dear David,

I earlier posted a mail of setup creating new menu entries in my install
directory. I have looked at the setup version that was being used and found,
just downloaded it today, version: 2.194.2.15, while I was under the
impression using an other version. 

Can somebody elaborate on which version we currently are?

regards,
Danny

-Original Message-
From: David Starks-Browning [mailto:[EMAIL PROTECTED]]
Sent: maandag 25 maart 2002 15:51
To: Cliff Hones
Cc: [EMAIL PROTECTED]; Cliff Hones (E-mail)
Subject: Re: [ANNOUNCEMENT] Setup.exe update


On Monday 25 Mar 02, Cliff Hones writes:
> Despite having followed the various posts, I am
> still confused by the current status of setup.exe,
> and I doubt if I'm alone.
> 
> Robert announced the new version on 19th March.
> I downloaded setup.exe shortly after (but didn't use it)
> and found I had got version 2.194.2.15.  After a flurry
> of mails about -luser32 and problems with mountpoints and w32api,
> cgf announced on 21st March that setup.exe was being reverted
> until the problem was fixed.
> 
> I just tried downloading setup.exe again and found I
> still got 2.194.2.15.

We figured out how to work around the "missing -luser32" problem by
repacking a couple of packages.  So it was no longer necessary to have
pulled the latest setup.  So it's back.

David


--
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/


--
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: Cygwin/DJGPP and memory

[G.Spagnuolo]

Thanks for your reply.
So, the total memory is the only limit. I'm reading about a mysterious 
256MB limit of cygwin: what about it?
With respect to DJGPP, by cygwin I am able to use the virtual memory. Is 
this true?
Thanks again

gs


At 09.48 25/03/2002 -0500, you wrote:
>At 08:54 AM 3/25/2002, G.Spagnuolo wrote:
> >Dear all,
> >I'm browsing the mailing list archive about the limits on memory 
> allocation under cygwin, but I've not yet a complete picture.
> >What is the real limit when I use new[] in a C++ program? The one I set 
> in windows2000 register heap_chunk_in_mb?
>
>
>Yep!  Assuming, of course, that you have that much total memory (physical +
>swap) space available for use.
>
>
>
>Larry Hall  [EMAIL PROTECTED]
>RFK Partners, Inc.  http://www.rfk.com
>838 Washington Street   (508) 893-9779 - RFK Office
>Holliston, MA 01746 (508) 893-9889 - FAX

--
Dr. Giovanni Spagnuolo, Ph.D.
Assistant Professor
University of Salerno
Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica 
(D.I.I.I.E.)
Via Ponte Don Melillo
84084 Fisciano - Salerno - Italy
phone: +39 089 964258
fax: +39 089 964218
e-mail: [EMAIL PROTECTED]

"You can tell whether a man is clever by his answers.
You can tell whether a man is wise by his questions."
Naguib Mahfouz


--
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: [ANNOUNCEMENT] Setup.exe update

[David Starks-Browning]

On Monday 25 Mar 02, Cliff Hones writes:
> Despite having followed the various posts, I am
> still confused by the current status of setup.exe,
> and I doubt if I'm alone.
> 
> Robert announced the new version on 19th March.
> I downloaded setup.exe shortly after (but didn't use it)
> and found I had got version 2.194.2.15.  After a flurry
> of mails about -luser32 and problems with mountpoints and w32api,
> cgf announced on 21st March that setup.exe was being reverted
> until the problem was fixed.
> 
> I just tried downloading setup.exe again and found I
> still got 2.194.2.15.

We figured out how to work around the "missing -luser32" problem by
repacking a couple of packages.  So it was no longer necessary to have
pulled the latest setup.  So it's back.

David


--
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: Cygwin/DJGPP and memory

[Larry Hall (RFK Partners, Inc)]

At 08:54 AM 3/25/2002, G.Spagnuolo wrote:
>Dear all,
>I'm browsing the mailing list archive about the limits on memory allocation under 
>cygwin, but I've not yet a complete picture.
>What is the real limit when I use new[] in a C++ program? The one I set in 
>windows2000 register heap_chunk_in_mb?


Yep!  Assuming, of course, that you have that much total memory (physical +
swap) space available for use.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: [ANNOUNCEMENT] Setup.exe update

[Cliff Hones]

Despite having followed the various posts, I am
still confused by the current status of setup.exe,
and I doubt if I'm alone.

Robert announced the new version on 19th March.
I downloaded setup.exe shortly after (but didn't use it)
and found I had got version 2.194.2.15.  After a flurry
of mails about -luser32 and problems with mountpoints and w32api,
cgf announced on 21st March that setup.exe was being reverted
until the problem was fixed.

I just tried downloading setup.exe again and found I
still got 2.194.2.15.

So, did I manage to miss the "bad" setup.exe, or is
it still downloading from www.cygwin.com?

I've been holding off doing any updates, expecting
another announcement "any day" - but as I've not seen one
I now don't know whether to use 2.194.2.15, or the
previous version I still have (2.125.2.10).
I did try 2.194.2.15 in download mode, and got
odd results which I've previously reported.

Yes, I'm sure I could look into this further myself
given time - but I'd have thought this would be wasted
if Robert & Co are as I suspect already beavering away
trying to iron out these problems.
 
-- Cliff



--
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: Networking problem

[Larry Hall (RFK Partners, Inc)]

At 01:02 AM 3/25/2002, Rajaraman B wrote:
>Hi,
> There is no support for IP_HDRINCL socket option. Many header files


Check out Winsock capabilities in this area.  Cygwin's socket support is 
dependent on Winsock functionality.



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: cygwin1.dll bug in ftime

[Larry Hall (RFK Partners, Inc)]

Sounds to me like Cygwin is SUS-compliant here to me.  Perhaps you'd get a
more sympathetic response if you posted code that does what you need, is 
itself SUS-compliant, and has trouble on Cygwin but not other SUS-compliant
platforms.  While it's always preferable that bug reports come with patches
for review, a simple, clear test case which shows the problem effectively is
the next best thing.  Sometimes it even prods someone else to fix the problem
you're seeing! ;-)

Just a thought,

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX



At 08:10 AM 3/25/2002, Wu Yongwei wrote:
>Thank you for your suggestions. The points are:
>
>1) Cygwin did very well, but not now;
>
>2) I was not using ftime to get time, but to get timezone information.
>
>3) timezone variable is not usable in Cygwin.
>
>So timezone is now not portable. Cygwin broke some "unportable" code.
>
>Best regards,
>
>Wu Yongwei
>
>"Fleischer, Karsten (K.)" wrote:
> > 
> > > Also notes the usage of "unspecified". "Unspecified" means
> > > the standard does
> > > not say anything about the implementation, and, IMHO, the
> > > implementors are
> > > free to choose the best practices.
> > 
> > ... or to not implement anything at all.
> > 
> > > I think it is obviously a
> > > good way to
> > > follow BSD.
> > 
> > Possibly.
> > The better way for application developers is to follow the Single UNIX > 
>Specification.
> > Any application relying on results that are explicitely marked as
> > "unspecified" in the SUS standard can be considered non-portable.
> > 
> > >From the SUSv3 documentation:
> > 
> > APPLICATION USAGE
> > For applications portability, the time() function should be used to
> > determine the current time instead of ftime().
> > 
> > Karsten
>
>--
>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/


--
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: 1.3.10 gcc/g77 won't install, won't work

[Tim Prince]

On Monday 25 March 2002 06:06, Ryu Myungsunn wrote:
> Recently I updated cygwin to 1.3.10 and got "installation incomplete
> Check /setup.log.full" message. but no /setup.log.full was found.
>
> Later I discovered that g77(v0.5.25) won't produce .exe files while
> producing .o files.
> This was the same with gcc(v2.95.3-5).
> The same versions of gcc and g77 work nicely on solaris7-sparc
> environment.
>
Your font is quite difficult to read here.
It's not your g77 version.  You may have somehow introduced breakage 
(possibly in more than one place) in your g77 linkage setup.  Since you give 
no particulars, anyone trying to help you would be guessing.  You haven't 
even revealed whether you got binutils installed.  One of the common problems 
with the cygwin setup is the introduction of a spurious -lm in the default 
g77 setup.  Such breakage in the g77 version installed by cygwin does not 
necessarily extend to a separate version of gcc/g77 installed from source.
-- 
Tim Prince

--
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: crypt command

[Richard Campbell]

I looked at it.  The crypt that comes with cygwin appears to do something
different than [I, Sanjay] expected, at least on at least Sanjay's system 
and mine.

Output from crypt seems to stop at 14 bytes:

bash-2.05a$ man apropos >out
bash-2.05a$ crypt mypass encryptedout
bash-2.05a$ ls -la
total 22
drwxrwxrwx2 1303 513 0 Mar 25 08:42 .
drwxrwxrwx   78 Administ 544 20480 Mar 21 11:18 ..
-rw-rw-rw-1 campbe_r Domain U   14 Mar 25 08:42 encryptedout
-rwxrwxrwx1 Administ Domain U  533 Mar 25 08:42 out
bash-2.05a$ cat out | crypt mypass >encryptedout
bash-2.05a$ ls -la
total 22
drwxrwxrwx2 1303 513 0 Mar 25 08:42 .
drwxrwxrwx   78 Administ 544 20480 Mar 21 11:18 ..
-rw-rw-rw-1 campbe_r Domain U   14 Mar 25 08:42 encryptedout
-rwxrwxrwx1 Administ Domain U  533 Mar 25 08:42 out
bash-2.05a$

This is a very suspicious size, since after looking at the crypt code 
that is the size of the retkey array:
(encrypt.c, line 253).
  static char retkey[14];

After looking further, I see that encrypt.c's "crypt" function, which
returns
the ultimate printed out values, returns the retkey array only.

I further notice that crypt does not read any stdin input.

I conclude that this crypt is designed to only print out a key for a given
salt/password.

Am I correct?

If so, what is this utility generally used for?

To Sanjay - it looks like compiling mcrypt would be your best bet, as it 
has a backwards compatibility mode with older crypt(1)s.
http://mcrypt.hellug.gr/

-Richard Campbell

--
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/

1.3.10 gcc/g77 won't install, won't work

[Ryu Myungsunn]

Recently I updated cygwin to 1.3.10 and got "installation incomplete
Check /setup.log.full" message. but no /setup.log.full was found.

Later I discovered that g77(v0.5.25) won't produce .exe files while
producing .o files.
This was the same with gcc(v2.95.3-5).
The same versions of gcc and g77 work nicely on solaris7-sparc
environment.

Still later found that when reinstalling cygwin package gcc always
appears on the update list as an item to be 'Skip'ped, and would show
"installation incomplete..." message when setup has finished.

I saw down the mailing list archive a posting that previous setup
program(v2.125.2.10) would install gcc properly when installing from
local hard disk, after downloading .bz2 files with current setup
program(v2.194.1.15).

But trying haphazrdly to reinstall gcc several times I have already
deleted the previous version of setup program.

I tried also to download the .bz2 file and "bzip2 -c -d ...bz2 | tar xvf
-" on the bash/cygwin environment. But the extracted gcc/g77 won't work
either.

--
¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬
   Ryu Myungsunn, Organic EL Group
  +82-2-526-4498
LG Elite
¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬



--
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: New version of setup.exe broken when running with WINE

[Sylvain Petreolle]

I resent this due to a small problem with the spam
filters. Thanks for your support.
 --- Sylvain Petreolle <[EMAIL PROTECTED]> a écrit :
 Date: Fri, 22 Mar 2002 18:43:19 +0100 (CET)

---
 
 Hi all,
 
 Thanks for the analogy with the toaster :).
 
 Seriously,
 Trying to run cygwin under WINE environment is a
 good
 testcase for both power companies (ie cygwin and
 wine
 :)).
 
 The goal of a bug entry created for wine is to run
 bash/sh in WINE environment. If someone is
 interested
 you can look at 
 http://bugs.codeweavers.com/show_bug.cgi?id=443
 
 Various cygwin programs function at this day
 (mount,ls, and several others).
 
 Thanks by advance,
 Sylvain.
 
 repliers : Please cc me in replies.
 
 

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.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/

Cygwin/DJGPP and memory

[G.Spagnuolo]

Dear all,
I'm browsing the mailing list archive about the limits on memory allocation 
under cygwin, but I've not yet a complete picture.
What is the real limit when I use new[] in a C++ program? The one I set in 
windows2000 register heap_chunk_in_mb?
What are the differences in memory limits between cygwin and DJGPP, besides 
the DJGPP need for DPMI?
Please clarify this point for a "medium level" programmer as me.
I am migrating from DJGPP to cygwin to benefit from a non-dos GCC 
interface, but I need to work with large sparse matrices and my programs 
are greedy for memory!

Thanks a lot for you time.

Regards

Giovanni


--
Dr. Giovanni Spagnuolo, Ph.D.
Assistant Professor
University of Salerno
Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica 
(D.I.I.I.E.)
Via Ponte Don Melillo
84084 Fisciano - Salerno - Italy
phone: +39 089 964258
fax: +39 089 964218
e-mail: [EMAIL PROTECTED]

"You can tell whether a man is clever by his answers.
You can tell whether a man is wise by his questions."
Naguib Mahfouz


--
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: Time sharing and fork

[Bernard Dautrevaux]

> -Original Message-
> From: Stephane Corbe [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2002 4:55 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Time sharing and fork
> 
> 
> Christopher Faylor wrote:
> 
> > That's not guaranteed fork behavior.  If the child never 
> started, that would
> > be a bug.
> 
> As you can see in my previous post, the programm is really simple :
> a loop of printf for the child, a loop of printf for the father.
> There's no place for a bug here ...

And there's no bug either in the result you got :-)

> 
> >  There is no guaranteed behavior with respect to which process is
> > scheduled after a fork on windows or linux.  If you want to 
> serialize things
> > use one of the wait calls.
> 
> I don't want serialized anything, I don't expect that the 
> child or the father
> start at first.

So what is your problem?

> 
> Just I wish that the child share the time (the cpu) with his father.

Except that if the child (or the father) uses all available processor time,
then as long as it runs there is no time to left to the father. What an OS
tries to do here is to give you th emost effective result, that is the
shorter total execution time. It would switch only if it thinks it's
beneficial, i.e. for example if there is contention of the output, that is
if you write on a low speed output device: the chile write some, get
blocked, then the father start, the output drains during startup time (it's
probably handled in interruption), then th efather can output some before
being blocked, then the son restarts, etc. etc. ad nauseam :-)

> 
> On solaris the two processes run like that :
> (A is some printf from father, B is some printf from child)
> 
> ABABABABABABA(end of A)B(end of B)
> 
> On cygwin I have this result :
> 
> AAA(end of A)BBB(end of B)
> 

Both are perfectly fitting the requirements written by your program: you
want some number of As *and* some number of Bs and do not give *any*
constraint regarding th eorder in which you want the As and Bs to get out.
If you *need* some constraints then you have to use synchronization
primitives...

HTH

Bernard


Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
 

--
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: cygwin1.dll bug in ftime

[Wu Yongwei]

Thank you for your suggestions. The points are:

1) Cygwin did very well, but not now;

2) I was not using ftime to get time, but to get timezone information.

3) timezone variable is not usable in Cygwin.

So timezone is now not portable. Cygwin broke some "unportable" code.

Best regards,

Wu Yongwei

"Fleischer, Karsten (K.)" wrote:
> 
> > Also notes the usage of "unspecified". "Unspecified" means
> > the standard does
> > not say anything about the implementation, and, IMHO, the
> > implementors are
> > free to choose the best practices.
> 
> ... or to not implement anything at all.
> 
> > I think it is obviously a
> > good way to
> > follow BSD.
> 
> Possibly.
> The better way for application developers is to follow the Single UNIX > 
>Specification.
> Any application relying on results that are explicitely marked as
> "unspecified" in the SUS standard can be considered non-portable.
> 
> >From the SUSv3 documentation:
> 
> APPLICATION USAGE
> For applications portability, the time() function should be used to
> determine the current time instead of ftime().
> 
> Karsten

--
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: cygwin1.dll bug in ftime

[Fleischer, Karsten (K.)]

> Also notes the usage of "unspecified". "Unspecified" means 
> the standard does
> not say anything about the implementation, and, IMHO, the 
> implementors are
> free to choose the best practices. 

... or to not implement anything at all.

> I think it is obviously a 
> good way to
> follow BSD.

Possibly.
The better way for application developers is to follow the Single UNIX Specification.
Any application relying on results that are explicitely marked as "unspecified" in the 
SUS standard can be considered non-portable.

>From the SUSv3 documentation:

APPLICATION USAGE
For applications portability, the time() function should be used to determine the 
current time instead of ftime().

Karsten

--
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: cygwin1.dll bug in ftime

[Wu Yongwei]

Also notes the usage of "unspecified". "Unspecified" means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose the best practices. I think it is obviously a good way to
follow BSD.

Am I wrong?

Best regards,

Wu Yongwei

--- Original Message from Christopher Faylor ---

  int gettimeofday(struct timeval *tp, void *tzp);

  DESCRIPTION
  The gettimeofday() function obtains the current time, expressed as
  seconds and microseconds since 00:00 Coordinated Universal Time (UTC),
  January 1, 1970, and stores it in the timeval structure pointed to by
  tp.  The resolution of the system clock is unspecified.

  If tzp is not a null pointer, the behaviour is unspecified.


  int ftime(struct timeb *tp);

  DESCRIPTION
  The ftime() function sets the time and millitm members of the timeb
  structure pointed to by tp to contain the seconds and milliseconds
  portions, respectively, of the current time in seconds since 00:00:00
  UTC (Coordinated Universal Time), January 1, 1970.  The contents of the
  timezone and dstflag members of tp after a call to ftime() are
  unspecified.

--
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/

no exec files from gcc and c++

[Jean-Marc Nuzillard]

Dear all,

Today, I have dowloaded and installed setup.exe and all packages from cygwin.
Up to there, everything was OK.
I have written the traditionnal "hello.c" and "hello.cpp".

gcc hello.c -o hello
-> No error but no hello.exe was produced.

gcc -c hello.c
-> got hello.o
gcc hello.o -o hello
-> No error but no hello.exe was produced.

g++ -c hello.cpp
-> g++ not found, took some time to think to try c++

c++ -c hello.cpp
-> got hello.o

c++ hello.o -o hello
-> No error but no hello.exe was produced.


Has someone experienced such a problem ?
How is it possible to get an executable file from C/C++ sources
using Cygwin downloads ?

I used Cygwin a few month ago with total satisfaction...

Sincerely yours,

Dr. Jean-Marc Nuzillard
Laboratoire de Pharmacognosie
UMR 6013
Moulin de la Housse
CPCBAI, Bâtiment 18
BP 1039
51687 REIMS Cedex 2
France

Tel : 33 3 26 91 35 48
Fax :33 3 26 91 35 96
http://www.univ-reims.fr/Labos/UPRESA6013/


--
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: New SETUP.EXE

[Robert Collins]

> -Original Message-
> From: Gaethofs, Danny [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, March 25, 2002 7:48 PM
> To: '[EMAIL PROTECTED]'
> Subject: New SETUP.EXE
> 
> 
> Dear all,
> 
> I have installed the new setup 2.125.2.10 and I am installing 
> new binaries from one of the mirror sites. What I notice is 
> that when I install from the internet setup creates a new 
> directory on my windows file system. In that new directory 
> setup stores the setup.ini and the contrib plus latest 
> directories. The directory name now is called 
> ftp%3a%2fmirrors.rcn.net%2fmirrors ... while the contrib 
> and latest directory were created in the local package 
> directory itselve. 

Something in the above paragraph is fictional. I'm going to assume it's
the setup version. (2.125.x don't use per-mirror directories). 
 
> Is setup now going to install from this new directory or is 
> it not going to find the binaries. 

It's going to install from a random directory. Or it might format your
hard disk. I'm not 100% sure because I haven't looked up the phase of
the moon and that's really important to determine what will happen. 

Seriously, do you think we'd release known-broken software? (Minor
glitches, yes, broken no). Just keep using it *exactly* as you did
before. Ignore what it does for IT's OWN HOUSEKEEPING. The contents of
the 'local dir' you give it are under it's control. Unless it
misbehaves, you can just ignore it.

> What is different between 
> the new approach and the one from a few weeks ago. What can I 
> do to get it working again as before. When I use different 
> mirror sites what result will this have on my installation?

If you use different mirror sites you will get mulitple per-mirror
directories. You can also *merge* the contents of mirror sites on the
fly, to get a view of multiple mirrors/providers. For example I use this
to look at Charles Wilson's pre-test packages from my normal install
window.

Rob

--
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/

New SETUP.EXE

[Gaethofs, Danny]

Dear all,

I have installed the new setup 2.125.2.10 and I am installing new binaries
from one of the mirror sites. What I notice is that when I install from the
internet setup creates a new directory on my windows file system. In that
new directory setup stores the setup.ini and the contrib plus latest
directories. The directory name now is called
ftp%3a%2fmirrors.rcn.net%2fmirrors ... while the contrib and latest
directory were created in the local package directory itselve. 

Is setup now going to install from this new directory or is it not going to
find the binaries. What is different between the new approach and the one
from a few weeks ago. What can I do to get it working again as before. When
I use different mirror sites what result will this have on my installation?

regards,
Danny




--
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: cygwin1.dll bug in ftime

[Wu Yongwei]

This is from the glibc documentation (is glibc meaningless to the Cygwin
project?):

Function: int gettimeofday (struct timeval *tp, struct timezone *tzp)
The gettimeofday function returns the current calendar time as the elapsed
time since the epoch in the struct timeval structure indicated by tp. (see
section 21.2 Elapsed Time for a description of struct timespec). Information
about the time zone is returned in the structure pointed at tzp. If the tzp
argument is a null pointer, time zone information is ignored. The return
value is 0 on success and -1 on failure. The following errno error condition
is defined for this function:
  ENOSYS   The operating system does not support getting time zone
information, and tzp is not a null pointer. The GNU operating system does
not support using struct timezone to represent time zone information; that
is an obsolete feature of 4.3 BSD. Instead, use the facilities described in
21.4.8 Functions and Variables for Time Zones.

I do not understand you quite clearly. And I want to emphasize again that IT
USED TO WORK! Do I need to write patches so that the code is unpatched?

Best regards,

Wu Yongwei

--- Original Message from Christopher Faylor ---

On Mon, Mar 25, 2002 at 10:45:09AM +0800, Wu Yongwei wrote:
>Thank you for your response, and I do see some reasonableness in your
>message. However, I can hardly calm down unless someone can answer:
>
>1) Why should Cygwin break both backward compatibility with older versions
>and compatibility Linux?

Basic meanness.

>2) If ftime does not need to get timezone information, how about
>gettimeofday?

Look again.  I quoted the Single Unix Specification for both gettimeofday
and
ftime.

>I did not read the documentation you quoted (where is it?),
>but no documentation I read about gettimeofday states that it should
>ignore the timezone argument.

http://www.opengroup.org/onlinepubs/7908799/index.html

>My program used to run on both Cygwin and Linux. But now I even do not know
>how to make it behave like before except that I try to find an old version
>of Cygwin and revert to it. Or I could use some ugly macros to define
>_timezone as timezone in some cases and use _timezone: Cygwin recognizes
>_timezone as a valid global variable while Linux recognizes only timezone.
>Anybody enlightens me to show me the right way to go? Or should I abandon
>running international time-related program on Cygwin in a cross-platform
>way?

You could always submit a patch.

cgf


--
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/

[ANNOUNCEMENT] Updated: libtool-devel-20020316-1

[Charles Wilson]

The 'libtool-devel' package has been updated to 20020316-1
It contains a (slightly) hacked version of libtool (from
CVS 16-Mar-2002), installed into /usr/autotool/devel/*.
Most of our earlier changes have been absorbed into the
official libtool CVS.

See the NOTES at the end of this email for some additional information.

--
Chuck Wilson

To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Save it and run setup, answer the questions and pick
up 'libtool-devel' from the 'Devel' category.  You may need to
click the "Full" button if it doesn't show up.

Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need
to find a mirror which has this update.

In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is already
updated.

In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date.

If one of the above doesn't have the latest version of this package
you can either wait for the site to be updated or find another
mirror.

Please  send questions or comments to the Cygwin mailing list at:
[EMAIL PROTECTED] .  If you want to subscribe go to:
http://cygwin.com/lists.html I would appreciate if you would use
this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send
email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

NOTES:

1) libtool (along with autoconf and automake) are really only for
developer use.  If you don't already have a good understanding of
how to use the tools -- and experience using them on a "normal"
unix platform -- then you probably DON'T want to "learn" with this
port.  The combination of
   a) the brain dead DLL format (compared to elf shared libs)
   b) still evolving shared lib support in the binutils/gcc/cygwin
   c) the VERY beta status of libtool-devel
   d) the wacky -stable/-devel/wrapper structure we are forced to
  use
means that cygwin is NOT a good platform to "learn how to use
the autotools".  PLEASE do not ask for tutorials on
automake/autoconf/libtool use on the cygwin mailing list -- you will
either be ignored, or mocked.

2) ALL libtools since version 1.4 (May 2001) have dispensed with
ltconfig.sh.  So, when re-libtoolizing, be sure to delete ltconfig.sh
first.

3) You can't "pick and choose".  If you want to use libtool-devel, you
must also use automake-devel and autoconf-devel.  Likewise, all of the
-stable versions must be used together.

4) libtool-devel installs its info files and man pages into /usr/* as
well as into /usr/autotool/devel/*.  Also, libtool-devel's cygltdl-3.dll
is installed into /usr/bin.  Therefore, applications dynamically linked
to that DLL by libtool-stable and by libtool-devel will both use
libtool-devel's version at runtime.  (Fortunately, this is okay --
libtool-devel's cygltdl-3.dll works fine with apps that expect
libtool-stable's version).


--
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/