[Mingw-w64-public] wcschr etc. problem
Hi Everyone
I can't build the popular build program ninja with clang++ and mingw.
The reason is demonstrated by this simple program:
// wcx.cpp
#include string
using namespace std;
#include windows.h
int main()
{
wchar_t* p = wcschr(Lhello, L'h');
}
Compiling this program with g++ yields the same problem, all the errors are
below, results from clang++ are included too.
g++ -std=c++1y -I/libcxx/include -nostdinc++ wcx.cpp
If ninja didn't put a using namespace std; in it's includes, the problem
would go away, but it does, and in over a year I've had no luck convincing
them not to put using namespaces in headers and when I mentioned it a year
ago here it didn't attract any interest.
On the ninja maintainers side, it is legal, so why should they change it,
and who knows what other programs break because it doesn't work.
So my question is, will mingw be changed to make this program compile by
default?
If there is a fix, where (actual link please) can I get it?
I'm using a mingw I got here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/seh/x86_64-4.9.0-release-win32-seh-rt_v3-rev0.7z/download
It'd be nice if someone actually tried this. Everything you need is listed
to reproduce the problem: Binaries, test case, compile command lines.
ninja source is available too so you can even download that, not that you
need it, the test case demonstrates the problem.
Also, regarding my earlier post, could someone tell me explicitly what the
procedure would be to either get the latest trunk mingw to apply to the
build linked above if that's what I'm supposed to do, or where a more
recent version of that is that fixes that problem so I can download that?
I find navigating the various personal builds/mingw builds tree very
confusing.
Whatever I download is always old whenever I try to discuss anything on
here. Nobody links to anything concrete in their replies.
I'm not an expert in mingw and I always find I'm chasing my tail most of
the time on this forum to get replies that I can actually do anything with,
despite attempts from people to help, and that's regardless of however much
info I provide.
Hopefully this time will be different.
Error output follows.
Thanks
In file included from /libcxx/include/memory:607:0,
from /libcxx/include/algorithm:628,
from /libcxx/include/string:439,
from wcx.cpp:1:
/libcxx/include/tuple:291:72: error: 'constexpr const _Hp
std::__1::__tuple_leaf_Ip, _Hp, anonymous ::get() const' ca
nnot be overloaded
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const _Hp
get() const _NOEXCEPT {return value;}
^
/libcxx/include/tuple:290:72: error: with 'constexpr _Hp
std::__1::__tuple_leaf_Ip, _Hp, anonymous ::get() const'
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 _Hp
get() _NOEXCEPT {return value;}
^
In file included from /libcxx/include/memory:607:0,
from /libcxx/include/algorithm:628,
from /libcxx/include/string:439,
from wcx.cpp:1:
/libcxx/include/tuple:357:72: error: 'constexpr const _Hp
std::__1::__tuple_leaf_Ip, _Hp, true::get() const' cannot be
overloaded
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const _Hp
get() const _NOEXCEPT {return static_castconst _H
p(*this);}
^
In file included from /libcxx/include/memory:607:0,
from /libcxx/include/algorithm:628,
from /libcxx/include/string:439,
from wcx.cpp:1:
/libcxx/include/tuple:356:72: error: with 'constexpr _Hp
std::__1::__tuple_leaf_Ip, _Hp, true::get() const'
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 _Hp
get() _NOEXCEPT {return static_cast_Hp(*t
his);}
^
In file included from /libcxx/include/memory:607:0,
from /libcxx/include/algorithm:628,
from /libcxx/include/string:439,
from wcx.cpp:1:
/libcxx/include/tuple: In function 'constexpr std::__1::tuple
std::__1::tuple_cat()':
/libcxx/include/tuple:996:1: error: invalid return type 'std::__1::tuple'
of constexpr function 'constexpr std::__1::tup
le std::__1::tuple_cat()'
tuple_cat()
^
/libcxx/include/tuple:674:29: note: 'std::__1::tuple' is not literal
because:
class _LIBCPP_TYPE_VIS_ONLY tuple
^
/libcxx/include/tuple:674:29: note: 'std::__1::tuple' is not an
aggregate, does not have a trivial default constructor
, and has no constexpr constructor that is not a copy or move constructor
wcx.cpp: In function 'int main()':
wcx.cpp:6:39: error: call of overloaded 'wcschr(const wchar_t [6],
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
2014-04-29 8:49 GMT+02:00 Rodny spillig...@gmx.com: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? The better question you should ask yourself is: why is the open source world changing? I'm not going to sum up the pro's and cons, you can find them yourself. git is just a lot more flexible and robust. This does not make it any better than any other distributed VCS, it just makes it better (i.e. more flexible) than stuff like CVS/SVN/... Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) You are aware that a) TortoiseGit exists? Along with a bunch of other graphical clients b) Visual Studio 2013 has native git integration? I'd hardly say git doesn't work on Windows... Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Google git for subversion users. There's a ton of migration help for you and everyone. There are no hard numbered revisions, instead, there's branches and tags and commit hashes, which offer the same flexibility. There are things like a shallow clone (see git clone --depth=N), which allows you to checkout the latest N commits. Note a git clone is often smaller than the equivalent svn checkout, because git compacts the commit history quite efficiently. See the previous mails about repo sizes. How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. I'm sorry to say this, but git (or any other distributed VCS) isn't just the latest bandwagon. There's a reason github is so popular. There's a reason more than half (watch me pull statistics out of nowhere) of major open source projects are
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 11:49 PM, Rodny spillig...@gmx.com wrote: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. Sorry, I am replying only because you've written your email in a way you must have realized was near guaranteed to start a flame war, which is very unlikely to be useful. There was a time, maybe 5 years ago, when it was common to assert that git was a fad and subversion was fine, but you must have noticed that that conversation died off a long time ago. I assume that you haven't used git or mercurial on a project with many distributed developers. For some reason it is very difficult to explain in the abstract why DVCS is so much better in this situation than centralized one-commit systems like svn. It only becomes clear after using these systems for a while. In case it is helpful, there's a very good explanation by Joel Spolsky (for mercurial) here: http://hginit.com/00.html See also Distributed Version Control is here to stay, baby http://www.joelonsoftware.com/items/2010/03/17.html Best, Matthew -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Rodny writes: Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Take git extensions for a spin: https://code.google.com/p/gitextensions/ -- Alberto -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.04.2014 11:31, Ruben Van Boxem wrote: On 2014-04-29 8:49 GMT+02:00 Rodny: JonY writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Google git for subversion users. There's a ton of migration help for you and everyone. There are no hard numbered revisions, instead, there's branches and tags and commit hashes, which offer the same flexibility. There are things like a shallow clone (see git clone --depth=N), which allows you to checkout the latest N commits. Note a git clone is often smaller than the equivalent svn checkout, because git compacts the commit history quite efficiently. See the previous mails about repo sizes. He's right on this one. Just yesterday i was frustrated when i couldn't download a *particular* revision of binutils to build. Shallow clones, as mentioned, give you HEAD or something near HEAD or a tagged commit. Usually i work around it by abusing the snapshot feature of a particular repo, but sourceware had that disabled. AND their snapshot tarballs on ftp are rolling (meaning i can't just download a particular snapshot that way either, they change over time). That said, this just breaks the use-case when you have to work with a particular revision of upstream for the first time. If you need a tag or the HEAD - it's fine, since shallow clones help. If you've done this before - also fine, since you have the repo clone, and just need to update and checkout to the commit you need. And since we're speaking of revisions, for the record, it should be possible to emulate incremental revision numbers in git, as long as master is kept linear. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTX2V5AAoJEOs4Jb6SI2CwMskIANtdlBEP1cTmVOL8lDzjJohx 3Mb2Ah+z2BSn2TTh96R/N2pag15uje6YmRkGJRRTUlv03jI4XTn50sj0AJyFNWko SskOxkBUbivKIP7k9qJFTAyvMpsf4n9hHAuE/PJ7QjBySBXwZsmxP7F8u7Tarh9E QqHcbrh4W+AFYQFNqRqQVHFyBg4zLPbPLIPOQZhiMp7qecSsPAOm2L5UG2AxPh+K /YlBadG1DsP0qaSCiiz9Fhg2ijvWMii0U2cehrG9dgUmzrGiCuQZNiw2NF34YPnm A7iJUPSKxsb6h23y0wATiK3p5X5R+yTwOE259oX2n81bnoQ0QUljr0VOX37iO+M= =JZOG -END PGP SIGNATURE- -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/29/2014 14:49, Rodny wrote: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Because it was a pain to track down patches applied to other branches and reapply it again and again, cherry-pick is god sent. Not to mention merging is quick and simple. It is also far far easier to do a long term private branch in git than in SVN, not to mention, multi-part commit patches are nice. Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) TortoiseGit. And no, you are not expected to work using Windows tools just because it is for Windows. You'd be surprised to learn most of the changes are not done on Windows at all. Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Just grab it once (or use a local cache) and then checkout the revision you want. How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Already mentioned in the original email. Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. What does Linus have to do with the decision? If anything, I'll use it because Linus recommends it. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? Because git commits cannot easily push back to SVN, and great, you have all the power of git and the inconvenience of SVN. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] How to do delay load in Mingw-w64
Hi friends, I'm now moving my ffmpeg build from MinGW to Mingw-w64 because the latter supports delay load. To be a bit more specific, ffmpeg could dynamically link to many external libraries, but I want these external libs be downloaded and used only when they are used (functions called). For example, there'a libspeex for which I configured with ./configure --enable-static=no --prefix=/mingw, so these files are generated libspeex-1.dll, libspeex.dll.a libspeex.la. According to this article http://mingw-users.1079350.n2.nabble.com/Delayloading-windows-libraries-Finally-the-real-deal-td7472183.html, what I need to do is: 1. gendef libspeex-1.dll to get the libspeex-1.def 2. dlltool --def libspeex-1.def --output-delaylib libspeex.dll.a so the old libspeex.dll.a is replaced by the newly generated one, and 'make install' will install header files and all lib files into mingw folder. But what I want to know is, what's the libspeex.la ? Should I also regenerate it or just install the old ones? Great thanks -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ 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 do delay load in Mingw-w64
0) http://stackoverflow.com/questions/1238035/what-is-libtools-la-file-for 1) Practically, I don't think .la files are useful on Windows. Neither do .dll.a files. -- Best regards, lh_mouse 2014-04-29 - 发件人：YIRAN LI mrfun.ch...@gmail.com 发送日期：2014-04-29 18:34 收件人：mingw-w64-public 抄送： 主题：[Mingw-w64-public] How to do delay load in Mingw-w64 Hi friends, I'm now moving my ffmpeg build from MinGW to Mingw-w64 because the latter supports delay load. To be a bit more specific, ffmpeg could dynamically link to many external libraries, but I want these external libs be downloaded and used only when they are used (functions called). For example, there'a libspeex for which I configured with ./configure --enable-static=no --prefix=/mingw, so these files are generated libspeex-1.dll, libspeex.dll.a libspeex.la. According to this article http://mingw-users.1079350.n2.nabble.com/Delayloading-windows-libraries-Finally-the-real-deal-td7472183.html, what I need to do is: 1. gendef libspeex-1.dll to get the libspeex-1.def 2. dlltool --def libspeex-1.def --output-delaylib libspeex.dll.a so the old libspeex.dll.a is replaced by the newly generated one, and 'make install' will install header files and all lib files into mingw folder. But what I want to know is, what's the libspeex.la ? Should I also regenerate it or just install the old ones? Great thanks -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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 do delay load in Mingw-w64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.04.2014 14:34, YIRAN LI wrote:
Hi friends,
I'm now moving my ffmpeg build from MinGW to Mingw-w64 because the latter
supports delay load. To be a bit more specific, ffmpeg could dynamically
link to many external libraries, but I want these external libs be
downloaded and used only when they are used (functions called).
For example, there'a libspeex for which I configured with ./configure
--enable-static=no --prefix=/mingw, so these files are generated
libspeex-1.dll, libspeex.dll.a libspeex.la.
According to this article
http://mingw-users.1079350.n2.nabble.com/Delayloading-windows-
libraries-Finally-the-real-deal-td7472183.html,
what I need to do is:
1. gendef libspeex-1.dll to get the libspeex-1.def 2. dlltool --def
libspeex-1.def --output-delaylib libspeex.dll.a
so the old libspeex.dll.a is replaced by the newly generated one, and
'make install' will install header files and all lib files into mingw
folder.
A more elegant (or braindead, YMMV) solution is to hack configure.ac of the
package in question and add this for *-*-mingw* hosts:
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -o
$output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --output-def
- -Xlinker $lib.def $DLLTOOL --dllname $soname --def $lib.def
- --output-delaylib $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds='if test x`$SED 1q $export_symbols` = xEXPORTS; then
cp $export_symbols $output_objdir/$soname.def;
else
echo EXPORTS $output_objdir/$soname.def;
cat $export_symbols $output_objdir/$soname.def;
fi~
$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o
$output_objdir/$soname ${wl}--enable-auto-image-base;
$DLLTOOL --dllname $soname --def $output_objdir/$soname.def --output-delaylib
$lib'
This code is a verbatim copy of libtool that is patched to create a
delay-load import library instead of the normal import library. This takes
advantage of the fact that libtool does have a .def file at hand already, and
thus there's no need to call gendef.
But what I want to know is, what's the libspeex.la ? Should I also
regenerate it or just install the old ones?
.la files are libtool helpers.
IMO they are useful (roughly as useful as libtool itself) when you build a
package, and Makefile.am files SHOULD refer to .la files by name when needing
to link to a library produced within the same package.
However, they are a hindrance when linking package libraries from outside (as
they remember all kinds of nasty details, absolute paths and such). Therefore
i strongly recommend against installing .la files (i routinely purge anything
a package installs, looking for .la files and deleting them with extreme
prejudice). dll.a import (with or without delay-loading) libraries in
/mingw/lib should be enough (and for anything more complex there's pkgconfig).
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJTX4+cAAoJEOs4Jb6SI2CwMLsIAMGDB4a1QWb0RO7A4OrjF0XX
S00vzJcKV3cY+S5iN4SIlgJSxqyXEAq79DjYzVCvtMvNyY0RhVDvmFxU5rPCFtNU
N5fDTEEdeya/z08zIzfENIrCRRH70yYskKYWDJXlqCxXOBVfozaPOFawJEoEMd6x
1DXCkvVO6ivlSfPM/qMwTSRJbFHAp3Ia+MyicFtxmXZK2bJ6KRMdJU2G2Ntei+xG
MWpc6zud6sLjqTweeWEzdod2ThEY6/o9TR+0Z12JR2sFeTfSaUDEpGEq6Wsi+poP
maVZk/qb3yKZT8iy+zTPWRnvvl90ZQJbAFT/9Ckrgmq+wfev8GKarUnGG9VI6DI=
=2L2j
-END PGP SIGNATURE-
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
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 do delay load in Mingw-w64
On Tue, Apr 29, 2014, LRN wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.04.2014 14:34, YIRAN LI wrote:
Hi friends,
I'm now moving my ffmpeg build from MinGW to Mingw-w64 because the latter
supports delay load. To be a bit more specific, ffmpeg could dynamically
link to many external libraries, but I want these external libs be
downloaded and used only when they are used (functions called).
For example, there'a libspeex for which I configured with ./configure
--enable-static=no --prefix=/mingw, so these files are generated
libspeex-1.dll, libspeex.dll.a libspeex.la.
According to this article
http://mingw-users.1079350.n2.nabble.com/Delayloading-windows-
libraries-Finally-the-real-deal-td7472183.html,
what I need to do is:
1. gendef libspeex-1.dll to get the libspeex-1.def 2. dlltool --def
libspeex-1.def --output-delaylib libspeex.dll.a
so the old libspeex.dll.a is replaced by the newly generated one, and
'make install' will install header files and all lib files into mingw
folder.
A more elegant (or braindead, YMMV) solution is to hack configure.ac of the
package in question and add this for *-*-mingw* hosts:
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -o
$output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --output-def
- -Xlinker $lib.def $DLLTOOL --dllname $soname --def $lib.def
- --output-delaylib $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds='if test x`$SED 1q $export_symbols` = xEXPORTS; then
cp $export_symbols $output_objdir/$soname.def;
else
echo EXPORTS $output_objdir/$soname.def;
cat $export_symbols $output_objdir/$soname.def;
fi~
$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o
$output_objdir/$soname ${wl}--enable-auto-image-base;
$DLLTOOL --dllname $soname --def $output_objdir/$soname.def --output-delaylib
$lib'
This code is a verbatim copy of libtool that is patched to create a
delay-load import library instead of the normal import library. This takes
advantage of the fact that libtool does have a .def file at hand already, and
thus there's no need to call gendef.
But what I want to know is, what's the libspeex.la ? Should I also
regenerate it or just install the old ones?
.la files are libtool helpers.
IMO they are useful (roughly as useful as libtool itself) when you build a
package, and Makefile.am files SHOULD refer to .la files by name when needing
to link to a library produced within the same package.
However, they are a hindrance when linking package libraries from outside (as
they remember all kinds of nasty details, absolute paths and such). Therefore
i strongly recommend against installing .la files (i routinely purge anything
a package installs, looking for .la files and deleting them with extreme
prejudice). dll.a import (with or without delay-loading) libraries in
/mingw/lib should be enough (and for anything more complex there's pkgconfig).
Yes, more and more software distribution are moving further and further
away from .la files. It would be good to not add new dependencies to
libtool.
--
Adrien Nader
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Unattended install with mingw-builds-install.exe
niXman i.nixman@... writes: 2013/9/20 Martin Fiers: Can we know what's the installer type (like, msi, installshield, inno...). CreateInstall: http://www.createinstall.com/ Hi niXman, 1) Can you please provide the script .ci used to build mingw-install.exe 2) In the current state, is that it is possible that CreateInstall allow to add another URL repository.txt file as argument? for example: mingw-intall.exe -url=another-local-repository.txt 3) You do not know a free alternative that would make a similar installation? Thanks and Regards, Paul -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Advice on accuracy of exp function
Hi, I'm sorry to ask this question without more information, but I'm hoping you can give me an idea what more information I need. Some of us got very interested in using Mingw-w64 as the standard compiler for Python numerical tools such as numpy and scipy: https://github.com/numpy/numpy/wiki http://www.mail-archive.com/numpy-discussion@scipy.org/msg44967.html One question that came up was the accuracy of the mingw exp function: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44950.html I believe this is implemented here: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/math/exp.def.h It looks as if this implementation is slightly less accurate than other implementations on OSX and Linux: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44987.html Specifically, the Linux implementation achieves 100% floating point accuracy, whereas the Mingw-w64 implementation gets about 80% of values exactly (floating point) correct, with the remainder off by one unit at the last place (ULP). I writing to ask whether I should investigate this further to see if another implementation would give better accuracy for similar speed. Or do y'all consider the current accuracy good enough? Cheers, Matthew -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Advice on accuracy of exp function
2014-04-29 21:16 GMT+02:00 Matthew Brett matthew.br...@gmail.com: Hi, I'm sorry to ask this question without more information, but I'm hoping you can give me an idea what more information I need. Some of us got very interested in using Mingw-w64 as the standard compiler for Python numerical tools such as numpy and scipy: https://github.com/numpy/numpy/wiki http://www.mail-archive.com/numpy-discussion@scipy.org/msg44967.html One question that came up was the accuracy of the mingw exp function: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44950.html I believe this is implemented here: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/math/exp.def.h It looks as if this implementation is slightly less accurate than other implementations on OSX and Linux: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44987.html Specifically, the Linux implementation achieves 100% floating point accuracy, whereas the Mingw-w64 implementation gets about 80% of values exactly (floating point) correct, with the remainder off by one unit at the last place (ULP). Hmm, well, we use here variant provided by netbsd. This 1 ULP thing isn't necessarily an inaccuracy in general. Mostly it might be either an issue of rounding, or of method you use to display them. If you want more accurate value-print I would recommment to use the __mingw_(printf) functions instead of the MS-C-runtime one. Issue here is that values by MS-printf getting rounded different (and sometimes inaccurate). I writing to ask whether I should investigate this further to see if another implementation would give better accuracy for similar speed. Or do y'all consider the current accuracy good enough? Of course we are interested in approving our math accuracy. It would be great to improve it. Nevertheless keep please in mind that not all licenses (and so not all implementations) are acceptable for us. And for such patches some testcases would be important, too. Another pretty important thing here is also the calculation-performance. Another interesting aspect of current implementation would be to make calculation table-based without use of x87-FPU instructions (especially for x64). Cheers, Matthew Cheers, Kai -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Advice on accuracy of exp function
Hi, On Tue, Apr 29, 2014 at 2:08 PM, Kai Tietz ktiet...@googlemail.com wrote: 2014-04-29 21:16 GMT+02:00 Matthew Brett matthew.br...@gmail.com: Hi, I'm sorry to ask this question without more information, but I'm hoping you can give me an idea what more information I need. Some of us got very interested in using Mingw-w64 as the standard compiler for Python numerical tools such as numpy and scipy: https://github.com/numpy/numpy/wiki http://www.mail-archive.com/numpy-discussion@scipy.org/msg44967.html One question that came up was the accuracy of the mingw exp function: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44950.html I believe this is implemented here: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/math/exp.def.h It looks as if this implementation is slightly less accurate than other implementations on OSX and Linux: http://www.mail-archive.com/numpy-discussion@scipy.org/msg44987.html Specifically, the Linux implementation achieves 100% floating point accuracy, whereas the Mingw-w64 implementation gets about 80% of values exactly (floating point) correct, with the remainder off by one unit at the last place (ULP). Hmm, well, we use here variant provided by netbsd. Just to check - you mean the Mingw-w64 assembly should give identical results to this function in C? http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libm/src/e_exp.c This 1 ULP thing isn't necessarily an inaccuracy in general. Mostly it might be either an issue of rounding, or of method you use to display them. If you want more accurate value-print I would recommment to use the __mingw_(printf) functions instead of the MS-C-runtime one. Issue here is that values by MS-printf getting rounded different (and sometimes inaccurate). Yes, sorry, I wasn't very clear. To work out the correct values I used a multiple precision math library in Python working at 100 decimal digits of precision: https://gist.github.com/matthew-brett/11301221 I didn't use printf for these values, they are being manipulated as doubles in Python, with the values for exp comping from calls to exp via the Python code. So, I think these accuracy values are correct, and I've checked with equivalent tests for multiplication (guaranteed to closest floating point value), but I'm happy to hear otherwise. I writing to ask whether I should investigate this further to see if another implementation would give better accuracy for similar speed. Or do y'all consider the current accuracy good enough? Of course we are interested in approving our math accuracy. It would be great to improve it. Nevertheless keep please in mind that not all licenses (and so not all implementations) are acceptable for us. And for such patches some testcases would be important, too. Another pretty important thing here is also the calculation-performance. Another interesting aspect of current implementation would be to make calculation table-based without use of x87-FPU instructions (especially for x64). OK - thanks - then I will investigate further and let you know what I find, if anything. Best, Matthew -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
