Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

[Herbert Stocker]

Hi Peter,

On 11/11/2016 1:15 AM, Peter A. Castro wrote:

On Thu, 10 Nov 2016, Herbert Stocker wrote:


Date: Thu, 10 Nov 2016 23:11:16 +0100
From: Herbert Stocker 
To: cygwin@cygwin.com
Subject: Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

Hi,


Greetings, Herbert,


On 10.11.2016 04:21, Andrey Gursky wrote:

Regarding cygwin time machine. I can't use it, since cygwin
is compiled for MSYS2. And then it is being run under Wine
on GNU/Linux.


So we have two people who have difficulty using time machine.

i did download setup.exe and the binary packages of the last
version with XP support using the "Download but don't Install"
feature of setup.exe . (But i never tested if it's usable).


I don't understand.  What difficulty did you have?  It sounds like you
successfully downloaded (I presume) the 32-bit packages from the Time
Machine?  What was difficult about it?  I really want to know.
If it's just *slow*, well, yes, that's a know problem. :-/


No, i did not have any difficulty with the time machine. Simply
because i did not download from it as i was not aware whether
something like this existed, and time was short.

There was another mail where somebody indicated they had difficulty
with time machine iirc.

If there are no Problems with time machine i see no need to provide
another copy of something.
Unless you'd need a mirror.



Also, did you pull the source packages?


No. Was too much clicking involved with setup.exe and i thought i'd
never compile these old sources anyway.

Now i know more. The great thing called open source software is not
complete if without source. It's just usable then.



best regards,
and thanks for maintaining a history of Cygwin.


Herbert

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

problem installing openTimer in cygwin

[kunal ghosh]

Hi
I am trying to install OpenTimer software on my Windows 7 machine
through cygwin, using standard steps "./configure", "make" , "make
install"

./configure gives me the below errors for which I have googled and
didnt founf anything constructive:

Kunal@Kunal-PC /cygdrive/c/VSD/Tools/openTimer/OpenTimer-1.0.5
$ grep error config.log
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory
conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
g++: error: unrecognized command line option '-qversion'
g++: fatal error: no input files
conftest.cpp:23:28: fatal error: ac_nonexistent.h: No such file or directory
conftest.cpp:23:28: fatal error: ac_nonexistent.h: No such file or directory
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
g++: error: unrecognized command line option '-qversion'
g++: fatal error: no input files
conftest.cpp:60:21: error: expected primary-expression before ')' token
conftest.cpp:60:22: error: expected primary-expression before ')' token
conftest.cpp:60:22: error: expected primary-expression before ')' token
conftest.cpp:60:22: error: expected primary-expression before ')' token
conftest.cpp:26:2: error: 'choke' does not name a type
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:39:3: error:
'omp_lock_t' does not name a type
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:86:28: error:
variable or field 'omp_init_lock' declared void
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:86:28: error:
'omp_lock_t' was not declared in this scope
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:86:40: error:
expected primary-expression before ')' token
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:87:31: error:
variable or field 'omp_destroy_lock' declared void
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:87:31: error:
'omp_lock_t' was not declared in this scope
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:87:43: error:
expected primary-expression before ')' token
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:88:27: error:
variable or field 'omp_set_lock' declared void
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:88:27: error:
'omp_lock_t' was not declared in this scope
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:88:39: error:
expected primary-expression before ')' token
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:89:29: error:
variable or field 'omp_unset_lock' declared void
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:89:29: error:
'omp_lock_t' was not declared in this scope
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:89:41: error:
expected primary-expression before ')' token
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:90:27: error:
'omp_lock_t' was not declared in this scope
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:90:39: error:
expected primary-expression before ')' token
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/include/omp.h:90:41: error:
expected ',' or ';' before 'throw'

Inspite of the above errors, I go ahead with 'make' command and I get
below errors:

src/utilities.cc: In function 'pid_t
google::glog_internal_namespace_::GetTID()':
src/utilities.cc:265:29: error: 'GetCurrentThreadId' was not declared
in this scope
   return GetCurrentThreadId();
 ^
make[2]: *** [Makefile:1197: src/libglog_la-utilities.lo] Error 1
make[2]: Leaving directory
'/cygdrive/c/VSD/Tools/openTimer/OpenTimer-1.0.5/3rd-party/glog-0.3.3'
make[1]: *** [Makefile:2676: all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/c/VSD/Tools/openTimer/OpenTimer-1.0.5'
make: *** [Makefile:846: all] Error 2


The owner of this software has asked me to move to Linux machine.
Before doing that, just wanted to check out if there's a workaround
available?
Any help appreciated?

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

Re: issetugid - not declared when _XOPEN_SOURCE is also defined

[cyg Simple]

On 11/10/2016 4:10 AM, Corinna Vinschen wrote:
> On Nov  9 14:41, cyg Simple wrote:
>> On 11/9/2016 1:13 PM, cyg Simple wrote:
>>> The following program demonstrates the issue.  Should issetugid be
>>> declared with this scenario?
>>>
>>> /*/
>>> #define _XOPEN_SOURCE 1  /* Causes declare warning */
>>> #define __BSD_VISIBLE 1
>>> #include 
>>>
>>> int main(int argc, char ** argv) {
>>> int result;
>>> result = issetugid();
>>> }
>>> //
>>>
>>
>> Because when _XOPEN_SOURCE is 1 _DEFAULT_SOURCE doesn't get set which
>> then #undef __BSD_VISIBLE and and sets it to 0.  See
>> /usr/include/sys/features.h.
>>
>> If I #define _DEFAULT_SOURCE 1 before the #include then the above code
>> works.  However, should it?
> 
> Yes.  You have a bug in your code.  Never (and I mean *never*) use the
> __foo_VISIBLE macros in your code.  Please read the long comment
> preceeding the visibility macro handling in /usr/include/sys/features.h.
> You want to use either _DEFAULT_SOURCE or _BSD_SOURCE (deprecated but
> probably available for another 100 years).
> 
> Also, note the description of the __foo_VISIBLE macros later in the file.
> It introduces the macros as "private" macros.

Yea, I figured that out.  I used __BSD_VISIBLE after looking at the
header for the function.  Thanks for your time; sorry for wasting it.

-- 
cyg Simple

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

Re: XWin server, idle, using lots of CPU time

[Jim Reisert AD1C]

I went to a non-Aero theme in Windows 7 and the CPU usage for XWin is
now 0%.  So that's the solution I'm sticking with.

Jon, you may want to look into this some time.

- Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

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

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Erik Soderquist]

On Thu, Nov 10, 2016 at 7:38 PM, Peter A. Castro wrote:
> Greetings, Erik,
>
> A good magician never reveals how the trick works.  8^)
>
> Sadly I'm not a good magician.
>
> It's not all that complicated, if you think about it.  Each time a new
> setup.ini is generated only a hand full of packages was actually updated, so
> really, day-to-day, there's not all that much change.
>
> I keep a delta database and each time I grab a new setup.ini I compare all
> of the packages listed to my existing database.  Anything new, I pull down
> and add to the archive.  Anything already present I don't re-pull.  Think of
> it as de-duplication on a package level (though I do this for more than just
> setup.ini, but that's a separate trick).
>
> It's only if you decide you want a complete copy of all packages for any
> given circa that the amount of data instantiating is alot.
>
> Then, from the setup.ini, I create a new circa directory and, really, the
> smoke-and-mirrors of the trick is that it's all symlinks to the real package
> storage, of which I have exactly one copy.  Hence, 500Gb instead of 535Tb.
>
> So, um, "Ta-da"! :-)
>
> Oh, this is all automated, btw.  I hardly touch it except to clean out old
> logs and do backups from time to time.
>
> Sorry, it wasn't all that good a trick, was it.

