[ANNOUNCEMENT] gambas3 3.11.2-1
The following packages have been uploaded to the Cygwin distribution: * gambas3-3.11.2-1 * gambas3-ide-3.11.2-1 * gambas3-runtime-3.11.2-1 * gambas3-devel-3.11.2-1 * gambas3-gb-clipper-3.11.2-1 * gambas3-gb-db-3.11.2-1 * gambas3-gb-db-form-3.11.2-1 * gambas3-gb-desktop-3.11.2-1 * gambas3-gb-desktop-x11-3.11.2-1 * gambas3-gb-eval-highlight-3.11.2-1 * gambas3-gb-form-3.11.2-1 * gambas3-gb-form-dialog-3.11.2-1 * gambas3-gb-form-editor-3.11.2-1 * gambas3-gb-form-mdi-3.11.2-1 * gambas3-gb-form-stock-3.11.2-1 * gambas3-gb-form-terminal-3.11.2-1 * gambas3-gb-image-3.11.2-1 * gambas3-gb-markdown-3.11.2-1 * gambas3-gb-net-3.11.2-1 * gambas3-gb-net-curl-3.11.2-1 * gambas3-gb-settings-3.11.2-1 * gambas3-gb-signal-3.11.2-1 * gambas3-gb-term-3.11.2-1 * gambas3-gb-util-3.11.2-1 * gambas3-gb-args-3.11.2-1 * gambas3-gb-chart-3.11.2-1 * gambas3-gb-dbus-trayicon-3.11.2-1 * gambas3-gb-logging-3.11.2-1 * gambas3-gb-media-form-3.11.2-1 * gambas3-gb-memcached-3.11.2-1 * gambas3-gb-mysql-3.11.2-1 * gambas3-gb-map-3.11.2-1 * gambas3-gb-net-pop3-3.11.2-1 * gambas3-gb-net-smtp-3.11.2-1 * gambas3-gb-report-3.11.2-1 * gambas3-gb-report2-3.11.2-1 * gambas3-gb-scanner-3.11.2-1 * gambas3-gb-term-form-3.11.2-1 * gambas3-gb-util-web-3.11.2-1 * gambas3-gb-web-3.11.2-1 * gambas3-gb-web-feed-3.11.2-1 * gambas3-gb-web-form-3.11.2-1 * gambas3-scripter-3.11.2-1 * gambas3-gb-cairo-3.11.2-1 * gambas3-gb-complex-3.11.2-1 * gambas3-gb-compress-3.11.2-1 * gambas3-gb-compress-bzlib2-3.11.2-1 * gambas3-gb-compress-zlib-3.11.2-1 * gambas3-gb-crypt-3.11.2-1 * gambas3-gb-data-3.11.2-1 * gambas3-gb-db-mysql-3.11.2-1 * gambas3-gb-db-odbc-3.11.2-1 * gambas3-gb-db-postgresql-3.11.2-1 * gambas3-gb-db-sqlite3-3.11.2-1 * gambas3-gb-dbus-3.11.2-1 * gambas3-gb-desktop-gnome-keyring-3.11.2-1 * gambas3-gb-gmp-3.11.2-1 * gambas3-gb-gsl-3.11.2-1 * gambas3-gb-gtk-3.11.2-1 * gambas3-gb-gtk-opengl-3.11.2-1 * gambas3-gb-gtk3-3.11.2-1 * gambas3-gb-httpd-3.11.2-1 * gambas3-gb-image-effect-3.11.2-1 * gambas3-gb-image-imlib-3.11.2-1 * gambas3-gb-image-io-3.11.2-1 * gambas3-gb-jit-3.11.2-1 * gambas3-gb-libxml-3.11.2-1 * gambas3-gb-media-3.11.2-1 * gambas3-gb-mime-3.11.2-1 * gambas3-gb-ncurses-3.11.2-1 * gambas3-gb-openal-3.11.2-1 * gambas3-gb-opengl-3.11.2-1 * gambas3-gb-opengl-glsl-3.11.2-1 * gambas3-gb-opengl-glu-3.11.2-1 * gambas3-gb-opengl-sge-3.11.2-1 * gambas3-gb-openssl-3.11.2-1 * gambas3-gb-option-3.11.2-1 * gambas3-gb-pcre-3.11.2-1 * gambas3-gb-pdf-3.11.2-1 * gambas3-gb-qt4-3.11.2-1 * gambas3-gb-qt4-ext-3.11.2-1 * gambas3-gb-qt4-opengl-3.11.2-1 * gambas3-gb-qt4-webkit-3.11.2-1 * gambas3-gb-qt5-3.11.2-1 * gambas3-gb-qt5-ext-3.11.2-1 * gambas3-gb-qt5-opengl-3.11.2-1 * gambas3-gb-qt5-webkit-3.11.2-1 * gambas3-gb-sdl-3.11.2-1 * gambas3-gb-sdl-sound-3.11.2-1 * gambas3-gb-sdl2-3.11.2-1 * gambas3-gb-sdl2-audio-3.11.2-1 * gambas3-gb-vb-3.11.2-1 * gambas3-gb-xml-3.11.2-1 * gambas3-gb-xml-html-3.11.2-1 * gambas3-gb-xml-rpc-3.11.2-1 * gambas3-gb-xml-xslt-3.11.2-1 Gambas is a free development environment and a full powerful development platform based on a Basic interpreter with object extensions, as easy as Visual Basic. CHANGES * Git support. * Debugger interface has been redesigned. * Project tree emblems have been redesigned. * Several enhancements in image editor. * A new dialog for inserting special characters. * Braces, brackets, markups and strings are now closed automatically. * Two new default stock icons themes. * Support for octal numbers in the interpreter. * Uninitialized local or private global variables now raise a compiler warning. * RDir() is faster. -- 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: Defaulting to stabs debug output from AS Cygwin64
Am 15.05.2018 um 19:17 schrieb Michael Enright: The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using -gdwarf2 with assembly code manually or through gcc is successful in producing a Cygwin64 executable that Cygwin64 GDB can work with. This combination of circumstances led me to wonder how stabs was chosen for Cygwin64. Basically because it was not chosen. It's not even actually supported, as evidenced by those relocation failures: not how those occurred in the .stab section. "The" default of Cygwin is whatever the compiler uses, i.e. Dwarf2, and was indeed chosen, because none of the older formats stand a chance of really handling the amount and complexity of debug information needed for modern-day C++. On to of that, making '-gdwarf-2' the default -g mode for 'as' would be an exercise in futility anyway, because that option is essentially a no-op. That's because Dwarf-2 debug information is _not_ actually created by the -g flag to begin with: it's spelled out by the compiler as reams of data and reloc statements, to go into specially named sections like '.debug_info'. GCC doesn't even pass any '-g' flag to the assembler in its default -gdwarf-2 mode. It makes sense that "as -g" equals "as -gstabs" because unlike the other ones, that one at least does something: it causes .def pseudo-ops to put data into the .stab section, which also is automatically created by that option. In a nutshell: you don't want to use either of "as -g" or "as -gstabs" -- 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] New: perl-Algorithm-Combinatorics
The Perl distribution Algorithm-Combinatorics has been added to Cygwin. x86 / x86_64 perl-Algorithm-Combinatorics-0.27-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: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)
Someone else wrote: Hi, just tried that command. There is no BSOD on my system. Windows 10 latest build, Dell laptop with latest Cygwin. Maybe there is an issue with your anti-virus or application firewall? --- (same Disclaimer -- replying to list on email sent to me privately... I would have a preference for people replying to both list and me, unless they don't want to reply publicly, the private is fine, though my *default*, (unless asked otherwise) will be to reply publicly with personal info deleted) I don't have *much* of an anti-virus and my system's on an internal network (connected via proxy or sometimes NAT for games). For malware I just use the free MS "home essentials" which I usually (including now) don't have set for real-time scanning -- I do a weekly scan which takes several hours. If it isn't set for real-time detection, though, I don't think it would be causing an issue. No? This is something that has persisted through many versions (like more than a year or two), including things like repairing the OS via an inplace "upgrade"/reinstall. So it's fairly persistent (and annoying, as I used to like to look around in all the proc dirs). -l -- 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-Win32-API package problem
SJ Luo writes: > The two lines of commands "mv ; cp xxx" are to dereference the > symbolic links of testing-needed dll files because > Win32::API::LoadLibrary() seems not be able to resolve Cygwin symbolic > link. You'd need to use native symlinks for that to work, yes. > By checking the gcc compile option, I found there is a gcc option > "-fno-stack-protector" provided when I compile this module by myself, > while the option is removed when I compile with cygport. If I try > manually compiling without this option, the same problem occurs. I don't know enough of how the stack protector actually is implemented to understand why it would work without the protector and stop working with. > The host system is Windows7. Cygwin dll is 64bit version 2.10.0-1. > wish it can be solved soon in next package release. I'll see if it's possible to remove the option from within cygport, if yo I'll have to think about any ramifications that might have. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: 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] Updated: Perl distributions
Achim Gratz writes: > Steven Penny writes: >> would you consider adding any of these: >> >> http://metacpan.org/pod/Algorithm::Combinatorics >> Testers: 10564 > > I think I have used that one before, so depending on how cleanly it > builds on Cygwin I might be able to maintain it on Cygwin. I've added it. 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: Programs become a no-op [SOLVED]
Thanks Marco, David and Brian for your responses. After the diagnostic steps described below, suggested by you, I ran the setup program and told it to reinstall cygwin, cygwin-base, and adwaita-icon-theme. ssh and man are working again. I'm a little puzzled how I got in this state, although it's possible I ran setup while I had a terminal open. And I wonder why the setup program didn't reinstall the damaged packages itself, or at least complain about them (though there were some complaints--see last paragraph below). Running strace ssh produced a popup "The procedure entry point __memcpy_chk could not be located in the dynamic link library cygwin1.dll" and cygcheck's output included Package Version Status _autorebase 001007-1OK Missing file: /usr/share/icons/Adwaita/icon-theme.cache from package adwaita-icon-theme adwaita-icon-theme3.26.1-1Incomplete alternatives 1.3.30c-10 OK at-spi2-core 2.26.2-1OK base-cygwin 3.8-1 OK base-files4.2-4 OK bash 4.4.12-3OK bzip2 1.0.6-3 OK ca-certificates 2.22-1 OK coreutils 8.26-2 OK csih 0.9.9-1 OK curl 7.59.0-1OK cygrunsrv 1.62-1 OK cygutils 1.4.16-2OK Missing file: /usr/bin/gencat.exe from package cygwin cygwin2.10.0-1Incomplete Those were the only 2 Incomplete packages. Finally, I've been getting errors from the post-installation that some packages were not setup, but since they all seemed to be graphical and I don't have cygwin/X installed I thought they were harmless. I guess they weren't. After the package reinstallation I get no such errors. Ross -- 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: Defaulting to stabs debug output from AS Cygwin64
On Tue, May 15, 2018 at 5:58 AM, cyg Simple wrote: > > Years of work tells me to not trust the default of any option. You > should be specific. I have a few years under my belt (come to think of it they are threatening to engulf my belt). For work, I'd do what's necessary to integrate the little thing into the big thing. For this I don't want to work too hard on side issues unless I decide they are interesting side issues. > > The dwarf format isn't supported by native tools. I think COFF should > be the default but that is just me and I don't maintain the distribution > of GCC. The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using -gdwarf2 with assembly code manually or through gcc is successful in producing a Cygwin64 executable that Cygwin64 GDB can work with. This combination of circumstances led me to wonder how stabs was chosen for Cygwin64. > > I question your use of Cygwin instead of MinGW for your compiler but > that is just a musing. > When I cobble together an I/O system for the language's runtime, I will probably switch the project to Linux-only. I/O is one of the interesting side issues I wish to tackle. -- 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: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)
On 2018-05-15 18:22, L A Walsh wrote: > Someone wrote: >> I tried it for the hell of it. It worked ok for me. >> Running windows 10 - build 1803 - >> >> $ uname -a >> CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin >> >> Running as an normal user - I did not try an admin acct. >> >> Good luck, someone > > (FYI -- replying to this "on-list", but anonymizing the sender's > info in case they didn't want it posted.) > > I wonder if it is Win7 specific or a quirk in my system. > Too often it is some peculiarity in my system. > > Thanks for the data point. Here's another one: works4me on my Windows 7. > CYGWIN_NT-6.1 Bahamut 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin No BSOD when running that in my home directory. I was lead to believe that no userland code could trigger BSODs anymore so I don't think that is normal. But maybe that is was only for 8+. Next time you feel like triggering one read what "module" the fault was in. Last time I got one (caused by OC instability) I think it was in ntfs.sys. signature.asc Description: OpenPGP digital signature
Re: normal to blue-screen windows when doing 'ls -CF' of /proc/sys/GLOBAL?? (bug? cygcheck attached)
Someone wrote: I tried it for the hell of it. It worked ok for me. Running windows 10 - build 1803 - $ uname -a CYGWIN_NT-10.0 spiro1 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin Running as an normal user - I did not try an admin acct. Good luck, someone (FYI -- replying to this "on-list", but anonymizing the sender's info in case they didn't want it posted.) I wonder if it is Win7 specific or a quirk in my system. Too often it is some peculiarity in my system. Thanks for the data point. -- 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: Octave crashes with segfault
I have confirmed that this is resolved with fontconfig 1.12.6-2. Thanks. On Sat, 12 May 2018 12:37:47 +0900 Takashi Yano wrote: > Hi, cygwin folks. > > I found octave cannot start, or crashes by plot command in recent > 32bit cygwin. This occurs in Windows 10 (1709 or later). > > It seems that this is a problem of fontconfig package. > > To reproduce this: > 1. Install 32bit version of cygwin with the following packages. > - octave > - gnuplot > - xorg-server > - dbus > 2. execute 'dbus-uuidgen'. Without this step, octave complains > about dbus. > 3. execute 'run XWin -multiwindow' > 4. execute 'export DISPLAY=':0.0' > 5.1 execute 'octave'. This fails with the message: > octave exited with signal 11 > 5.2 execute 'octave -W' and issue the command 'plot([])'. > This fails with the message: > panic: Segmentation fault -- stopping myself... > attempting to save variables to 'octave-workspace'... > save to 'octave-workspace' complete > Segmentation fault (core dumped) > > Workaround 1: > Remove /usr/share/fonts/microsoft/bahnschrift.ttf > > Workaround 2: > Build fontconfig package from source code and replace > cygfontconfig-1.dll. > > cygcheck.out in failure environment is attached. > > -- > Takashi Yano -- Takashi Yano -- 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: libharfbuzz0 1.7.6-1 update causing xwin-xdg-menu.exe to crash
On 05/14/2018 04:43 PM, Jon Turney wrote: On 14/05/2018 18:05, Gilles Detillieux wrote: Thanks, Jon. The local.conf blacklist rule worked like a charm! It's odd that the fontconfig packages appear not to have been built with the latest stable gcc release, but so long as it's just this one I don't know if that's the case or not. More things than just the compiler can effect the resulting binary. (unneeded) font that's causing the headaches I'll just keep blacklisting it on our systems. Yaakov has rebuilt and uploaded the fontconfig 2.12.6-2, which doesn't seem to suffer from this problem in my testing. Awesome. Upgrading to the new libfontconfig packages did indeed fix the problem. Thanks, Yaakov & Jon! -- Gilles R. Detillieux E-mail: Spinal Cord Research Centre WWW:http://www.scrc.umanitoba.ca/ Dept. of Physiology and Pathophysiology, Rady Faculty of Health Sciences, Univ. of Manitoba Winnipeg, MB R3E 0J9 (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: Request new Ruby release
On Tue, 15 May 2018 at 00:49, Steven Penny wrote: > fact. example is the Git package, which as of this writing is totally up to > date: > - http://cygwin.mirrors.hoobly.com/x86_64/release/git > - http://github.com/git/git/releases I've been avoiding this thread as I haven't had anything productive to add. However a package I maintain has now been invoked as an example, and I feel compelled to respond; I am not comfortable with my work being held up to shame other volunteer maintainers. I entirely understand the desire for up-to-date packages to be available, and clearly there are vast swathes of our packages that aren't kept at the bleeding edge of the upstream release tracks. However I don't think this email trail is a good way to encourage maintainers to put in the effort required to keep things up to date. Maintainers, at least for the most part, are going to be well aware when their packages aren't the latest code, and equally be aware of the possibilities of releasing test packages. Pointing these things out, particularly repeatedly, is unlikely to be well received. For anyone who wants to see Cygwin packages updated, a single prompt to the maintainer is occasionally useful, but further prompts are likely to be taken as hassling, not as helpful. Beyond that, I expect most maintainers will have an idea of what other people could do to help if someone offered; I know for myself I can point at specific things other people could offer to help for each of my packages, and I imagine other maintainers would also be able to answer a question of "I'd like to see this updated, what can I do to help?", even if the answer is sometimes going to be "nothing". As others have pointed out, the Cygwin package maintainers are volunteers, using their own time and resources. I don't think any of them will appreciate being described as acting in bad faith, myself included (and while Git is up-to-date, other packages I maintain aren't, for a variety of reasons, so I very much take the description as being levelled at me as much as anyone else). If someone genuinely thinks a package maintainer is acting in bad faith, or otherwise not keeping up with their responsibilities as a maintainer, *and* they're able and willing to put in the effort to take over the maintainership, that's a discussion we can have. However, certainly in the cases of Ruby and GCC and their related packages, as Yaakov has said, I don't think there's any question from the other maintainers or the folk who run the Cygwin project as a whole, that they are working in good faith and keeping up with their responsibilities to the project, even if individuals would prefer different behaviour. This thread is not going to get GCC, Ruby, or any other package updated more quickly than it otherwise would. I'd recommend folk who want to see what they can do to get things updated ask what they can do to help, and accept that the answer may be "nothing". Adam -- 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: What is Cygwin and MinGW [WAS: Request new Ruby release]
I'm moving this to the Cygwin-Talk list. On 5/14/2018 7:48 PM, Steven Penny wrote: > On Mon, 14 May 2018 10:31:18, cyg Simple wrote: >> And you a free to do so. MinGW isn't GCC > > yes it is. when you compile GCC, as i have done: > > http://github.com/svnpenn/glade/blob/master/mingw-w64-x86-64/gcc > > you choose a target. normally for this community that is > "x86_64-pc-cygwin", but > in my case it is "x86_64-w64-mingw32". but you dont use some magical > "MinGW" > repo, its the same GCC. granted, you do need to also install the target > "binutils", "headers" and "runtime", but the same source is used to > build GCC > itself. > And given this you think Cygwin is also GCC. WRONG, MinGW and Cygwin are just the runtime libraries required to build GCC and other packages. GCC is a separate entity that has its own process of accepting patches for using runtime libraries. Binutils also is a separate entity that uses even different methods of patching requirements as both Cygwin and GCC. Anyone who states that the GCC product is an entity other than GCC isn't thinking clearly about the various pieces and parts. Now to make Cygwin or MinGW useful you need the other pieces and parts but those pieces and parts do not become the entity of Cygwin or MinGW. Cygwin and MinGW remain a separate entity providing the runtime libraries to use to build other pieces and parts. -- 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: Defaulting to stabs debug output from AS Cygwin64
On 5/15/2018 12:17 AM, Michael Enright wrote: > I am working on a little compiler for fun, which generates assembly > code. At this point I manually invoke as and ld. > > For debugging I added the -g option to the invocation of as, but then > ld failed with > Years of work tells me to not trust the default of any option. You should be specific. https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html";> -g Produce debugging information in the operating system’s native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information. On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below) > t.o:t.s:1:(.stab+0x14): relocation truncated to fit: R_X86_64_32 > against `.text' > > Looking into this on Stack Overflow I was taught that stabs is > obsolete. I think 'obsolete' may not be quite the right > interpretation, but 'wrong for Cygwin64' could be the right story. > Practically speaking, without thinking about it too critically, > -gdwarf2 in place of -g is the solution. > The dwarf format isn't supported by native tools. I think COFF should be the default but that is just me and I don't maintain the distribution of GCC. > I'm trying to find authority for saying anything exact about the situation: > 1) Is there a reason why stabs is the default for '-g' with Cygwin64? I gave one above. > 1a) Is a patch desired to make dwarf2 the default? It would have to be at the upstream source level but I don't think so. > 2) Is there a way within Cygwin64 that a .o file with stabs can be > properly processed by ld to give proper input to gdb? Does -gstabs+ help? > 3) Is stabs fatally flawed for the purposes of Cygwin64 or could it be > upgraded, within the existing meaning of the stabs specification, so > that it would work? That should be asked at the GCC upstream. > 3a) To put it another way, is this just a stabs bug that could be > fixed for Cygwin64? I haven't looked at the source for the compiler to answer that. > > Above when I say Cygwin64, I'm talking about straightforward native > use of as, ld, and gdb, not cross-compiling to some other platform. I question your use of Cygwin instead of MinGW for your compiler but that is just a musing. -- 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
