[Mingw-w64-public] Winapi import libraries have .a instead of .dll.a
Hi. It seems that winapi libraries in \*-w64-mingw32\lib have extensions of .a instead of .dll.a (which I would expect since they're DLL import libraries). Could this be changed for the sake of consistency? Is there a reason not to? -- David Macek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Website update continued
On 1. 5. 2015 16:15, Adrien Nader wrote: What's left is moving and updating the documentation that is still on the wiki2 stuff on Sourceforge (*hint* *hint*). What are the requirements for the migration? Is it enough to copy (and re-format) the current revisions, or should history and authorship be migrated as well? I searched for a way to do this automatically (seeing there's at least 100 pages), but I only found https://github.com/primordial-soup/sourceforge-wiki-export and I can't get it to work. Is it possible for people someone with admin access to SF to get a dump of the wiki? Is https://sourceforge.net/p/forge/community-docs/Migrating%20MediaWiki%20from%20Hosted%20Apps/ related? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCC 5.1/5.1.1 related bootstrap failures
On 11. 5. 2015 13:52, Matt Breedlove wrote: Also, I'm experiencing a currently unresolved issue building gcc 5.1/5.1.1 natively for i686 using dw2 exceptions resulting in it failing out with the following during stage1 libgcc: M:\\msys64\\build\\staging\\mingw-w64-i686-gcc5\\src\\build-i686-w64-mingw32\\i686-w64-mingw32\\libgcc/../../../gcc-5.1.1/libgcc/libgcc2.c:2240: undefined reference to `__EH_FRAME_BEGIN__' __main_s.o: In function `_do_global_ctors': M:\\msys64\\build\\staging\\mingw-w64-i686-gcc5\\src\\build-i686-w64-mingw32\\i686-w64-mingw32\\libgcc/../../../gcc-5.1.1/libgcc/libgcc2.c:2256: undefined reference to `__EH_FRAME_BEGIN__' collect2.exe: error: ld returned 1 exit status Makefile:947: recipe for target 'libgcc_s.dll' failed I'm less experienced with this type of issue so if anyone could give me some guidance on this before I report the issue, it would be greatly appreciated. The issue does not come up unless --disable-sjlj-exceptions is specified during configuration. This didn't occur under 4.9.2 and appears new to 5.1. Full build logs for libgcc found here: http://pastebin.com/xMnZxmbs I mainly just want to try and eliminate other possible causes before creating a bug for it though the same configuration builds fine for gcc 4.9.2. Just wanted to note that -- according to my observations on IRC and MLs -- others are hitting the same issue with i686/dw2. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] fork: can't reserve memory for stack 0xA0000 - 0x2A0000, Win32
On 7. 5. 2015 22:03, James Franco wrote: When I attempt to install Msys2 from the download link you suggested http://sourceforge.net/projects/msys2/?source=directory I get the error message The program cant start because MSVCR90.dll is missing from your computer. Try reinstalling the program to fix this problem After pressing ok i am prompted to the installation menu. Is this something that I should be concerned about ? I wonder what program is that. Nothing in MSYS2 should depend on msvcr90.dll and I can't think of a good hypothesis why the installer would start any program that does depend on msvcr90.dll. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] sbuild update - 6.0
Hi. On 30. 3. 2015 20:22, LRN wrote: A python2-utf8.sh startup script in /etc/profile.d forces Python to use UTF-8 encoding. I'm still unsure whether this will have any adverse effects. A matching change to console codepage (chcp 65001) was planned, but was disabled at the last moment, since it caused Python to error-out on write() to console. Have you tried setting PYTHONIOENCODING? https://docs.python.org/3/using/cmdline.html#envvar-PYTHONIOENCODING -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
On 24. 3. 2015 21:20, Adrien Nader wrote: Following Vincent Torri's mail, I did some changes this morning and I just noticed I had not done these changes for every block but only for the ones that fell under Windows and Linux tabs. I've now corrected it. Basically I've removed title elements and added blue-colored blocks instead. They should make it easier to tell each block apart. Can you check the page again and tell me if it looks better? Yeah, it looks well separated now. I know Arch Linux users are generally competent, but I'd like to see the link point to something actually related to mingw-w64, rather than just to AUR homepage. This may be a good link: https://aur.archlinux.org/packages/?SeB=nK=mingw-w64SB=cPP=250 I'm not an Arch Linux user and the link in place was the only one I had. I've updated the page, thanks. Also, wouldn't it be better to also mention the packages in official Arch repos? https://www.archlinux.org/packages/?q=mingw-w64 They don't seem outdated or anything. I wasn't aware of these packages (maybe they're newer than the arch-linux-related update). I'm not sure how they relate to AUR ones; I'm under the impression the toolchain is in the base and non-toolchain packages should be built from AUR but I need a confirmation from at least one actual user. Unfortunately, I can't help here. I checked the package lists though and the two repositories are complements. Community repo has the basics (gcc, binutils, crt, headers...), and AUR has the rest plus trunk versions of _some_ of the basic packages. T === Downloads/Windows: Mentioning Cygwin while omitting MSYS2 seems weird, given the numbers of packages they provide. I'm definitely in favor of mentioning MSYS2 in this tab. Is there a reason Cygwin is first in this list? Jonathan gave me the relevant information and, to the best of my knowledge, it is still (mostly) correct. There's an additional reason: I'm seeing cygwin similarly to fedora/opensuse/arch. If someone is already using these, the entries on the website will make him check his version requirements and look at his distro package manager. They probably won't make anyone start using these distros however. Some distros have recent versions, some don't (debian, ubuntu) and I believe this page can help the user by providing something simple to read. I think the situation of choosing an _application package_ on Windows is different from the one of choosing a whole _operating system_. I'm not arguing against the presence of Cygwin, though. MSYS2 is different in that there's a lot more to say. I also don't want to make all the content myself and had had no actual feedback on that front before. I hope MSYS2 makes it there eventually. Cygwin is first because the lists are sorted alphabetically. I don't think I want to start changing that. Sounds reasonable. === Overall, the website looks very good IMO. Good to hear. :) I noticed some typos and weird sentences in some places; should I also note them here on the ML? I can either create you an account on the wiki or you can send me the list of things to change and I'll review and apply. Donate: Mingw-w64 is almost entirely made by volunteer. (- volunteers) Contribute: Check CC's page on contributing. (- GCC's) Contribute, the last heading seems to lack a description. I think that's all. Cheers. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
On 20. 3. 2015 22:51, Adrien Nader wrote: Hi, I've just pushed a redirect from http://mingw-w64.sourceforge.net to http://mingw-w64.yaxm.org in order to serve a new website. [snip] Any constructive criticism is welcome; don't hesitate. Hi. I took a look on the website and I've got some notes which may or may not be applicable to other visitors: === Downloads/Others: The first paragraph in the tab talks about OS X builds straight away, as if Others == OSX. This also led to an impression that Rubenv's builds are also for OS X. Also most of the contents of the tab seems to belong to other tabs. I imagine that if a visitor was interested only in toolchains for Windows, he/she could be led to believe that the three options in the first tab were the only one, because he/she would never even look at the Others tab and discovered the link to SF.net file repository. The following organisation would make more sense to me: I propose 1) moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or completely outside of them), and 4) renaming the tab from Other to OS X. I don't think moving these mentions from the Others tab to the other tabs will confuse users as to which one to download, as the gray boxes with logos serve well to make their contents seem as more trust-worthy than the plain text around. === Downloads/Source: This may be just my profession talking, but links to various stuff on SF.net with SourceForge as the title seem misleading. === Downloads/Linux: I know Arch Linux users are generally competent, but I'd like to see the link point to something actually related to mingw-w64, rather than just to AUR homepage. This may be a good link: https://aur.archlinux.org/packages/?SeB=nK=mingw-w64SB=cPP=250 Also, wouldn't it be better to also mention the packages in official Arch repos? https://www.archlinux.org/packages/?q=mingw-w64 They don't seem outdated or anything. === Downloads/Windows: Mentioning Cygwin while omitting MSYS2 seems weird, given the numbers of packages they provide. I'm definitely in favor of mentioning MSYS2 in this tab. Is there a reason Cygwin is first in this list? === Overall, the website looks very good IMO. I noticed some typos and weird sentences in some places; should I also note them here on the ML? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] completely lost building/linking DLLs
On 2. 3. 2015 15:25, David Rysdam wrote: I'm lost. Is there a tutorial for this? Try looking at these two, which seem to be still up to date: http://www.mingw.org/wiki/createimportlibraries http://www.mingw.org/wiki/sampledll I think mingw should generally look for .a files (not .lib), specifically .dll.a. in case of DLL link stubs. Hopefully this will help you. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Patch] - Hardening libssp against malicious local processes
On 3. 2. 2015 11:53, Georg Koppen wrote: I am putting a patch inline (not sure if attachments are allowed on this mailing list) that does not make it possible for a local process anymore to replace canaries which in turn might disable SSP. Comments and/or review are much appreciated. The problem it is trying to solve is outlined in https://trac.torproject.org/13169#comment:4: (Quoting a cypherpunk) In Windows you can to create any directories for any disks(C:, D:, .. Z:), only system directories (Windows directory, Program files, etc) are protected. Any process with privileges of any standard user can to create C:\dev\urandom file and to fill it by any stuff. Hi. This is maybe off-topic, but I'd like to point out that ACLs can be customized, so any assumption of this kind can be wrong. Also, the motivation for this patch should be don't use /dev/urandom on Windows, because it's not a thing, not someone could supply fake random data to us. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How to recognize symlinks in WIN32?
On 15. 1. 2015 4:11, Greg Jung wrote: Yes I've seen that, if my second post appeared, the symlinks created with cygwin are the ones giving me trouble. These links are invisible to CMD.exe, by someone's design: CYGWIN- created links in Directory of e:\cygwin64\lib\nox 03/31/2014 09:39 AMDIR . 03/31/2014 09:39 AMDIR .. 07/01/2013 03:24 AM 336,710 libXpm-noX.a 07/01/2013 03:24 AM43,690 libXpm-noX.dll.a 2 File(s)380,400 bytes 2 Dir(s) 85,657,726,976 bytes free I think these are cygwin emulated symlinks: They are visible, just not by default. I suspect they are marked with the system attribute. Use dir /as to show them. You should see a small size (in order of tens of bytes). You can instruct cygwin to create native NTFS symlinks, but due to a different design, there are some restrictions. See this: https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks So the question becomes, why do cygwin symlinks look different, and how can a user program detect this attribute? I assume you could detect them using cygwin *stat calls. Maybe by compiling against cygwin headers and cygwin1.dll, or maybe by extracting the relevant code from cygwin sources (you'd have to check the relevant licenses). -- David Macek smime.p7s Description: S/MIME Cryptographic Signature -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] any all-in-one Mingw-w64 to build GIMP 32/64?
On 18. 12. 2014 18:17, oyster wrote: Hi, everyone I want to compile GIMP 32 bits/64 bits on my Win7 64-bits. However I found this is too difficult. I have spend 3 days to install/update msys, mingw-64, and kinds of libraries. Even though I am stuck by gexiv2 now. I got too tired to search, download, modify, autogen.sh, configure and make. Can any one supply an all-in-one Mingw-w64, which is running on Win7 64bits, has git to clone new gimp, can build 32bits and 64bits GIMP for Windows? Hi. Try MSYS2. They have some patches and a script for building GIMP. See: http://msys2.github.io/ http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/ https://github.com/alexpux/mingw-packages/tree/master/mingw-w64-gimp -- David Macek -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] why isn't UINT64_MAX usable when countdown reaches past 0 to -1?
On 18. 12. 2014 21:35, Jim Michaels wrote:
dongshengdaily 5.0.0 20141105
#if defined(_WIN64)
for (i=src.size()-1-findStr.size(); i=pos pos!=UINT64_MAX; i--) {
#else
for (i=src.size()-1-findStr.size(); i=pos pos!=UINT32_MAX; i--) {
#endif
std::cerri=i, findStrSizeDiv2=findStrSizeDiv2,
findStrSizeMod2=findStrSizeMod2std::endl;
i=0, findStrSizeDiv2=3, findStrSizeMod2=1
j=0, srcNarrowingRHS=0, srcNarrowingLHS=18446744073709551611,
fsNarrowingRHS=6, fsNa
HS]=ÿ, src[srcNarrowingRHS]=g
i=18446744073709551615, findStrSizeDiv2=3, findStrSizeMod2=1
j=0, srcNarrowingRHS=18446744073709551615,
srcNarrowingLHS=18446744073709551610, fsN
, src[srcNarrowingLHS]=ÿ, src[srcNarrowingRHS]=...
notice i. the loop didn't stop. I corrected the improper value for
UINT64_MAX, but this did not fix the problem.
You are only comparing pos with UINTxx_MAX, not i. If pos is 0, then the
loop won't stop.
--
David Macek
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DWORD_PTR implemented as long long unsigned int
On 18. 12. 2014 21:16, Jim Michaels wrote: using the code idea for FORMAT_MESSAGE_ARGUMENT_ARRAY: http://msdn.microsoft.com/en-us/library/windows/desktop/ms679351%28v=vs.85%29.aspx it says va_list in this case is a * to array of DWORD_PTR. so what exactly is a DWORD_PTR? I had assumed it was a pointer, that you need to cast, and microsoft somehow did a sloppy or erroneous job of documenting or something. Short answer: It's like uintptr_t. Long answer: According to the first example, I'd say that DWORD_PTR in this situation is kind of equivalent to (void*), i.e. a placeholder type for when the type is not known beforehand. In comparison to other possible placeholder types, DWORD_PTR and (void*) both have the the advantage of being large enough to safely contain any pointer (e.g. string), so unless you want to pass a (long long int) to the function on a 32-bit system, it should be able to contain any allowed parameter. because in the past, _PTR has always been defined as a * (pointer) to whatever, like DWORD*. who changed the definition of the word pointer? :-( in c++ it's a nice and solid def. I can't say how _PTR types were defined in the past, I'm not very familiar with WINAPI. -- David Macek -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] any reason why stack overflow just calling plain function?
On 15. 12. 2014 22:03, Jim Michaels wrote:
it's when I do:
char line[LINEBUFSIZE];
where LINEBUFSIZE is 8388608
Yes, this is the problem. There is a limit on how much memory you can allocate
in this way (in contrast to new and malloc) and it depends on the size of
the stack. The default stack size with mingw-w64 on Windows should be around 2
MiB. You can change the stack size using a linker option, like this:
g++ -Wl,--stack,839 test.cpp -o test
I think you should rather change the function to use heap allocation ( char
*line = new char[LINEBUFSIZE]; ...; free(line); ), or better yet, use
std::string or something else that expands automatically -- that way you don't
have to set a limit for the length of the line.
Next time, try to reduce your example source even more (according to SSCCE)
when asking for help, more people will be inclined to help you. One possible
example source would be this one:
---START OF SOURCE---
#include iostream
void fn() {
std::cout enter fn std::endl;
std::cout.flush();
char buffer[8388608];
// make sure that the variable is not 'unused':
std::cout leave fn ( (int)buffer[0] ) std::endl;
std::cout.flush();
}
int main() {
std::cout enter main std::endl;
std::cout.flush();
fn();
std::cout leave main std::endl;
std::cout.flush();
return 0;
}
---END OF SOURCE---
Notice that even when enter fn is before the line declaring buffer, it is
not printed, because the allocation happens right after entering fn.
--
David Macek
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DWORD_PTR implemented as long long unsigned int
On 16. 12. 2014 13:19, Ruben Van Boxem wrote:
2014-12-16 9:56 GMT+01:00 Jim Michaels jmich...@yahoo.com
mailto:jmich...@yahoo.com:
usually, any microsoft _PTR is a *, but DWORD_PTR is defined as long long
unsigned int.
winerrstr.cpp:83:24: error: invalid conversion from 'DWORD* {aka long
unsigned int*}' to 'DWORD_PTR {aka long long unsigned int}' [-fpermissive]
DWORD_PTR *dwpArray;
dwpArray=(DWORD_PTR*)new DWORD_PTR[argc+1];
Please see this link for the definitions of all Windows types:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751.aspx
I think PDWORD (and other P-types) is what you're looking for.
--
David Macek
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] any reason why stack overflow just calling plain function?
On 14. 12. 2014 1:11, Jim Michaels wrote: 1st line of function is std::cerrsometextstd::endl but it never gets executed, I get stack overflow crash before this gets shown. why is this? Can you post a compilable small example that still crashes (http://sscce.org/)? (Preferably not inside an email, but onto a paste site.) As to the reason of the error, do you allocate a big array somewhere in the function? -- David Macek -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