The automation details are primarily what I'm after, though it could
have been something like ZFS with deduplication turned on

I'm wondering if I could apply your automations to a few background
projects I'm working on

Would also be interesting to see how cleanly the existing setup could
be mirrored knowing the details of the automation... rsync would
happily copy the symlinks, and once created, a Time Machine mirror
*should* be able to "stay in sync" with the original time machine by
pulling from the cygwin main sources in the same manner.



-- Erik

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

Re: [RFU] ruby-puppet-lint-2.0.2-1

[David Stacey]

On 11/11/16 00:48, David Stacey wrote:
A tool for checking (and fixing) Puppet manifests. Found in most Linux 
distros [1], including Fedora.


BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release 

wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \

${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1-src.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/ruby-puppet-lint-doc-2.0.2-1.tar.xz 
\

${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/setup.hint \
${BASEURL}/ruby-puppet-lint/setup.hint


Dave.

[1] - https://pkgs.org/search/?query=puppet-lint=smart



Subject: s/RFU/ITP/ Sorry - it's late here and my brain is already asleep...

Dave.

[RFU] ruby-puppet-lint-2.0.2-1

[David Stacey]

A tool for checking (and fixing) Puppet manifests. Found in most Linux 
distros [1], including Fedora.


BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/noarch/release
wget --no-check-certificate --no-host-directories --force-directories 
--cut-dirs=5 \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1-src.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-2.0.2-1.tar.xz \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/ruby-puppet-lint-doc-2.0.2-1.tar.xz
 \
${BASEURL}/ruby-puppet-lint/ruby-puppet-lint-doc/setup.hint \
${BASEURL}/ruby-puppet-lint/setup.hint


Dave.

[1] - https://pkgs.org/search/?query=puppet-lint=smart

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Peter A. Castro]

On Thu, 10 Nov 2016, Erik Soderquist wrote:


Date: Thu, 10 Nov 2016 17:16:53 -0500
From: Erik Soderquist 
To: cygwin@cygwin.com
Subject: Re: Complaining after fair notice of dropping XP support. Was: Not
very nice at all.


Greetings, Erik,


On Thu, Nov 10, 2016 at 2:19 PM, Peter A. Castro wrote:

And for those who think keeping a private mirror is trivial, let me give you
some stats.  A full snapshot of Cygwin, 32-bit + 64-bit (+noarch) + source
packages (Current and Previous) is about 137Gb.  Don't believe me? Your
setup.ini has a size (and a hash) for every package.  Add them up yourself.
Now consider that I have about 4000 snapshots (and counting!) of Cygwin.
Oh!  Quick quiz:
  What's 137Gb * 4000?
  Answer: 535Tb.
Now, do you really think I have that amount of storage?  Of course not. The
Time Machine isn't organized like that (don't be silly).  It's currently
about 500Gb (which is quite a savings, if you think about it :-)


I would dearly love to know more about how you did this specific piece...


A good magician never reveals how the trick works.  8^)

Sadly I'm not a good magician.

It's not all that complicated, if you think about it.  Each time a new 
setup.ini is generated only a hand full of packages was actually updated, 
so really, day-to-day, there's not all that much change.


