|
Bugzilla – Full Text Bug Listing |
| Summary: | system mutex APIs missing in mingw, linking errors | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | core | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P3 | ||
| Version: | ns-3.2 | ||
| Hardware: | All | ||
| OS: | Windows | ||
|
Description
Gustavo J. A. M. Carneiro
2008-09-07 17:37:22 UTC
> I would rather just disable the real-time simulator feature on mingw...
This isn't due to the real-time simulator, it is due to the fact that the threading primitives checked in several months ago are not being compiled since the platform is "win32" not "unix." The real-time simulator just uses them.
If this is turned on, then I believe MinGW will break since there are no pthreads.
I think the real question is, "should MinGW be turned off." Perhaps our windows story should be that we can user virtual machines ...
(In reply to comment #1) > > I would rather just disable the real-time simulator feature on mingw... > > This isn't due to the real-time simulator, it is due to the fact that the > threading primitives checked in several months ago are not being compiled since > the platform is "win32" not "unix." The real-time simulator just uses them. > > If this is turned on, then I believe MinGW will break since there are no > pthreads. > > I think the real question is, "should MinGW be turned off." Perhaps our > windows story should be that we can user virtual machines ... > I think our Windows story should be that we continue to make the core simulator work with Windows, but features that require a lot of work to support or are unreasonable are either unsupported or supported by a Windows maintainer. As you point out, there are free virtualization options nowadays for Windows users. Historically, I have been surprised by the number of ns-2 Cygwin users; hence, I would be reluctant to drop Cygwin/mingw altogether unless/until we get feedback that most of those users are happy moving to virtual machines. (In reply to comment #2) > (In reply to comment #1) > > > I would rather just disable the real-time simulator feature on mingw... > > > > This isn't due to the real-time simulator, it is due to the fact that the > > threading primitives checked in several months ago are not being compiled since > > the platform is "win32" not "unix." The real-time simulator just uses them. > > > > If this is turned on, then I believe MinGW will break since there are no > > pthreads. > > > > I think the real question is, "should MinGW be turned off." Perhaps our > > windows story should be that we can user virtual machines ... > > > > I think our Windows story should be that we continue to make the core simulator > work with Windows, and to be clear, I don't view that real-time simulator has to be considered as part of the core simulator in this case (although technically it is part of src/simulator), since it is a specialized scheduler for use in emulation and packet-emitting modes that are not going to be easy to support in Windows anyways. > > I think our Windows story should be that we continue to make > > the core simulator work with Windows, > > and to be clear, I don't view that real-time simulator has to > be considered as part of the core simulator in this case > (although technically it is part of src/simulator), since it > is a specialized scheduler for use in emulation and packet- > emitting modes that are not going to be easy to support in > Windows anyways. While I agree with this (and I turned off the real-time simulator build in the case where the underlying primitives are not available) the question now is what exactly do we mean by core simulator. For example, the real-time simulator works fine on cygwin, but not on MinGw. What this seems to mean is that we need to come up with a product matrix defining what is supported on what kind of machine and teach waf to respect it. We need to publish this matrix so that, for example, folks that need to do emulation or packet-emitting modes should use cygwin and not MinGW. (In reply to comment #4) > > > I think our Windows story should be that we continue to make > > > the core simulator work with Windows, > > > > and to be clear, I don't view that real-time simulator has to > > be considered as part of the core simulator in this case > > (although technically it is part of src/simulator), since it > > is a specialized scheduler for use in emulation and packet- > > emitting modes that are not going to be easy to support in > > Windows anyways. > > While I agree with this (and I turned off the real-time simulator build in the > case where the underlying primitives are not available) the question now is > what exactly do we mean by core simulator. For example, the real-time > simulator works fine on cygwin, but not on MinGw. > > What this seems to mean is that we need to come up with a product matrix > defining what is supported on what kind of machine and teach waf to respect it. > We need to publish this matrix so that, for example, folks that need to do > emulation or packet-emitting modes should use cygwin and not MinGW. Yes I totally agree the time has come for this type of documentation. However, I hope to not burden Gustavo and waf too much in dealing with the various combinations, and we will need to also get the regression scripts to cover the valid ones and avoid the invalid ones. Re-titling for more accurate description. Actually I would be more in favor of excluding features based on missing header files or libraries rather than on a black list of platforms. This is the perfect example why. Normally people don't have pthread.h in mingw. However, there is an open source pthread implementation out there [1] that makes it easy to install a pthread library and header. Black lists are often the wrong solution, configuration tests are better. [1] http://sourceware.org/pthreads-win32/ (In reply to comment #6) > Re-titling for more accurate description. > > Actually I would be more in favor of excluding features based on missing header > files or libraries rather than on a black list of platforms. I committed this change now. I'll revert if someone objects. With this commit plus Mathieu's NSC disabling patch (bug #316) makes the whole thing compile and run unit tests in mingw. |