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