I keep a delta database and each time I grab a new setup.ini I compare all 
of the packages listed to my existing database.  Anything new, I pull down 
and add to the archive.  Anything already present I don't re-pull.  Think 
of it as de-duplication on a package level (though I do this for more 
than just setup.ini, but that's a separate trick).


It's only if you decide you want a complete copy of all packages for any
given circa that the amount of data instantiating is alot.

Then, from the setup.ini, I create a new circa directory and, really, the 
smoke-and-mirrors of the trick is that it's all symlinks to the real 
package storage, of which I have exactly one copy.  Hence, 500Gb 
instead of 535Tb.


So, um, "Ta-da"! :-)

Oh, this is all automated, btw.  I hardly touch it except to clean out 
old logs and do backups from time to time.


Sorry, it wasn't all that good a trick, was it.


-- Erik


--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

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

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

[Peter A. Castro]

On Thu, 10 Nov 2016, Herbert Stocker wrote:


Date: Thu, 10 Nov 2016 23:11:16 +0100
From: Herbert Stocker 
To: cygwin@cygwin.com
Subject: Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

Hi,


Greetings, Herbert,


On 10.11.2016 04:21, Andrey Gursky wrote:

Regarding cygwin time machine. I can't use it, since cygwin
is compiled for MSYS2. And then it is being run under Wine
on GNU/Linux.


So we have two people who have difficulty using time machine.

i did download setup.exe and the binary packages of the last
version with XP support using the "Download but don't Install"
feature of setup.exe . (But i never tested if it's usable).


I don't understand.  What difficulty did you have?  It sounds like you 
successfully downloaded (I presume) the 32-bit packages from the Time 
Machine?  What was difficult about it?  I really want to know.

If it's just *slow*, well, yes, that's a know problem. :-/

Also, did you pull the source packages?  I recall that one of the 
requirements is that you provide the source packages along with the binary 
packages.

(I expect Corinna will correct me if I'm wrong about that).


Now i would like to provide them on an HTTP Server.


If you do, please let me know so I can add reference to it in the Time 
Machine webpage.



i think setup.exe can use such a repository.


If it helps, I have been collecting versions of setup as well.  I just 
don't have an exposed list for that (yet).



Right now i'm not sure if i have to ask for permission to do
so given it is open source.
Am i allowed to do this?


I think you have to say "Pretty Please with Sugar on Top!"  :-D


best regards,
Herbert Stocker


--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

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

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Erik Soderquist]

On Thu, Nov 10, 2016 at 2:19 PM, Peter A. Castro wrote:
> And for those who think keeping a private mirror is trivial, let me give you
> some stats.  A full snapshot of Cygwin, 32-bit + 64-bit (+noarch) + source
> packages (Current and Previous) is about 137Gb.  Don't believe me? Your
> setup.ini has a size (and a hash) for every package.  Add them up yourself.
> Now consider that I have about 4000 snapshots (and counting!) of Cygwin.
> Oh!  Quick quiz:
>   What's 137Gb * 4000?
>   Answer: 535Tb.
> Now, do you really think I have that amount of storage?  Of course not. The
> Time Machine isn't organized like that (don't be silly).  It's currently
> about 500Gb (which is quite a savings, if you think about it :-)


I would dearly love to know more about how you did this specific piece...

-- Erik

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

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

[Herbert Stocker]

Hi,

On 10.11.2016 04:21, Andrey Gursky wrote:
> Regarding cygwin time machine. I can't use it, since cygwin
> is compiled for MSYS2. And then it is being run under Wine
> on GNU/Linux.

So we have two people who have difficulty using time machine.

