Re: GCC release criteria
On 2019-08-18 08:51, Denis Excoffier wrote: > In the GCC 10 Release Criteria, one can read > (https://gcc.gnu.org/gcc-10/criteria.html) that cygwin is among the > secondary platform list: >> Secondary Platform List >> >> The secondary platforms are: >> * aarch64-elf >> * i686-apple-darwin >> * i686-pc-cygwin >> * i686-mingw32 >> * powerpc-ibm-aix7.1.0.0 >> * s390x-linux-gnu > This is ok of course, but nowadays, perhaps would it be a better choice > that they switch to x86_64-pc-cygwin? What do you think? Also mingw64-x86_64, and doubt there is an i686-apple-darwin, more likely x86_64-/amd64-apple-darwin. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-DBD-SQLite-1.64-1 perl-Scalar-List-Utils-1.52-1 perl-Unicode-Normalize-1.26-1 (test) noarch -- perl-DateTime-Calendar-Julian-0.101-1 perl-Mojolicious-8.23-1 perl-Specio-0.44-1 perl-Test-Simple-1.302166-1 perl-Test2-Suite-0.000124-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-DBD-SQLite-1.64-1 perl-Scalar-List-Utils-1.52-1 perl-Unicode-Normalize-1.26-1 (test) noarch -- perl-DateTime-Calendar-Julian-0.101-1 perl-Mojolicious-8.23-1 perl-Specio-0.44-1 perl-Test-Simple-1.302166-1 perl-Test2-Suite-0.000124-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Clang is using the wrong memory model
On 18/08/2019 13.57, Corinna Vinschen wrote: Nope, Cygwin uses the Windows loader. Then, how do you do the extra linking? What is producing the "Cygwin runtime failure" message when loading/linking a DLL fails? If the medium model is wasteful in clang, that's a clang optimization problem, not a Cygwin problem. The medium model in Clang is not wasteful. It does exactly what it is designed to do. It was never designed with Cygwin in mind. The program build with a medium model is wasteful because it makes all addresses 64 bits when few or no addresses actually need to be 64 bits. If you want to use the small model in your own projects, great, if it works for you. It is not for my own project. I am writing manuals on how to optimize software. Agner -- 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: Perl Unicode-Normalize
On 8/18/2019 8:08 AM, Achim Gratz wrote: > Ken Brown writes: >> If you can get to it within the next few days, that would be great. If not, >> I >> can just install it from CPAN temporarily for the purpose of building the >> packed >> archive. > > I've uploaded it as a test package for both architectures. > > perl-Unicode-Normalize-1.26-1 Thanks! Ken
GCC release criteria
Hello, In the GCC 10 Release Criteria, one can read (https://gcc.gnu.org/gcc-10/criteria.html) that cygwin is among the secondary platform list: > > Secondary Platform List > > The secondary platforms are: > * aarch64-elf > * i686-apple-darwin > * i686-pc-cygwin > * i686-mingw32 > * powerpc-ibm-aix7.1.0.0 > * s390x-linux-gnu > This is ok of course, but nowadays, perhaps would it be a better choice that they switch to x86_64-pc-cygwin? What do you think? Regards, Denis Excoffier. -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Corinna Vinschen writes: > There's no xlocale.h on Linux either. What do these packages do in > that case? I've dug a little bit deeper. The trouble is that perl.h has picked up xlocale.h as the location of some of the interfaces it wants to use during configuration, so that means you can't compile any XS modules after the update to 3.1.0 anymore. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 18 14:06, Achim Gratz wrote: > Corinna Vinschen writes: > > - Eliminate a header file name collision with on case > > insensitive filesystems by reverting back to . > > What's the suggested way to deal with software that expects to be able > to "#include "? I think I'll see that more often than X11 > applications that have their include directives set up wrongly. There's no xlocale.h on Linux either. What do these packages do in that case? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Perl Unicode-Normalize
Ken Brown writes: > If you can get to it within the next few days, that would be great. If not, > I > can just install it from CPAN temporarily for the purpose of building the > packed > archive. I've uploaded it as a test package for both architectures. perl-Unicode-Normalize-1.26-1 Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Corinna Vinschen writes: > - Eliminate a header file name collision with on case > insensitive filesystems by reverting back to . What's the suggested way to deal with software that expects to be able to "#include "? I think I'll see that more often than X11 applications that have their include directives set up wrongly. I guess I could make a symlink, but that's iffy. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
[newlib-cygwin] Cygwin: select: revamp non-polling code for signalfd
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7097b05eda2f8e9058eab4fda8dedacdfb7ffd7f
commit 7097b05eda2f8e9058eab4fda8dedacdfb7ffd7f
Author: Corinna Vinschen
Date: Fri Aug 16 16:36:06 2019 +0200
Cygwin: select: revamp non-polling code for signalfd
Rather than waiting for signalfd_select_wait in a thread, which is racy,
create a global event "my_pendingsigs_evt" which is set and reset by
wait_sig depending only on the fact if blocked signals are pending or not.
This in turn allows to WFMO on this event in select as soon as signalfds
are present in the read descriptor set. Select's peek and verify
will then check if one of the present signalfds is affected.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/cygtls.h | 2 +-
winsup/cygwin/exceptions.cc | 8 -
winsup/cygwin/select.cc | 80 +++-
winsup/cygwin/select.h | 11 ++
winsup/cygwin/signal.cc | 1 -
winsup/cygwin/sigproc.cc | 17 ++
winsup/cygwin/tlsoffsets.h | 16 -
winsup/cygwin/tlsoffsets64.h | 16 -
8 files changed, 40 insertions(+), 111 deletions(-)
diff --git a/winsup/cygwin/cygtls.h b/winsup/cygwin/cygtls.h
index 65a905c..a2e3676 100644
--- a/winsup/cygwin/cygtls.h
+++ b/winsup/cygwin/cygtls.h
@@ -189,8 +189,8 @@ public:
stack_t altstack;
siginfo_t *sigwait_info;
HANDLE signal_arrived;
- HANDLE signalfd_select_wait;
bool will_wait_for_signal;
+ long __align;/* Needed to align context to 16 byte.
*/
/* context MUST be aligned to 16 byte, otherwise RtlCaptureContext fails.
If you prepend cygtls members here, make sure context stays 16 byte
aligned. */
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 1765f43..848f9bd 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1469,14 +1469,6 @@ sigpacket::process ()
if (issig_wait)
{
tls->sigwait_mask = 0;
- /* If the catching thread is running select on a signalfd, don't call
-the signal handler and don't remove the signal from the queue. */
- if (tls->signalfd_select_wait)
- {
- SetEvent (tls->signalfd_select_wait);
- rc = 0;
- goto done;
- }
goto dosig;
}
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 4e9256b..ac73e0a 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -1849,80 +1849,6 @@ fhandler_windows::select_except (select_stuff *ss)
return s;
}
-static int start_thread_signalfd (select_record *, select_stuff *);
-
-static DWORD WINAPI
-thread_signalfd (void *arg)
-{
- select_signalfd_info *si = (select_signalfd_info *) arg;
- bool event = false;
-
- while (!event)
-{
- sigset_t set = 0;
- _cygtls *tls = si->start->tls;
-
- for (select_record *s = si->start; (s = s->next); )
- if (s->startup == start_thread_signalfd)
- set |= ((fhandler_signalfd *) s->fh)->get_sigset ();
- set_signal_mask (tls->sigwait_mask, set);
- tls->signalfd_select_wait = si->evt;
- sig_dispatch_pending (true);
- switch (WaitForSingleObject (si->evt, INFINITE))
- {
- case WAIT_OBJECT_0:
- tls->signalfd_select_wait = NULL;
- event = true;
- break;
- default:
- break;
- }
- if (si->stop_thread)
- break;
- if (!event)
- Sleep (1L);
-}
- CloseHandle (si->evt);
- return 0;
-}
-
-static int
-start_thread_signalfd (select_record *me, select_stuff *stuff)
-{
- select_signalfd_info *si;
-
- if ((si = stuff->device_specific_signalfd))
-{
- me->h = *si->thread;
- return 1;
-}
- si = new select_signalfd_info;
- si->start = >start;
- si->stop_thread = false;
- si->evt = CreateEventW (_none_nih, TRUE, FALSE, NULL);
- si->thread = new cygthread (thread_signalfd, si, "signalfdsel");
- me->h = *si->thread;
- stuff->device_specific_signalfd = si;
- return 1;
-}
-
-static void
-signalfd_cleanup (select_record *, select_stuff *stuff)
-{
- select_signalfd_info *si;
-
- if (!(si = stuff->device_specific_signalfd))
-return;
- if (si->thread)
-{
- si->stop_thread = true;
- SetEvent (si->evt);
- si->thread->detach ();
-}
- delete si;
- stuff->device_specific_signalfd = NULL;
-}
-
static int
peek_signalfd (select_record *me, bool)
{
@@ -1942,17 +1868,19 @@ verify_signalfd (select_record *me, fd_set *rfds,
fd_set *wfds, fd_set *efds)
return peek_signalfd (me, true);
}
+extern HANDLE my_pendingsigs_evt;
+
select_record *
fhandler_signalfd::select_read (select_stuff *stuff)
{
select_record *s = stuff->start.next;
if (!s->startup)
{
- s->startup = start_thread_signalfd;
+ s->startup = no_startup;
s->verify = verify_signalfd;
- s->cleanup = signalfd_cleanup;
}
s->peek = peek_signalfd;
+ s->h =
[newlib-cygwin] Revert "Cygwin: fix potential SEGV in sigwaitinfo/signalfd scenario"
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=b7399d5e6f8ad5b15cd725f66b3e49732393ef03
commit b7399d5e6f8ad5b15cd725f66b3e49732393ef03
Author: Corinna Vinschen
Date: Fri Aug 16 16:36:20 2019 +0200
Revert "Cygwin: fix potential SEGV in sigwaitinfo/signalfd scenario"
This reverts commit 92115a83a4579635e253be2887d3706d28b477fd.
This was utterly wrong.
Diff:
---
winsup/cygwin/exceptions.cc | 17 +++--
winsup/cygwin/release/3.1.0 | 3 ---
2 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 9bdf9f0..1765f43 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1628,7 +1628,7 @@ _cygtls::call_signal_handler ()
if (retaddr () == (__tlsstack_t) sigdelayed)
pop ();
- debug_only_printf ("dealing with signal %d, handler %p", sig, func);
+ debug_only_printf ("dealing with signal %d", sig);
this_sa_flags = sa_flags;
sigset_t this_oldmask = set_process_mask_delta ();
@@ -1647,12 +1647,8 @@ _cygtls::call_signal_handler ()
ucontext_t *thiscontext = NULL, context_copy;
- /* Only make a context for SA_SIGINFO handlers, only if a handler
- exists. If handler is NULL, drop SA_SIGINFO flag to avoid
-accidental context access later in the function. */
- if (!thisfunc)
- this_sa_flags &= ~SA_SIGINFO;
- else if (this_sa_flags & SA_SIGINFO)
+ /* Only make a context for SA_SIGINFO handlers */
+ if (this_sa_flags & SA_SIGINFO)
{
context.uc_link = 0;
context.uc_flags = 0;
@@ -1714,11 +1710,6 @@ _cygtls::call_signal_handler ()
sig = 0; /* Flag that we can accept another signal */
unlock (); /* unlock signal stack */
- /* Handler may be NUll in sigwaitinfo/signalfd scenario. Avoid
-crashing by calling a NULL function. */
- if (!thisfunc)
- goto skip_calling_handler;
-
/* Alternate signal stack requested for this signal and alternate signal
stack set up for this thread? */
if (this_sa_flags & SA_ONSTACK
@@ -1826,8 +1817,6 @@ _cygtls::call_signal_handler ()
signal handler. */
thisfunc (thissig, , thiscontext);
-skip_calling_handler:
-
incyg = true;
set_signal_mask (_my_tls.sigmask, (this_sa_flags & SA_SIGINFO)
diff --git a/winsup/cygwin/release/3.1.0 b/winsup/cygwin/release/3.1.0
index c9cb7c0..ccb63c3 100644
--- a/winsup/cygwin/release/3.1.0
+++ b/winsup/cygwin/release/3.1.0
@@ -71,6 +71,3 @@ Bug Fixes
- 64 bit only: Avoid collisions between memory maps created with shmat
and Windows datastructures during fork.
Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html
-
-- Avoid a SEGV after using signalfd.
- Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00148.html
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 18 01:43, Takashi Yano wrote: > Hi Corinna, > > On Fri, 16 Aug 2019 16:48:11 +0200 > Corinna Vinschen wrote: > > I now had an idea, but I'm not entirely sure if it's the right thing to > > do. Can you please test this? It consists of two patches, one with the > > revamped signalfd handling, and one with the revert of the signalfd > > patch I applied a couple of days ago. > > > > Quick description: I dropped signalfd_select_wait entirely. Instead, > > wait_sig sets or resets a manual event object to indicate if there are > > signals pending in the queue, even after trying to handle them the > > normal way. That usually means they are blocked. > > > > select() uses the event to wake up from WFMO, if at least one signalfd > > is present in the read descriptor set. The rest is done via the peek > > and verify functions in select, which basically just check if this > > signalfd is waiting for one of the pending signals. > > > > The reversion of my patch from a couple days ago is not required as > > such, but after thinking about this a while I'm convinced that this was > > just me not getting the full picture. Also, reverting this patch would > > revert to seeing a SEGV in your testcase and thus a bug in the new code, > > too. > > > > I attached both patches. It would be pretty nice if you could test them > > and point out any problems you get with this new code. > > > > Please note that you should ideally perform a full rebuild due to the > > slight change in TLS layout. > > I confirmed that my STC and script command works as expected with these > patches. > > Thank you for greate work! Great, thank you, and thanks for testing! Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Clang is using the wrong memory model
On Aug 18 08:04, Agner Fog wrote: > Thanks a lot for your help in clarifying this. > > When I complained here about the wasteful 64-bit addresses you said that it > was an LLVM issue. I never said anything like that. The issue is that your clang linux->cygwin cross compiler uses the wrong model, that's all. That's a bug in clang or whatever it's using under the hood. Clang should follow what GCC does for years, using the medium model on Cygwin. > When I complained to LLVM they said it was a Cygwin > issue, and that you were using the wrong memory model. > > All this confusion is due to a terrible lack of documentation of everything. > I had to do a lot of reverse engineering to figure out what is happening. > What I have found out so far is listed below. Much of this is undocumented. > Obviously, I would like to know if any or this is wrong or if specific > documentation is available other than the SysV ABI and Windows ABI: > > * Cygwin is using its own loader which is different from the Windows loader. Nope, Cygwin uses the Windows loader. > * The Cygwin loader emulates the behavior of Linux shared objects. This > includes the ability to directly access a variable inside a DLL See above. > * Access to a variable in a different DLL requires a 64-bit address. This is > obtained by using the medium memory model with a gcc or Clang compiler. ACK [...] To me, the only interesting thing is that clang continues to use the medium memory model *by default*. It doesn't make sense if package maintainers and devs building something on Cygwin have to care for memory models all of a sudden. The default should just work. If you want to use the small model in your own projects, great, if it works for you. If the medium model is wasteful in clang, that's a clang optimization problem, not a Cygwin problem. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
[ANNOUNCEMENT] Updated: engauge-digitizer-12
Version 12 of "engauge-digitizer" has been uploaded. Interactively converts a bitmap graph or map into numbers. Changes: * More point styles * Fix export issue with log scale data and small step values *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Updated: engauge-digitizer-12
Version 12 of "engauge-digitizer" has been uploaded. Interactively converts a bitmap graph or map into numbers. Changes: * More point styles * Fix export issue with log scale data and small step values *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: Clang is using the wrong memory model
Thanks a lot for your help in clarifying this.
When I complained here about the wasteful 64-bit addresses you said that
it was an LLVM issue. When I complained to LLVM they said it was a
Cygwin issue, and that you were using the wrong memory model.
All this confusion is due to a terrible lack of documentation of everything.
I had to do a lot of reverse engineering to figure out what is
happening. What I have found out so far is listed below. Much of this is
undocumented. Obviously, I would like to know if any or this is wrong or
if specific documentation is available other than the SysV ABI and
Windows ABI:
* Cygwin is using its own loader which is different from the Windows
loader.
* The Cygwin loader emulates the behavior of Linux shared objects. This
includes the ability to directly access a variable inside a DLL
* Access to a variable in a different DLL requires a 64-bit address.
This is obtained by using the medium memory model with a gcc or Clang
compiler.
* The small memory model works differently on different targets. A
-mcmodel=small with a Linux target puts everything below 2GB addresses.
32-bit absolute addresses are allowed. -mcmodel=small with a Windows or
Mac target allows addresses above 2GB, but limits the distance between
code and data in the same executable to 2GB. 32-bit absolute addresses
are not allowed. 32-bit relative addresses are used instead.
* The memory models work differently in gcc an Clang. Gcc with a medium
or large memory model is using 64-bit address tables to access a
variable in a different C/CPP file. Clang with a medium or large memory
model is using 64-bit addresses not only for external variables, but
also for local static data. This includes floating point constants,
string constants, array initializers, jump tables, global variables, and
more.
* Cygwin uses a medium memory model by default. The medium memory model
is necessary only for a program that makes direct access to a variable
in a different DLL. The medium memory model is wasteful, and more so
with Clang than with gcc.
Now I am speculating what we can do to avoid the wasteful 64-bit
address-load instructions to improve the performance of Cygwin programs.
We can improve performance by using the small memory model when
possible. The medium memory model is needed only for programs that link
to a variable in a different DLL. The DLL that contains the link target
does not need the medium memory model.
Direct access to a variable in a different DLL is considered bad
programming practice by modern standards. This should occur only in old
Linux code.
A link to a variable in a different DLL may be replaced by function
calls (this is done with errno). In some cases, static linking can be an
efficient alternative.
It would be helpful if the Cygwin loader could print the name of the
offending variable when relocation fails with the small memory model.
This could help programmers remove any obstacles to using the more
efficient small memory model.
Agner
On 17/08/2019 10.16, Corinna Vinschen wrote:
Oe Aug 17 07:31, Agner Fog wrote:
So errno was a bad example but you can try accessing e.g. __ctype_ptr__,
__progname, optarg, h_errno, or use FE_DFL_ENV from another DLL, just
for kicks.
__ctype_ptr__ is a function
h_errno works like errno with an imported function
FE_DFL_ENV is a macro
__progname and optarg are local variables to each exe or dll
That would contradict what, e.g., __progname is for. Here's a test:
$ cat > dll.c <
extern char *__progname;
void
printprog ()
{
printf ("progname: %s\n", __progname);
}
EOF
$ cat > main.c <
gcc is using the small memory model by default in Cygwin64, and it works.
No, it's not, see above.
clang is using the small memory by default when cross-compiling for a Cygwin64
target from Linux, and it works.
...in *your* example code.
Corinna
--
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
