|
»
»
GCC 4.4 on mingw
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
 |
GCC 4.4 on mingw
by Diego Iastrubni-4
::
Rate this Message:
Hi,
I downloaded the automated installer and I see that it (stiil?) installes gcc 3.4. I assume I can install the 4.4 version of gcc manually. But my question is why isn't it the defaut yet? Are there any known issues?
- diego ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Roger Pack
::
Rate this Message:
> I downloaded the automated installer and I see that it (stiil?) installes
> gcc 3.4. I assume I can install the 4.4 version of gcc manually. But my > question is why isn't it the defaut yet? Are there any known issues? One issue is that the 4.4 version uses dwarf2 exception handling, which...is a bit less compatible with 3.4.5, so you need to be careful. -r ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Brecht Sanders
::
Rate this Message:
Roger Pack wrote: >> I downloaded the automated installer and I see that it (stiil?) installes >> gcc 3.4. I assume I can install the 4.4 version of gcc manually. But my >> question is why isn't it the defaut yet? Are there any known issues? >> I'm using MinGW 4.4.0 and most things compile fine for me. To create .exe files I now always link with the -static-libgcc option to avoid the dependancy on libstdc++.dll, because I'm not sure it is distributable. > One issue is that the 4.4 version uses dwarf2 exception handling, > which...is a bit less compatible with 3.4.5, so you need to be > careful. I used to be able to debug my code in Code::Blocks, but since I switched to MinGW 4.4.0 this no longer works properly. Initially it would just hang when I started debugging. Then I switched gdb-6.3-2 and now debugging does something but Code::Blocks seems not to know which line is being debugged. Is this maybe related to exception handling or anything else new in 4.4 in any way? ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Diego Iastrubni-4
::
Rate this Message:
It's a known fact that gcc3 and gcc4 are not compatible, no nothing new in here for me.
The real question remains: why are you still distributing 3.4 and not 4.4?
On Mon, Oct 5, 2009 at 2:07 PM, Roger Pack <rogerdpack2@...> wrote:
------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
Please do not top post. Do it again, and I will delete your message
without reading it; hence, you will see no further reply from me. On Monday 05 October 2009 18:32:04 Diego Iastrubni wrote: > The real question remains: why are you still distributing 3.4 and > not 4.4? We *are* distributing GCC-4.4.0, in addition to GCC-3.4.5. However, if what you are really asking is why the Automated Installer doesn't support GCC-4.4, (I can't determine that, because you didn't quote context appropriately, and I don't have time to waste trying to unravel insultingly top-posted content), then the answer is simple: the Automated Installer is unmaintained, and has been since GCC-3.4.5 was incorporated; it is now classed as deprecated, in favour of the upcoming mingw-get, and will not be developed further. The effort required to rewrite a deprecated installer every time the distribution requirements change is an onerous task, on which our current GCC maintainer has (quite reasonably) chosen not to waste his time. -- Regards, Keith. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Diego Iastrubni-4
::
Rate this Message:
> On Monday 05 October 2009 18:32:04 Diego Iastrubni wrote:
>> The real question remains: why are you still distributing 3.4 and >> not 4.4? > > We *are* distributing GCC-4.4.0, in addition to GCC-3.4.5. Sorry, you are correct: I was actually asking about the automated installer. > simple: the Automated Installer is unmaintained, and has been since > GCC-3.4.5 was incorporated; it is now classed as deprecated, in > favour of the upcoming mingw-get, and will not be developed further. Currently the automated installer is "featured" on the front page. On the right, "Popular content" => "HOWTO Install the MinGW (GCC) Compiler Suite" which links to http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite This clearly suggest to use MinGW-5.1.4.exe, which is by now deprecated. Please document that an 4.4 based toolchain is stable, since Qt/Trolltech/Nokia are still distributing with their Qt SDK an outdated and non supported. Also, it would help if the site contained a documentation in the front page for mingw-get (I tried a google search, and found nothing relevant, some posts on random sites, the cvs but no real information for users). ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Takashi Ono
::
Rate this Message:
Hi all,
In message "Re: [Mingw-users] GCC 4.4 on mingw", Diego Iastrubni wrote... >Sorry, you are correct: I was actually asking about the automated installer. According to the release note GCC 4.4.0 has a restriction that the exceptions can be thrown accross the dll boundaries if and only if all modules are dynamically linked to libgcc. Additionally, as I wrote in this mailing list, with the release of GCC 4.4.0 the exceptions can be rethrown accross the dll boundary if and only if all modules are dynamically linked to libstdc++, which is still incomplete in the distribution and has concerns in redistributing. These facts should be considered when switching the automated installer. Best Regards, ---- Takashi Ono(HK Freak) mailto:t_ono@... or MHF00056@... (Personal Address, checked every morning/evening and holidays) mailto:t_ono@... (Address for business, checked every working days) http://www.hkfreak.net ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Clive McCarthy
::
Rate this Message:
<2a7dfb920910051032t26b05c38hedc6102153c7d0b5@...> <200910052055.12211.keithmarshall@...> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 ---------------------------------------- > From: keithmarshall@... > To: mingw-users@... > Date: Mon=2C 5 Oct 2009 20:55:11 +0100 > Subject: Re: [Mingw-users] GCC 4.4 on mingw > > Please do not top post. Do it again=2C and I will delete your message > without reading it=3B hence=2C you will see no further reply from me. > > On Monday 05 October 2009 18:32:04 Diego Iastrubni wrote: >> The real question remains: why are you still distributing 3.4 and >> not 4.4? > > We *are* distributing GCC-4.4.0=2C in addition to GCC-3.4.5. > > However=2C if what you are really asking is why the Automated Installer > doesn't support GCC-4.4=2C (I can't determine that=2C because you didn't > quote context appropriately=2C and I don't have time to waste trying > to unravel insultingly top-posted content)=2C then the answer is > simple: the Automated Installer is unmaintained=2C and has been since > GCC-3.4.5 was incorporated=3B it is now classed as deprecated=2C in > favour of the upcoming mingw-get=2C and will not be developed further. > > The effort required to rewrite a deprecated installer every time the > distribution requirements change is an onerous task=2C on which our > current GCC maintainer has (quite reasonably) chosen not to waste > his time. > > -- > > Regards=2C > Keith. > I had the same question a few weeks ago and someone pointed me to Twilight = Dragon Media. I got my 4.4.0 from them and it seems fine. =0A= _________________________________________________________________=0A= Hotmail: Trusted email with powerful SPAM protection.=0A= http://clk.atdmt.com/GBL/go/177141665/direct/01/= ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
On Monday 05 October 2009 21:21:15 Diego Iastrubni wrote:
> > simple: the Automated Installer is unmaintained, and has been > > since GCC-3.4.5 was incorporated; it is now classed as > > deprecated, in favour of the upcoming mingw-get, and will not be > > developed further. > > Currently the automated installer is "featured" on the front page. > On the right, "Popular content" => "HOWTO Install the MinGW (GCC) > Compiler Suite" which links to > http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Sui >te > > This clearly suggest to use MinGW-5.1.4.exe, which is by now > deprecated. In fact, the latest patch brings that to MinGW-5.1.6.exe. I foresee no further patches being applied; in the absence of a *committed* volunteer to maintain it further, (and given its deprecated status), this is the end of the line, for that product. > Please document that an 4.4 based toolchain is stable, The documentation, to which you refer, is a wiki; as such, it is maintained by *you*, the users. Why do you think anyone other than yourself should assume the responsibility for this? Rather than demand that someone else do it, you could do it yourself. > since Qt/Trolltech/Nokia are still distributing with their Qt SDK > an outdated and non supported. What these third parties choose to distribute is their own affair; we have no influence over it. If you dislike their policies, or their failure to keep up-to-date with release announcements, then complain to them. > Also, it would help if the site contained a documentation in the > front page for mingw-get ... There is nothing useful to document, as yet; when there is, I will do so. Meanwhile, the more time I spend on rebuttal of futile demands such as this, the more will development of mingw-get be delayed. -- Regards, Keith. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Roger Pack
::
Rate this Message:
> However, if what you are really asking is why the Automated Installer
> doesn't support GCC-4.4, (I can't determine that, because you didn't > quote context appropriately, and I don't have time to waste trying > to unravel insultingly top-posted content), then the answer is > simple: the Automated Installer is unmaintained, and has been since > GCC-3.4.5 was incorporated; it is now classed as deprecated, in > favour of the upcoming mingw-get, and will not be developed further. How can we help out/contribute to development of mingw-get? Who does this? Is it a port of apt-get to windows? Much thanks. -r ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
On Wednesday 07 October 2009 21:51:24 Roger Pack wrote:
> How can we help out/contribute to development of mingw-get? If you are interested in helping out, please contact me privately, and we'll consider setting you up as a MinGW developer. > Who does this? I initiated it, with a conceptual wxWidgets prototype for the UI. John E. (the name behind TDM) developed that further, without the dependency on wxWidgets, but still little more than a UI prototype. Currently, I believe I am the only one actively working on it. > Is it a port of apt-get to windows? No, although from a users perspective its CLI incarnation will bear a strong superficial resemblance, while the GUI will be modelled on synaptic. However, it will *not* rely on any package format other than humble tar archives, (as we currently distribute); package relationships will be specified in free-standing XML configuration files, which will be hosted alongside the packages themselves. At present, I am focussing on creating the API components to support dependency resolution and package installation, coupled only with a CLI implementation initially; as I progress this, I am refining the accompanying XML specification. I would certainly appreciate some help, especially to integrate my API with the tentatively proposed GUI interface. In the next week or so, I hope to find time to tidy up the existing CVS, and push my experimental API components to it. -- Regards, Keith. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Brecht Sanders
::
Rate this Message:
Have you considered using devpak as a format (see: http://www.devpaks.org/)? Basically they are .tar.bz2 files with an extra .ini-style file containing some meta data. And I believe this also includes basic dependancy information. I have currently successfully compiled over 250 open source libraries using MinGW, and I am playing with the idea to publish them somewhere. Devpak format seemed like a good choice because it's well supported in Dev-C++ and Code::Blocks. If you are also working on a format that will support better package management I am very interested. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
On Tuesday 13 October 2009 07:52:34 Brecht Sanders wrote:
> > [mingw-get] will *not* rely on any package format other than > > humble tar archives, (as we currently distribute); package > > relationships will be specified in free-standing XML > > configuration files, which will be hosted alongside the packages > > themselves. > > Have you considered using devpak as a format ... No; nor do I think that such a format would be appropriate to our needs. > Basically they are .tar.bz2 files with Okay; we are moving towards .tar.lzma (or maybe even .tar.xz) as de-facto standard, but mingw-get will also support distribution of older .tar.gz and .tar.bz2 package formats. > an extra .ini-style file containing some meta data. And I believe > this also includes basic dependancy information. For mingw-get, the meta data *will* be XML; the entire package collection will be represented internally, as an XML tree. The segregation of tarball and meta data is also a necessary choice, since mingw-get must be able to acquire and construct that XML tree dynamically, from internet hosted resources, *without* having to search within arbitrary unspecified packages. > I have currently successfully compiled over 250 open source > libraries using MinGW, and I am playing with the idea to publish > them somewhere. Nice! Did you consider offering them as "contributed" packages, via our own hosting service? We are always willing to accommodate such distributions, provided the contributor commits to supporting his or her packages; you only have to ask. > Devpak format seemed like a good choice because it's well supported > in Dev-C++ and Code::Blocks. While that may be important to you, it isn't particularly relevant to MinGW. > If you are also working on a format that will support better > package management I am very interested. Depending on your concept of "package management", mingw-get may or may not meet your criteria. It will *not* use an integrated package format like .deb or .rpm, so will not need dpkg or similar. It *will* support package distribution in the form of tarballs, as we currently use. It *will* use *free-standing* XML specifications of the package meta data; that will include a capability for specifying inter-package dependencies, as a "requires package=tarname" spec. It will install user specified packages, selected from those listed in the XML tree, with automatic "requires" dependency resolution. What is considered as a "supported package" will be entirely determined by the content of the XML; that allows for addition of new packages at any time, simply be editing the XML, without needing a rebuild of mingw-get itself, (which I consider to be one of our NSIS installer's most critical failings). -- Regards, Keith. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Diego Iastrubni-4
::
Rate this Message:
(comment is slightly out of order.... sorry) On Tue, Oct 13, 2009 at 11:58 AM, Keith Marshall <keithmarshall@...> wrote: > Have you considered using devpak as a format ...
Interoperability is not important to mingw? 2 different groups of people doing (more or less) the same sound like a waste of time/dead-dinosaurs. Can you provide good technical details? I mean besides including the in-package meta description (which is a good technical reason!).
The compression format is not that relevant, as Dev-C++ and Code::Blocks can (should?) include a better compression algorithm. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Brecht Sanders
::
Rate this Message:
I have to agree the dependancy information is too limited to use an a package manager type of application that automatically resolves dependancies.On Tuesday 13 October 2009 07:52:34 Brecht Sanders wrote: I hope your new package format will get well adopted to the point maybe that somebody will even write a Code::Blocks package manager plug-in. Although, if your package manager can be run inside de MinGW directory that Code::Blocks points to it will work just as good from a seperate directory. Are planning on making it a portable application - in the sense that it doesn't install in the registry, uses relative paths and can be used in multiple directories e.g. to have a MinGW 3.x and 4.x along side each other? Any benefit of using .xz over .lzma? I recall they use the same compression algorithm, but .xz is still in beta. XML sounds good and seperate distribution will indeed be needed for your package manager. Any idea what kind of date you will include in it? In my devpaks I like to include these fields: - basename (e.g.: freetype2) - version (e.g.: 2.3.11) - description (e.g.: A Free, High-Quality, and Portable Font Engine) - dependancies (e.g.: zlib) - relative path of license file (e.g.: docs/GPL.TXT) - license file (e.g.: GPL2) - homepage URL (e.g.: http://freetype.sourceforge.net/) - download URL containing at least latest version, preferably HTTP (e.g.: http://mirrors.aixtools.net/sv/freetype/) Were you considering similar fields? I can't guarantee any commitment, because I can't guarantee when and how much time I can spare to work on them. Some packages I have built I never really tested. How does your hosting service work exactly, is there an FTP upload or SVN commit kind of method to send files? I was thinking more about those users coming from other IDEs. Giving them an all in one solution (like Code::Blocks shipped with MinGW and a DevPak manager) will make it easier to switch environments. I was in this situation many years ago. I was working with Borland, and instead of buying the newer version I discovered Dev-C++ and later Code::Blocks. I never used the old IDE ever again! So you won't be able to do dependencies on minimal version numbers like "requires package=expat, version>=2.0.0" ? What my experiences with devpaks told me is that sometimes the same version of the same library is circulating in different versions with or without certain functionality/dependancies. This can be because one was built without support for a library and the other with, either because the latter had the library in his/her build environment or a configure switch (e.g. --with(out)-mysql) was used. An end-user may decide to use the lighter version to avoid unneeded overhead in the library, while another one may need the larger version because of it's extra functionality. What's your view on this? Should the meta-XML contain some information on which functionality is available (e.g.: type configure flags used, or the output which is sometimes at the end of the configure script that shows what features are enabled)? I'm not trying to make your project more complex, just handing you some considerations from the field ;-) ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
Hi Brecht,
Please adjust your mailer to post plain text only, not multipart alternative with plain text and HTML duplicates. Also, please keep line length to between 65 and 72 characters, thanks. On Wednesday 14 October 2009 08:15:45 Brecht Sanders wrote: > Are [you] planning on making [mingw-get] a portable application - > in the sense that it doesn't install in the registry, It will not touch the registry. > uses relative paths and It will install into its own sysroot, (which may, but need not coincide with the MinGW sysroot). > can be used in multiple directories e.g. to have a MinGW 3.x and > 4.x along side each other? It will support multiple side-by-side installations, each with its own distinct sysroot. (Each "subsystem" will have its own distinct sysroot; two distinct mingw32 installs could share a common MSYS, or vice-versa). > Any benefit of using .xz over .lzma? I recall they use the same > compression algorithm, They do; however, AIUI, lzma lacks any form of reliably identifiable file "magic", whereas xz does add an appropriate signature. > but .xz is still in beta. It is, although now very close to release, and seems quite stable. > Any idea what kind of date you will include in it? > In my devpaks I like to include these fields: > - basename (e.g.: freetype2) > - version (e.g.: 2.3.11) Much of it is encapsulated in the "canonical package name" format, which we have adopted, as described in Chuck Wilson's document at http://mingw.org/PackageIdentificationHOWTO As an example, Chris Sutcliffe's recent expat DLL package specifies: $ ./pkginfo.exe libexpat-2.0.1-1-mingw32-dll-1.tar.gz Package Name: libexpat Package Version: 2.0.1 Package Build: 1 Subsystem Name: mingw32 Subsystem Version: <unspecified> Subsystem Build: <unspecified> Release Status: <unspecified> Release Reference: <unspecified> Component Type: dll Component Version: 1 Archive Format: tar Compression Type gz (pkginfo is part of mingw-get; you'll find it in our CVS on SF). > - description (e.g.: A Free, High-Quality, and Portable Font > Engine) > - dependancies (e.g.: zlib) Already included in the proposed XML spec; deployed as in John E's prototype, (posted here last year). > - relative path of license file (e.g.: docs/GPL.TXT) > - license file (e.g.: GPL2) Always provided in a component package, designated as type "lic". > - homepage URL (e.g.: http://freetype.sourceforge.net/) Already included in my XML prototype, but not actually utilised. > - download URL containing at least latest version, preferably HTTP > (e.g.: http://mirrors.aixtools.net/sv/freetype/) Not exactly optional, is it? Downloads won't work without this; (mingw-get will take care of downloading what's needed). > Were you considering similar fields? See my attached prototype; this isn't final, but should give you some idea of what we have in mind. > How does your hosting service work exactly, It's SF's file release system. > So you won't be able to do dependencies on minimal version numbers > like "requires package=expat, version>=2.0.0" ? Indeed we will! A dependency of the form: <requires eq="foo-1.0.5-1-mingw32-dll-1.tar" /> depends on DLL version 1 from package "foo", built for "mingw32" with an exact version match to "1.0.5-1"; substitute ge for eq, for an exact or more recent version match, (or analogously for gt, lt, le); substitute "*" for "1.0.5-1", to match any available version, or "&" rather than "*" for identically the same version as the dependant, (e.g. gcc-g++-3.4.5-mingw32-... depends on gcc-core-&-mingw32-...). > Should the meta-XML contain some information on which > functionality is available (e.g.: type configure flags used, or > the output which is sometimes at the end of the configure script > that shows what features are enabled)? I don't think that's necessary, but it could easily be accommodated, even if not actually used for the time being. > I'm not trying to make your project more complex, just handing you > some considerations from the field ;-) It's appreciated, but let's keep it simple for now; extra features can always be considered later. -- Regards, Keith. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <software-distribution project="MinGW" home="http://www.mingw.org" issue="2008082000"> <package-group-hierarchy> <package-group name="MinGW" expand="true"> <package-group name="MinGW Compiler Suite"/> <package-group name="MinGW Standard Libraries" /> <package-group name="MinGW Add-On Libraries" /> </package-group> <package-group name="MSYS"> <package-group name="MSYS Base System" /> <package-group name="MSYS Supplementary Tools" /> <package-group name="GNU Autotools"/> </package-group> <package-group name="MinGW-Ports"> </package-group> </package-group-hierarchy> <package-collection subsystem="mingw32"> <download-host uri="http://prdownloads.sourceforge.net/mingw/%F?download" /> <!-- download-host uri="http://%M.dl.sourceforge.net/mingw/%F" mirror="kent" / --> <package name="binutils"> <description lang="en" title="The GNU Binary File Utilities"> <paragraph> This package provides the GNU assembler, linker, archive librarian, and other utilities for manipulating object format files. </paragraph> <paragraph> This is a required component of the MinGW Compiler Suite. </paragraph> </description> <affiliate group="MinGW Compiler Suite" /> <release tarname="binutils-2.19.1-mingw32-bin.tar.gz" /> <release tarname="binutils-2.19-mingw32-bin.tar.gz" status="installed" /> <release tarname="binutils-2.18.50-mingw32-alpha-bin.tar.gz" /> <release tarname="binutils-2.17.50-20060824-1-bin.tar.gz"> <download tarname="binutils-2.17.50-20060824-1.tar.gz" /> </release> </package> <package name="gcc-core" alias="gcc"> <description lang="en" title="The GNU C Compiler"> <paragraph> This package provides the MinGW implementation of the GNU C language compiler; this includes the C preprocessor, and the common back end processors which are necessary to support all other language compilers in the GNU Compiler Collection. </paragraph> <paragraph> This is a required component of the MinGW Compiler Suite. </paragraph> </description> <affiliate group="MinGW Compiler Suite" /> <requires ge="binutils-*-mingw32-bin.tar" /> <requires ge="mingw-runtime-*-mingw32-dev.tar" /> <requires ge="mingw-runtime-*-mingw32-dll.tar" /> <requires ge="w32api-*-mingw32-dev.tar" /> <release tarname="gcc-core-3.4.5-20060117-3-mingw32-bin.tar.gz" status="installed"> <download tarname="gcc-core-3.4.5-20060117-3.tar.gz" /> </release> </package> <package name="gcc-ada" alias="ada"> <affiliate group="MinGW Compiler Suite" /> <release tarname="gcc-ada-3.4.5-20060117-3-mingw32-bin.tar.gz"> <download tarname="gcc-ada-3.4.5-20060117-3.tar.gz" /> <requires eq="gcc-core-3.4.5-20060117-3-mingw32-bin.tar" /> </release> </package> <package name="gcc-g++" alias="g++ c++"> <description lang="en" title="The GNU C++ Compiler"> <paragraph> This package provides the MinGW implementation of the GNU C++ language compiler. </paragraph> <paragraph> This is an optional component of the MinGW Compiler Suite; you require it only if you wish to compile programs written in the C++ language. </paragraph> </description> <affiliate group="MinGW Compiler Suite" /> <release tarname="gcc-g++-3.4.5-20060117-3-mingw32-bin.tar.gz" status="installed"> <download tarname="gcc-g++-3.4.5-20060117-3.tar.gz" /> <requires eq="gcc-core-3.4.5-20060117-3-mingw32-bin.tar" /> </release> </package> <package name="gcc-fortran" alias="g77 f77"> <affiliate group="MinGW Compiler Suite" /> <release tarname="gcc-g77-3.4.5-20060117-3-mingw32-bin.tar.gz" status="installed"> <download tarname="gcc-g77-3.4.5-20060117-3.tar.gz" /> <requires eq="gcc-core-3.4.5-20060117-3-mingw32-bin.tar" /> </release> </package> <package name="gcc-java" alias="java"> <affiliate group="MinGW Compiler Suite" /> <release tarname="gcc-java-3.4.5-20060117-3-mingw32-bin.tar.gz"> <download tarname="gcc-java-3.4.5-20060117-3.tar.gz" /> <requires eq="gcc-core-3.4.5-20060117-3-mingw32-bin.tar" /> </release> </package> <package name="gcc-objc" alias="objc"> <affiliate group="MinGW Compiler Suite" /> <release tarname="gcc-objc-3.4.5-20060117-3-mingw32-bin.tar.gz"> <download tarname="gcc-objc-3.4.5-20060117-3.tar.gz" /> <requires eq="gcc-core-3.4.5-20060117-3-mingw32-bin.tar" /> </release> </package> <package name="mingwrt" alias="mingw-runtime"> <affiliate group="MinGW Compiler Suite" /> <affiliate group="MinGW Standard Libraries" /> <component class="dev"> <release tarname="mingwrt-3.15.2-mingw32-dev.tar.gz" /> <release tarname="mingwrt-3.15.1-mingw32-dev.tar.gz" status="installed" /> <release tarname="mingwrt-3.15-mingw32-dev.tar.gz" /> </component> <component class="dll"> <release tarname="mingwrt-3.15.2-mingw32-dll.tar.gz" /> <release tarname="mingwrt-3.15.1-mingw32-dll.tar.gz" status="installed" /> <release tarname="mingwrt-3.15-mingw32-dll.tar.gz" /> </component> </package> <package name="w32api"> <affiliate group="MinGW Compiler Suite" /> <affiliate group="MinGW Standard Libraries" /> <component class="dev"> <release tarname="w32api-3.13-mingw32-dev.tar.gz" /> <release tarname="w32api-3.12-mingw32-dev.tar.gz" status="installed" /> <release tarname="w32api-3.11-mingw32-dev.tar.gz"> <download tarname="w32api-3.11.tar.gz" /> </release> </component> </package> </package-collection> </software-distribution> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Brecht Sanders
::
Rate this Message:
>> Are [you] planning on making [mingw-get] a portable application - >> in the sense that it doesn't install in the registry, >> > > It will not touch the registry. > Please check out http://portableapps.com/ to see what I really mean. This type of portable applications have a growing number of supporters. It is esepcially useful if one would like to set up a MinGW environment e.g. on a USB harddisk that should work on any system (regardless of which driveletter the device gets in Windows). > >> uses relative paths and >> > > It will install into its own sysroot, (which may, but need not > coincide with the MinGW sysroot). > > >> can be used in multiple directories e.g. to have a MinGW 3.x and >> 4.x along side each other? >> > > It will support multiple side-by-side installations, each with its > own distinct sysroot. (Each "subsystem" will have its own distinct > sysroot; two distinct mingw32 installs could share a common MSYS, or > vice-versa). > should still allow for it to be used as a portable app I guess. > >> Any idea what kind of date you will include in it? >> In my devpaks I like to include these fields: >> - basename (e.g.: freetype2) >> - version (e.g.: 2.3.11) >> > > Much of it is encapsulated in the "canonical package name" format, > which we have adopted, as described in Chuck Wilson's document at > http://mingw.org/PackageIdentificationHOWTO > > As an example, Chris Sutcliffe's recent expat DLL package specifies: > > $ ./pkginfo.exe libexpat-2.0.1-1-mingw32-dll-1.tar.gz > Package Name: libexpat > Package Version: 2.0.1 > Package Build: 1 > Subsystem Name: mingw32 > Subsystem Version: <unspecified> > Subsystem Build: <unspecified> > Release Status: <unspecified> > Release Reference: <unspecified> > Component Type: dll > Component Version: 1 > Archive Format: tar > Compression Type gz > > (pkginfo is part of mingw-get; you'll find it in our CVS on SF). > > >> - description (e.g.: A Free, High-Quality, and Portable Font >> Engine) >> - dependancies (e.g.: zlib) >> > > Already included in the proposed XML spec; deployed as in John E's > prototype, (posted here last year). > > >> - relative path of license file (e.g.: docs/GPL.TXT) >> - license file (e.g.: GPL2) >> > > Always provided in a component package, designated as type "lic". > > >> - homepage URL (e.g.: http://freetype.sourceforge.net/) >> > > Already included in my XML prototype, but not actually utilised. > > >> - download URL containing at least latest version, preferably HTTP >> (e.g.: http://mirrors.aixtools.net/sv/freetype/) >> > > Not exactly optional, is it? Downloads won't work without this; > (mingw-get will take care of downloading what's needed). > can be downloaded. I even use this field in my setup in an automated script to scan each project's official site's download page for new versions. This allows me to get notified when a new release is out. > >> Were you considering similar fields? >> > > See my attached prototype; this isn't final, but should give you some > idea of what we have in mind. > > >> How does your hosting service work exactly, >> > > It's SF's file release system. > > which binaries I'm allowed to distribute. I guess anything (L)GPL is fine, but I'm afraid things like berkeley-db, now owned by Oracle, or even better the Oracle client itself, may be a problem. >> So you won't be able to do dependencies on minimal version numbers >> like "requires package=expat, version>=2.0.0" ? >> > > Indeed we will! A dependency of the form: > > <requires eq="foo-1.0.5-1-mingw32-dll-1.tar" /> > > depends on DLL version 1 from package "foo", built for "mingw32" with > an exact version match to "1.0.5-1"; substitute ge for eq, for an > exact or more recent version match, (or analogously for gt, lt, le); > substitute "*" for "1.0.5-1", to match any available version, or "&" > rather than "*" for identically the same version as the dependant, > (e.g. gcc-g++-3.4.5-mingw32-... depends on gcc-core-&-mingw32-...). > > >> Should the meta-XML contain some information on which >> functionality is available (e.g.: type configure flags used, or >> the output which is sometimes at the end of the configure script >> that shows what features are enabled)? >> > > I don't think that's necessary, but it could easily be accommodated, > even if not actually used for the time being. > > >> I'm not trying to make your project more complex, just handing you >> some considerations from the field ;-) >> > > It's appreciated, but let's keep it simple for now; extra features > can always be considered later. > Regards Brecht ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by keithmarshall
::
Rate this Message:
On Friday 16 October 2009 15:04:52 Brecht Sanders wrote:
> >> Are [you] planning on making [mingw-get] a portable application > >> - in the sense that it doesn't install in the registry, > > > > It will not touch the registry. > > Please check out http://portableapps.com/ to see what I really > mean. This type of portable applications have a growing number of > supporters. I'm familiar with PortableApps; setting up MinGW/MSYS as such is one of those projects I might look at one day, if I ever find some spare time to do so. > It is esepcially useful if one would like to set up a > MinGW environment e.g. on a USB harddisk that should work on any > system (regardless of which driveletter the device gets in > Windows). I thought I'd already answered that; like MinGW-GCC, mingw-get will locate its own data, and other support files, relative to its own sysroot, (i.e. wherever its executable happens to be installed). If that sysroot moves, e.g. because of a different removable device drive allocation, then the entire tree moves relatively. > >> - download URL containing at least latest version, preferably > >> HTTP (e.g.: http://mirrors.aixtools.net/sv/freetype/) > >> > > > > Not exactly optional, is it? Downloads won't work without this; > > (mingw-get will take care of downloading what's needed). > > > > Sorry, I wasn't quite clear. What I meant was where the source > tarball can be downloaded. Did you look at the sample XML package collection spec I posted? Do you see... <package-collection subsystem="mingw32"> <download-host uri="http://prdownloads.sourceforge.net/mingw/%F?download" /> ... Substitute the tarball name of any package in the package-collection for "%F", (as mingw-get will do), and you get the full download URI for that package. In what way is that not "where the source tarball can be downloaded", if a "-src" tarball is referenced? (In cases where the source tarball isn't named such that it may be immediately deduced from the other component tarnames, then a... <source tarname="foo-*-src.tar.lzma /> or similar, would be included in the package spec). > I even use this field in my setup in an automated script to scan > each project's official site's download page for new versions. > This allows me to get notified when a new release is out. Well, mingw-get will use a master XML catalogue, maintained on a server under our control, which will provide such notifications. You will do... $ mingw-get update to synchronise your local copy of the catalogue with the master; (I said it was going to look very like apt-get :-) > > It's SF's file release system. > > My only problem is that for so many libraries I'm not entirely > sure which binaries I'm allowed to distribute. You'll have to carefully check the licences of each and every one. > I guess anything (L)GPL is fine... Yes, that's a given... > but I'm afraid things like berkeley-db, now owned by Oracle, or > even better the Oracle client itself, may be a problem. Berkley-DB should be distributed under a BSD licence, which grants you the right to distribute it; I don't know if Oracle can rescind that, legitimately; (they certainly couldn't, if the original were GPL licensed, which is why I prefer that for my own code). -- Regards, Keith. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Brecht Sanders
::
Rate this Message:
>>>> - download URL containing at least latest version, preferably >>>> HTTP (e.g.: http://mirrors.aixtools.net/sv/freetype/) >>>> >>>> >>> Not exactly optional, is it? Downloads won't work without this; >>> (mingw-get will take care of downloading what's needed). >>> >>> >> Sorry, I wasn't quite clear. What I meant was where the source >> tarball can be downloaded. >> > > Did you look at the sample XML package collection spec I posted? Do > you see... > > <package-collection subsystem="mingw32"> > <download-host > uri="http://prdownloads.sourceforge.net/mingw/%F?download" > /> > ... > > Substitute the tarball name of any package in the package-collection > for "%F", (as mingw-get will do), and you get the full download URI > for that package. In what way is that not "where the source tarball > can be downloaded", if a "-src" tarball is referenced? (In cases > where the source tarball isn't named such that it may be immediately > deduced from the other component tarnames, then a... > > <source tarname="foo-*-src.tar.lzma /> > > or similar, would be included in the package spec). > library/project's download page on the homepage of the library/project itself. The reason is that this allows you to check in an automated way if the MinGW distributed version is behind on the official latest version. For example: uppose you have a distribution of libbz2 version 1.0.4 available on the MinGW site, the official project's download page (http://www.bzip.org/downloads.html) may just have released version 1.0.5. This is what I use to know which libraries have a new version I so I can build a MinGW version. It's very useful for keeping my MinGW build environment onto very recent versions of libraries. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
|
Re: GCC 4.4 on mingw
by Roger Pack
::
Rate this Message:
> Substitute the tarball name of any package in the package-collection
> for "%F", (as mingw-get will do), and you get the full download URI > for that package. In what way is that not "where the source tarball > can be downloaded", if a "-src" tarball is referenced? (In cases > where the source tarball isn't named such that it may be immediately > deduced from the other component tarnames, then a... Glad to hear that mingw-get will support source only [+local compile] downloads. I did notice that cygwin has an extensive list of source only downloads, I wonder if there were a way to leverage some of those that cross-compile out of the box [just thinking out loud]. Thanks for your work on this. -r ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ MinGW-users mailing list MinGW-users@... A: Yes. > Q: Is it really? >> A: Because the logical conversation flow is disrupted. >>> Q: Why does MinGW object to top posting? (abstracted from Larry Hall signature) This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Most annoying abuses are: 1) Top posting 2) Thread hijacking 3) HTML/MIME encoded mail 4) Improper quoting 5) Improper trimming _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
| Free embeddable forum powered by Nabble | Forum Help |