i did download setup.exe and the binary packages of the last
version with XP support using the "Download but don't Install"
feature of setup.exe . (But i never tested if it's usable).

Now i would like to provide them on an HTTP Server.
i think setup.exe can use such a repository.

Right now i'm not sure if i have to ask for permission to do
so given it is open source.
Am i allowed to do this?


best regards,

Herbert Stocker


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

Re: XWin server, idle, using lots of CPU time

[Jim Reisert AD1C]

On Thu, Nov 10, 2016 at 1:56 PM, Brian Inglis wrote:

> Assume you're using W7 Pro 64 as you're using Cygwin 64.
> How big, fast, and full is your disk?

512GB SSD, tons of free space.

> How much memory is installed/used/free in Resource Monitor?

Laptop has 16GB installed.

> Have you a lot of services started that you don't use?

None that I did not have with the older laptop, which also ran Windows
7 (Enterprise instead of Pro).  It's just the Xwin process that's
taking constant CPU time, none of the others are (other than System
Idle and a blip or two from other processes).

> Are you seeing many pageins/pageouts?

I turned on every column in Task Manager.  Looking at just XWin.exe,
*none* of the values in any column are changing while it's chewing up
CPU time.

> How much paging space is allocated?

pagefile.sys is 4 GB:

11/10/2016  11:00   4,294,967,296  pagefile.sys

> Try allocating 2*physical memory size as paging space.
> If that helps, you may want to add more or faster memory if
> you only have 4GB installed, or most of it is used, with
> low free.

I changed to system managed size, it went up to 16GB. Rebooted, but it
made no difference.

- Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

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

Re: XWin server, idle, using lots of CPU time

[Jim Reisert AD1C]

On Thu, Nov 10, 2016 at 9:14 AM, Jon Turney wrote:

> Possibly the problem is caused by the internal WM or clipboard threads, so
> you might try with -noclipboard or in windowed mode, and see if you see the
> same load.
>
> If that's the case, maybe running with -logverbose 3 would generate a log
> which gives more information about what unnecessary work is being done.

Thanks, Jon.

-noclipboard did not make a difference.

Running xinit instead of startxwin consumes 0% CPU time.  The X
desktop has a single xterm which I could play with.

I attached the log output from startxwin with -logverbose 3.  I opened
and closed one xterm before existing xdg.  Clipboard is disabled.

-- 
Jim Reisert AD1C, , http://www.ad1c.us


XWin.0.log
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: XWin server, idle, using lots of CPU time

[Brian Inglis]

On 2016-11-09 19:05, Jim Reisert AD1C wrote:

I received a new laptop at work (Windows 7 Pro) and installed Cygwin
from scratch, including the Xorg server and xdg.

Unlike my old laptop, XWIN seems to be using about 10% CPU *all the
time* (measured with Task Manager), even when there are no clients
connected to it.  My ~/ home directory is the same, so the X server is
being set up the same way as before, as far as I can tell.

The processor is an I7-6600U with two cores, two threads/core.  10%
seems rather high, given that 25% would be one fully-utilitized
thread.  I even updated the Intel video driver to the latest Dell
version, dated November 1, 2016.  No change in behavior.

I've attached cygcheck.out and my X server log, but can anyone advise
how to track down the source of the problem? There does seem to be a
large number of winClipboardFlushXEvents failures in the Xwin log
file, but those are also in the log file on the old laptop.

This is how I'm starting the X server:

C:\Cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec
/usr/bin/startxwin"

I am starting the X server with this line in  .xserverrc

exec /usr/bin/XWin -notrayicon "$@"


Assume you're using W7 Pro 64 as you're using Cygwin 64.
How big, fast, and full is your disk?
How much memory is installed/used/free in Resource Monitor?
Have you a lot of services started that you don't use?
Are you seeing many pageins/pageouts?
How much paging space is allocated?
Try allocating 2*physical memory size as paging space.
If that helps, you may want to add more or faster memory if
you only have 4GB installed, or most of it is used, with
low free.
Some people have improved performance by increasing the min
free memory setting, to keep more instantly available for use.
Search google or stackoverflow for W7 Pro min free memory advice.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: No gawk-doc package, gawk source autoconf fails

[Brian Inglis]

On 2016-11-10 02:24, Corinna Vinschen wrote:

On Nov  9 18:29, Yaakov Selkowitz wrote:

On 2016-11-09 18:02, Brian Inglis wrote:

Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc.
Checked for gawk doc as a package - no gawk-doc or anything like
it.
Downloaded gawk package source and tried to configure enough to
build doc.
Seems to be problem with autoconf autopoint gettext package
version - something run by autoreconf seems to be detecting
gettext 0.19.8-1 as 0.19.8.1 instead of 0.19.8 which causes
autopoint to fail:



This is already fixed in cygport git master.


Thanks for that - fixing a gettext nano-release with an extra .#
autopoint dislikes.


Do I have to create a fixed gawk package at one point?  Perhaps
after the next cygport release?


It would be a kindness if the maintainer built the docs and
provided a gawk-doc package like other distros with the next
gawk release.
It would be nice if it included the examples, manuals, and
cards in man, info, html, ps, and pdf formats, unlike most
distros.
Can never have too many doc formats, depending on what you're
doing, what you're looking for, and what you have available.
Regular man and info are good for grepping, html single page
is good for phones and ereaders, multi page and PDF are better
on tablets and desktops.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Peter A. Castro]

On Thu, 10 Nov 2016, Brian Inglis wrote:


Date: Thu, 10 Nov 2016 02:45:32 -0700
From: Brian Inglis
Subject: Re: Complaining after fair notice of dropping XP support. Was: Not
very nice at all.

On 2016-11-10 00:24, Fergus wrote:

1. Use the following version of setup*.exe:
32-bit:

ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-x86-2.874.exe

2. Run setup*.exe with the -X option, using the following
mirror:
32-bit:
ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223

Q1  Any ideas of what might be de-railing this simple operation?


See notice on throttling Cygwin Time Machine because of abuse:
http://www.fruitbat.org/Cygwin/timemachine.html
advises using only setup on as few required packages as possible
at a time, until abuse stops.


Greetings, All,
  (Time Machine owner/operator here! :-)


Q2  [... virtual(?);] Could one instead use wget on
ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223?


Brian is correct about robots and LIST, but what he (anyone) doesn't know 
is why.  I generally keep to myself and don't post non-Cygwin specific 
things to this list so I've never really explain why I do what I do. 
And, no, it's not "BWJM" (https://cygwin.com/acronyms/#BWAM) either. :)



Wget honours robots.txt, and LIST has been disabled for Cygwin
Time Machine directories, so you can not even see the
directories, and no FTP download requests other than GET will
work.

https://www.google.ca/search?q=lack+of+planning+on+your+part+does+not+constitute+an+emergency=imghp=isch=u=univ=X

Please remember that both the Cygwin and Time Machine
projects are volunteer efforts with few resources.
Each must manage their projects as best they can fit effort
into their time, and may withdraw their efforts and
facilities at any time.


While it is true I have limited resources, it's unlikely I'll ever 
withdraw the Time Machine.  I've been doing this for over 10 years and 
will continue so until Windows finally becomes Skynet.  :-)  At that point 
I figure we'll all be dead or used as living batteries, so it won't 
matter.



Following the mailing lists/groups and participation earlier
could perhaps have delayed the final implementation to allow
more time for people to plan and execute final downloads.

Complaining after advance notice was given publicly and making
could/should have suggestions after the fact is pointless, and
could demotivate the volunteers to drop the projects, make
access private, or charge for it.

Fairly recently, the owner of gmane.org, that many of us had
used to browse and post to mailing lists via the web, shut
down his web site, although he kept his mail-news gateway up.
How many people over the years expressed appreciation for his
free service to the community? Or were gracious when letting
him know his site had a problem. And thanked him when it was
fixed. Not enough probably!

If you, a bunch of Cygwin XP dependents banded together, or
your company  have the space, bandwidth, server(s), money to
provide a public mirror of the final Cygwin XP release from
the Time Machine, you could contact the owner and make a
proposal to offload his site, or upgrade his facilities and
help run them.


Ugh.  Please don't.  I already have plans in motion to move the Time 
Machine to a service with greater network bandwidth and I'm really not 
willing to consider other options.  In the process of that I'll be 
restricting the existing site even further to not-so-subtly prod existing 
users over to the new system, when it is live.  People wanting to make 
their own special, private copy really should wait, please, pretty please.


And for those who think keeping a private mirror is trivial, let me give 
you some stats.  A full snapshot of Cygwin, 32-bit + 64-bit (+noarch) + 
source packages (Current and Previous) is about 137Gb.  Don't believe me? 
Your setup.ini has a size (and a hash) for every package.  Add them up 
yourself.  Now consider that I have about 4000 snapshots (and counting!) 
of Cygwin.

Oh!  Quick quiz:
  What's 137Gb * 4000?
  Answer: 535Tb.
Now, do you really think I have that amount of storage?  Of course not. 
The Time Machine isn't organized like that (don't be silly).  It's 
currently about 500Gb (which is quite a savings, if you think about it 
:-).  It is for this reason I won't let webcrawlers on the site.  They 
would see each "virtual" slice as wholely separate and attempt to pull it 
all.  That is what was happening before I disabled FTP LIST.



Or your company could ask MS and Redhat for XP and Cygwin XP
support quotes if it has the money ;^>


I see what you did there.  Ha Ha. :)


There's an opportunity for some of you XP folks to make
money off the others by providing dedicated repos of
outdated software with support ;^>

If you are working for a company that decided to build products
for XP dependent on Cygwin, maybe it's time to tell them that
Cygwin has reached EOL on the EOL XP.
If you are supporting Cygwin based products on XP, maybe it's

Re: XWin server, idle, using lots of CPU time

[Jon Turney]

On 10/11/2016 02:05, Jim Reisert AD1C wrote:

I received a new laptop at work (Windows 7 Pro) and installed Cygwin
from scratch, including the Xorg server and xdg.

Unlike my old laptop, XWIN seems to be using about 10% CPU *all the
time* (measured with Task Manager), even when there are no clients
connected to it.  My ~/ home directory is the same, so the X server is
being set up the same way as before, as far as I can tell.

The processor is an I7-6600U with two cores, two threads/core.  10%
seems rather high, given that 25% would be one fully-utilitized
thread.  I even updated the Intel video driver to the latest Dell
version, dated November 1, 2016.  No change in behavior.

I've attached cygcheck.out and my X server log, but can anyone advise
how to track down the source of the problem? There does seem to be a
large number of winClipboardFlushXEvents failures in the Xwin log
file, but those are also in the log file on the old laptop.

Thanks for reporting this problem.

Yes, this doesn't seem right, or expected.

Possibly the problem is caused by the internal WM or clipboard threads, 
so you might try with -noclipboard or in windowed mode, and see if you 
see the same load.


If that's the case, maybe running with -logverbose 3 would generate a 
log which gives more information about what unnecessary work is being done.



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

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

[Andrey Gursky]

> https://cygwin.com/ml/cygwin-announce/2015-08/msg00049.html

Thanks,
Andrey

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

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine],

[Corinna Vinschen]

On Nov 10 15:19, Andrey Gursky wrote:
> > On Nov 10 04:21, Andrey Gursky wrote:
> > > On 11/9/2016 7:59 AM, Andrey Gursky wrote:
> > > > > P.S. Was it not too early to remove WinXP support? Though it is
> > > > > officially not supported anymore, there are still PCs running WinXP
> > > > > [...]
> > > > 
> > > > This has been answered.  The problem with supporting XP into infinitude
> > > > is that every application would need to agree to do the same.
> > > > [...]
> > > [...]
> > Ending XP support was announced last year and only a year later we
> > actually dropped it.  So we don't support Windows XP anymore, but we
> > *would* support Wine.  However, the problem here is not on the Cygwin
> > side.
> > 
> > It seems Cygwin under Wine was not tested outside of XP compatibility
> > mode, or Wine doesn't support certain post-XP functions albeit claiming
> > Vista caompatibility.  Cygwin doesn't require any functionality which
> > isn't available in Vista.
> 
> Corinna,
> 
> sorry, I missed that early announce. Is there any link?

https://cygwin.com/ml/cygwin-announce/2015-08/msg00049.html


Corinna

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


signature.asc
Description: PGP signature

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine],

[Andrey Gursky]

> On Nov 10 04:21, Andrey Gursky wrote:
> > Hi cyg Simple,
> > 
> > On 11/9/2016 7:59 AM, Andrey Gursky wrote:
> > > > 
> > > > P.S. Was it not too early to remove WinXP support? Though it is
> > > > officially not supported anymore, there are still PCs running WinXP
> > > > (and Wine). Also there are still systems, I've heard, using some
> > > > embedded Windows, that shares the same code with WinXP, thus making it
> > > > not yet truly obsolete. Additionally a lot of work has been done by
> > > > Cygwin contributors to support this OS and I believe the most of bugs
> > > > have been workarounded, while due to stopped development it is not
> > > > likely one has to spend time solving new problems. So was it really
> > > > worth to drop the hardly crafted code? Are there already some
> > > > worthwhile advantages? Why wasn't it possible to switch Cygwin WinXP
> > > > support to just "not officially supported"? (kindly asking)
> > > 
> > > This has been answered.  The problem with supporting XP into infinitude
> > > is that every application would need to agree to do the same.
> > > Improvements to the OS API would not be able to be used so there are
> > > trade-offs for the continued support of an OS that is no longer
> > > supported.  The code becomes unwieldy to maintain because a change needs
> > > to be tested on other systems.  Security maintenance becomes impossible
> > > because the OS vendor no longer supports the older OS.  There is the
> > > cygwin time machine, USE IT if you need old software for old OS.
> > 
> > Thanks for your reply (however I haven't received it, because you
> > likely didn't click on "reply all"?).
> > 
> > Do you refer to the recent message [1]?
> > 
> > Regarding cygwin time machine. I can't use it, since cygwin is compiled
> > for MSYS2. And then it is being run under Wine on GNU/Linux. While
> > WinXP is still not dead, Wine is definitively not an old OS. It's just
> > an active project doing WinAPI implementation from scratch according to
> > documentation. Thus I hope Cygwin developers could talk directly to
> > Wine ones to find the minimum needed changes in both projects.
> 
> Ending XP support was announced last year and only a year later we
> actually dropped it.  So we don't support Windows XP anymore, but we
> *would* support Wine.  However, the problem here is not on the Cygwin
> side.
> 
> It seems Cygwin under Wine was not tested outside of XP compatibility
> mode, or Wine doesn't support certain post-XP functions albeit claiming
> Vista caompatibility.  Cygwin doesn't require any functionality which
> isn't available in Vista.

Corinna,

sorry, I missed that early announce. Is there any link? Since I'm aware
only of almost "last minute" MSYS2 mail [1] referring to your recent
announce.

If I understood you correctly, previously discussed changes in Cygwin
itself are not considered anymore and from now Wine is really left
alone with this issue?

Regards,
Andrey

[1] Announcement: msys2-runtime 2.5.1 -- last version to support XP/2003
30. June 2016
https://sourceforge.net/p/msys2/mailman/message/35191999/

P.S. I didn't receive your message also. Does Cygwin mailing list
program strips my E-Mail address (though I see it in the archive)?
(And it even can't guess a possibly follow-up :( )

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

Re: isn't or hasn't 32 bit support going or gone away?

[Corinna Vinschen]

On Nov 10 02:55, Brian Inglis wrote:
> On 2016-11-10 02:16, Corinna Vinschen wrote:
> > On Nov  9 13:53, L. A. Walsh wrote:
> > > I thought I remember an announcement about 32-bit support
> > > going away in cygwin and that cygwin would only be built for
> > > 64-bit?  Am I imagining this or was this reversed?
> > 
> > We only (kind of) joked about it.
> 
> MS will release that fix in an upcoming Anniversary Update, if
> the 32 bit MS Office Education and Enterprise licence revenue
> ever dwindles, and Insider devs' systems tell MS they don't do
> 32 bit builds.

Good thing MS doesn't collect user data...

> Cygwin won't have to worry about it, as they won't have a WoW
> to work on any more ;^>

I heard there are still lots of real 32 bit Vista/W7/W8.1/W10 systems
running, but I wonder what's the point.  I won't actively pursue
dropping 32 bit, albeit getting rid of 32 bit would be a bit of a relief
in terms of ugly `#ifdef' handling in the code.


Corinna

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


signature.asc
Description: PGP signature

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Corinna Vinschen]

On Nov 10 02:45, Brian Inglis wrote:
> On 2016-11-10 00:24, Fergus wrote:
> > > > 1. Use the following version of setup*.exe:
> > > > 32-bit:
> > ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-x86-2.874.exe
> > > > 2. Run setup*.exe with the -X option, using the following
> > > > mirror:
> > > > 32-bit:
> > > > ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223
> > Q1  Any ideas of what might be de-railing this simple operation?
> 
> See notice on throttling Cygwin Time Machine because of abuse:
> http://www.fruitbat.org/Cygwin/timemachine.html
> advises using only setup on as few required packages as possible
> at a time, until abuse stops.
> 
> > Q2  [... virtual(?);] Could one instead use wget on
> > ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223?
> 
> Wget honours robots.txt, and LIST has been disabled for Cygwin
> Time Machine directories, so you can not even see the
> directories, and no FTP download requests other than GET will
> work.
> 
> https://www.google.ca/search?q=lack+of+planning+on+your+part+does+not+constitute+an+emergency=imghp=isch=u=univ=X
> 
> Please remember that both the Cygwin and Time Machine
> projects are volunteer efforts with few resources.
> Each must manage their projects as best they can fit effort
> into their time, and may withdraw their efforts and
> facilities at any time.
> 
> Following the mailing lists/groups and participation earlier
> could perhaps have delayed the final implementation to allow
> more time for people to plan and execute final downloads.
> 
> Complaining after advance notice was given publicly and making
> could/should have suggestions after the fact is pointless, and
> could demotivate the volunteers to drop the projects, make
> access private, or charge for it.
> 
> Fairly recently, the owner of gmane.org, that many of us had
> used to browse and post to mailing lists via the web, shut
> down his web site, although he kept his mail-news gateway up.
> How many people over the years expressed appreciation for his
> free service to the community? Or were gracious when letting
> him know his site had a problem. And thanked him when it was
> fixed. Not enough probably!
> 
> If you, a bunch of Cygwin XP dependents banded together, or
> your company  have the space, bandwidth, server(s), money to
> provide a public mirror of the final Cygwin XP release from
> the Time Machine, you could contact the owner and make a
> proposal to offload his site, or upgrade his facilities and
> help run them.
> Or your company could ask MS and Redhat for XP and Cygwin XP
> support quotes if it has the money ;^>

https://cygwin.com/ml/cygwin/2016-11/msg00068.html

Red Hat does not provide Cygwin Support any longer since we hadn't
enough support customers to get the revenue supporting the business
model.  Apparently too many people were happy with upstream as is.

As Stephen wrote, Cygwin is a volunteer driven project now.  One of the
reasons we relaxed the license was to make the project easier accessible
and maybe get more volunteers fixing bugs and stuff.  But then again,
Cygwin isn't Linux so it's not as sexy by far.

> There's an opportunity for some of you XP folks to make
> money off the others by providing dedicated repos of
> outdated software with support ;^>
> 
> If you are working for a company that decided to build products
> for XP dependent on Cygwin, maybe it's time to tell them that
> Cygwin has reached EOL on the EOL XP.
> If you are supporting Cygwin based products on XP, maybe it's
> time to tell your customers you can't any longer, as both are
> unsupported.
> 
> You can download source and binary packages that you need that
> predate 2.6 from the Cygwin mirrors, and include all the build
> dependencies, starting with cygport.
> That will enable you to use setup to download from the Time
> Machine only those packages recently updated on Cygwin
> mirrors to use 2.6.
> You could run setup unattended installing packages one at a
> time, in a loop driven by the packages needed from
> installed.db, to honour the site owner's request.
> You will then be in a position to monitor upstream sources,
> so you can download new upstream patches and releases as
> they become available, so you have and can apply them when
> needed, to rebuild the updated packages.
> 
> You could also try upgrading to W10 and working with single
> user Ubuntu under WSL ;^>

Interesting point, but where's the fun in that from a dev perspective :)


Corinna

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


signature.asc
Description: PGP signature

Re: isn't or hasn't 32 bit support going or gone away?

[Brian Inglis]

On 2016-11-10 02:16, Corinna Vinschen wrote:

On Nov  9 13:53, L. A. Walsh wrote:

I thought I remember an announcement about 32-bit support
going away in cygwin and that cygwin would only be built for
64-bit?  Am I imagining this or was this reversed?


We only (kind of) joked about it.


MS will release that fix in an upcoming Anniversary Update, if
the 32 bit MS Office Education and Enterprise licence revenue
ever dwindles, and Insider devs' systems tell MS they don't do
32 bit builds.

Cygwin won't have to worry about it, as they won't have a WoW
to work on any more ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Complaining after fair notice of dropping XP support. Was: Not very nice at all.

[Brian Inglis]

On 2016-11-10 00:24, Fergus wrote:

1. Use the following version of setup*.exe:
32-bit:

ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-x86-2.874.exe

2. Run setup*.exe with the -X option, using the following
mirror:
32-bit:
ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223

Q1  Any ideas of what might be de-railing this simple operation?


See notice on throttling Cygwin Time Machine because of abuse:
http://www.fruitbat.org/Cygwin/timemachine.html
advises using only setup on as few required packages as possible
at a time, until abuse stops.


Q2  [... virtual(?);] Could one instead use wget on
ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223?


Wget honours robots.txt, and LIST has been disabled for Cygwin
Time Machine directories, so you can not even see the
directories, and no FTP download requests other than GET will
work.

https://www.google.ca/search?q=lack+of+planning+on+your+part+does+not+constitute+an+emergency=imghp=isch=u=univ=X

Please remember that both the Cygwin and Time Machine
projects are volunteer efforts with few resources.
Each must manage their projects as best they can fit effort
into their time, and may withdraw their efforts and
facilities at any time.

Following the mailing lists/groups and participation earlier
could perhaps have delayed the final implementation to allow
more time for people to plan and execute final downloads.

Complaining after advance notice was given publicly and making
could/should have suggestions after the fact is pointless, and
could demotivate the volunteers to drop the projects, make
access private, or charge for it.

Fairly recently, the owner of gmane.org, that many of us had
used to browse and post to mailing lists via the web, shut
down his web site, although he kept his mail-news gateway up.
How many people over the years expressed appreciation for his
free service to the community? Or were gracious when letting
him know his site had a problem. And thanked him when it was
fixed. Not enough probably!

If you, a bunch of Cygwin XP dependents banded together, or
your company  have the space, bandwidth, server(s), money to
provide a public mirror of the final Cygwin XP release from
the Time Machine, you could contact the owner and make a
proposal to offload his site, or upgrade his facilities and
help run them.
Or your company could ask MS and Redhat for XP and Cygwin XP
support quotes if it has the money ;^>

There's an opportunity for some of you XP folks to make
money off the others by providing dedicated repos of
outdated software with support ;^>

If you are working for a company that decided to build products
for XP dependent on Cygwin, maybe it's time to tell them that
Cygwin has reached EOL on the EOL XP.
If you are supporting Cygwin based products on XP, maybe it's
time to tell your customers you can't any longer, as both are
unsupported.

You can download source and binary packages that you need that
predate 2.6 from the Cygwin mirrors, and include all the build
dependencies, starting with cygport.
That will enable you to use setup to download from the Time
Machine only those packages recently updated on Cygwin
mirrors to use 2.6.
You could run setup unattended installing packages one at a
time, in a loop driven by the packages needed from
installed.db, to honour the site owner's request.
You will then be in a position to monitor upstream sources,
so you can download new upstream patches and releases as
they become available, so you have and can apply them when
needed, to rebuild the updated packages.

You could also try upgrading to W10 and working with single
user Ubuntu under WSL ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: No gawk-doc package, gawk source autoconf fails

[Corinna Vinschen]

Hey Yaakov,

On Nov  9 18:29, Yaakov Selkowitz wrote:
> On 2016-11-09 18:02, Brian Inglis wrote:
> > Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc.
> > Checked for gawk doc as a package - no gawk-doc or anything like it.
> > Downloaded gawk package source and tried to configure enough to build doc.
> > Seems to be problem with autoconf autopoint gettext package version
> > - something run by autoreconf seems to be detecting gettext 0.19.8-1 as
> > 0.19.8.1 instead of 0.19.8 which causes autopoint to fail:
> 
> This is already fixed in cygport git master.

Do I have to create a fixed gawk package at one point?  Perhaps after
the next cygport release?


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: isn't or hasn't 32 bit support going or gone away?

[Corinna Vinschen]

On Nov  9 13:53, L. A. Walsh wrote:
> I thought I remember an announcement about 32-bit support
> going away in cygwin and that cygwin would only be built for
> 64-bit?  Am I imagining this or was this reversed?

We only (kind of) joked about it.


Corinna

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


signature.asc
Description: PGP signature

Re: issetugid - not declared when _XOPEN_SOURCE is also defined

[Corinna Vinschen]

On Nov  9 14:41, cyg Simple wrote:
> On 11/9/2016 1:13 PM, cyg Simple wrote:
> > The following program demonstrates the issue.  Should issetugid be
> > declared with this scenario?
> > 
> > /*/
> > #define _XOPEN_SOURCE 1  /* Causes declare warning */
> > #define __BSD_VISIBLE 1
> > #include 
> > 
> > int main(int argc, char ** argv) {
> > int result;
> > result = issetugid();
> > }
> > //
> > 
> 
> Because when _XOPEN_SOURCE is 1 _DEFAULT_SOURCE doesn't get set which
> then #undef __BSD_VISIBLE and and sets it to 0.  See
> /usr/include/sys/features.h.
> 
> If I #define _DEFAULT_SOURCE 1 before the #include then the above code
> works.  However, should it?

Yes.  You have a bug in your code.  Never (and I mean *never*) use the
__foo_VISIBLE macros in your code.  Please read the long comment
preceeding the visibility macro handling in /usr/include/sys/features.h.
You want to use either _DEFAULT_SOURCE or _BSD_SOURCE (deprecated but
probably available for another 100 years).

Also, note the description of the __foo_VISIBLE macros later in the file.
It introduces the macros as "private" macros.


HTH,
Corinna

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


signature.asc
Description: PGP signature

Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]

[Corinna Vinschen]

On Nov 10 04:21, Andrey Gursky wrote:
> Hi cyg Simple,
> 
> On 11/9/2016 7:59 AM, Andrey Gursky wrote:
> >> 
> >> P.S. Was it not too early to remove WinXP support? Though it is
> >> officially not supported anymore, there are still PCs running WinXP
> >> (and Wine). Also there are still systems, I've heard, using some
> >> embedded Windows, that shares the same code with WinXP, thus making it
> >> not yet truly obsolete. Additionally a lot of work has been done by
> >> Cygwin contributors to support this OS and I believe the most of bugs
> >> have been workarounded, while due to stopped development it is not
> >> likely one has to spend time solving new problems. So was it really
> >> worth to drop the hardly crafted code? Are there already some
> >> worthwhile advantages? Why wasn't it possible to switch Cygwin WinXP
> >> support to just "not officially supported"? (kindly asking)
> > 
> > This has been answered.  The problem with supporting XP into infinitude
> > is that every application would need to agree to do the same.
> > Improvements to the OS API would not be able to be used so there are
> > trade-offs for the continued support of an OS that is no longer
> > supported.  The code becomes unwieldy to maintain because a change needs
> > to be tested on other systems.  Security maintenance becomes impossible
> > because the OS vendor no longer supports the older OS.  There is the
> > cygwin time machine, USE IT if you need old software for old OS.
> 
> Thanks for your reply (however I haven't received it, because you
> likely didn't click on "reply all"?).
> 
> Do you refer to the recent message [1]?
> 
> Regarding cygwin time machine. I can't use it, since cygwin is compiled
> for MSYS2. And then it is being run under Wine on GNU/Linux. While
> WinXP is still not dead, Wine is definitively not an old OS. It's just
> an active project doing WinAPI implementation from scratch according to
> documentation. Thus I hope Cygwin developers could talk directly to
> Wine ones to find the minimum needed changes in both projects.

Ending XP support was announced last year and only a year later we
actually dropped it.  So we don't support Windows XP anymore, but we
*would* support Wine.  However, the problem here is not on the Cygwin
side.

It seems Cygwin under Wine was not tested outside of XP compatibility
mode, or Wine doesn't support certain post-XP functions albeit claiming
Vista caompatibility.  Cygwin doesn't require any functionality which
isn't available in Vista.


Corinna

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


signature.asc
Description: PGP signature