setup to test mngw- ...

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

setup to test mngw- ...

Boost - Testing mailing list
I've been working to get out one last issue with the boost serialization
library related to code visibility.  It shows up on only one platform.
That is gcc-mngw-gnu on the boost develop test matrix.  So I conjured up
a windows machine and I want to run these tests locally.  I'm really
confused about what software I have to install in order replicate the
behavior on the test matrix.  If I google mngw it seems that there are
multiple distributions using this name.  I tried one one but I
downloaded the compiler first and then msys and tried to run "bootstrap"
but was unsuccessful.  I need some advice on how to do this.

I did manage to implement the above procedure with Cygwin which found
found an unrelated bug.  So I'm confident I'm on the right track.  But I
need help and would appreciate information from anyone who has done this.

Robert Ramey

_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: setup to test mngw- ...

Boost - Testing mailing list
On 10/18/2017 12:21 PM, Robert Ramey via Boost-Testing wrote:

> I've been working to get out one last issue with the boost serialization
> library related to code visibility.  It shows up on only one platform.
> That is gcc-mngw-gnu on the boost develop test matrix.  So I conjured up
> a windows machine and I want to run these tests locally.  I'm really
> confused about what software I have to install in order replicate the
> behavior on the test matrix.  If I google mngw it seems that there are
> multiple distributions using this name.  I tried one one but I
> downloaded the compiler first and then msys and tried to run "bootstrap"
> but was unsuccessful.  I need some advice on how to do this.
>
> I did manage to implement the above procedure with Cygwin which found
> found an unrelated bug.  So I'm confident I'm on the right track.  But I
> need help and would appreciate information from anyone who has done this.

Here is my recipe for using mingw/gcc under Windows:

1) Do not bother with mingw, just use mingw-64.
2) Go to https://sourceforge.net/projects/mingw-w64/
3) Click on the green rectangle that says
"Download mingw-w64-install.exe".
4) This should download the file to your hard drive somewhere. Put this
file away somewhere so that you can invoke it a number of times.
5) Execute mingw-w64-install.exe,. click Next, and choose which version
you want to install. Currently you can install any gcc version from
4.8.1 through 7.1.0, and 32 and 64-bit versions.
6) When you install it will suggest a path, but since that path has
spaces, I always override it to a path with no spaces. Boost Build is
famous for problems regarding spaces in a file specification so I never
install anything I will be using with Boost Build to a path with spaces.
You would be wise to do the same.
7) Once installed the setup in user-config.jam will look like:

using gcc : 7.1 :

C:/Utilities/mingw-w64/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin/g++ :
     <cxxflags>-Wno-unused-local-typedefs
     <cxxflags>-ftrack-macro-expansion=0
     <cxxflags>-Wno-unused-variable
     <cxxflags>-D_GLIBCXX_USE_CXX11_ABI=1
     ;

You can pick and choose which cxxflags you want, but that is my list.

8) Now comes the difficult part which I know you are not going to like.
Just don't curse me, but curse mingw-64/gcc instead. In order to
compile, link, or run, the gcc bin directory must be in your Windows
PATH; it is not good enough to execute g++ from the correct directory.
This is a major PITA, because whenever you invoke, as above 'b2
toolset=gcc-7.1'
C:/Utilities/mingw-w64/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin
better be in your PATH or else nothing will work because gcc-7.1 will
not find what it needs.
9) Furthermore b2 used to test every toolset in user-config.jam even if
you were not invoking that toolset via a 'b2 toolset=something". This
meant that if you had multiple gcc toolsets in your user-config.jam for
gcc, the b2 invocation would fail because it is impossible to have the
bin directory for all those multiple toolsets first in your PATH at the
same time. I believe Steve Watanabe fixed this but I am not sure.
10) So my setup, when using a version of gcc as the toolset is that I
have a separately named user-config.jam for each gcc toolset, with names
like user-config.gcc-7.1 etc, and then before invoking the gcc toolset I
do a symbolic link to user-config.jam from user-config.gcc-7.1 etc and
then I invoke 'b2 toolset=gcc-7.1 ...".
11) You can complain to mingw-64/gcc ( it is even worse with mingw/gcc,
but almost no one uses that anymore ) about the stupidity of requiring
the particular mingw-64 bin directory to be in the Windows PATH in order
that the g++ command finds the libraries and include files and whatever
else it needs in order to compile, link, or run an executable; but they
will not care and just cite to you that VC++ sort of does the same.

That is my recipe ! If you have any questions about it please ask and I
will try to help you mas much as I can.

>
> Robert Ramey

_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: setup to test mngw- ...

Boost - Testing mailing list
On 10/18/17 2:20 PM, Edward Diener via Boost-Testing wrote:
> On 10/18/2017 12:21 PM, Robert Ramey via Boost-Testing wrote:

> 8) Now comes the difficult part which I know you are not going to like.

LOL

> Just don't curse me, but curse mingw-64/gcc instead. In order to
> compile, link, or run, the gcc bin directory must be in your Windows
> PATH; it is not good enough to execute g++ from the correct directory.
> This is a major PITA, because whenever you invoke, as above 'b2
> toolset=gcc-7.1'
> C:/Utilities/mingw-w64/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin
> better be in your PATH or else nothing will work because gcc-7.1 will
> not find what it needs.
> 9) Furthermore b2 used to test every toolset in user-config.jam even if
> you were not invoking that toolset via a 'b2 toolset=something". This
> meant that if you had multiple gcc toolsets in your user-config.jam for
> gcc, the b2 invocation would fail because it is impossible to have the
> bin directory for all those multiple toolsets first in your PATH at the
> same time. I believe Steve Watanabe fixed this but I am not sure.
> 10) So my setup, when using a version of gcc as the toolset is that I
> have a separately named user-config.jam for each gcc toolset, with names
> like user-config.gcc-7.1 etc, and then before invoking the gcc toolset I
> do a symbolic link to user-config.jam from user-config.gcc-7.1 etc and
> then I invoke 'b2 toolset=gcc-7.1 ...".
> 11) You can complain to mingw-64/gcc ( it is even worse with mingw/gcc,
> but almost no one uses that anymore ) about the stupidity of requiring
> the particular mingw-64 bin directory to be in the Windows PATH in order
> that the g++ command finds the libraries and include files and whatever
> else it needs in order to compile, link, or run an executable; but they
> will not care and just cite to you that VC++ sort of does the same.
>
> That is my recipe ! If you have any questions about it please ask and I
> will try to help you mas much as I can.

Actually I did the above - or something similar had had the same hassle
regarding the path, etc.  I got disgusted and uninstalled the whole
thing.  Then I installed Cygwin - which uses it's own shell which looks
like a unix environment even though it builds and invokes windows
executables. Without much pain, I bootstrapped boost build and ran my
whole build/test suite.  It took forever though.  And of course a bunch
of tests failed for a particular archive type xml - wide character.
After too much time I isolated this and got everying working spiffy on
cywgin.  I uploaded develop branch and cross my fingers.  Alas - still
I've got the same mngw issue.

I was really hoping that installing some version of MSYS with it's shell
would give me similar results to cygwin. But alas, there are multiple
versions of this just as there are for the mngw compiler.  It appears
that there is the "official" one and the "better" one.  It's quite
confusing.  But your explanation has encouraged me to investigate this
further.

Thanks for your help.

Robert Ramey


>
>>
>> Robert Ramey
>
> _______________________________________________
> Boost-Testing mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-testing

_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: setup to test mngw- ...

Boost - Testing mailing list
Robert Ramey wrote:

> I was really hoping that installing some version of MSYS with it's shell
> would give me similar results to cygwin.

The best msys is this: http://www.msys2.org/

Apart from that, you might also try STL's mingw distro:
https://nuwen.net/mingw.html

_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: setup to test mngw- ...

Boost - Testing mailing list
On 10/18/17 3:11 PM, Peter Dimov via Boost-Testing wrote:
> Robert Ramey wrote:
>
>> I was really hoping that installing some version of MSYS with it's
>> shell would give me similar results to cygwin.
>
> The best msys is this: http://www.msys2.org/
>
> Apart from that, you might also try STL's mingw distro:
> https://nuwen.net/mingw.html

Just to finish off this thread:

I ended up using the information on this page:

http://www.math.ucla.edu/~wotaoyin/windows_coding.html

which gave me exactly what I wanted.  It built a whole unix shell
environment.  Then using the "Getting Started for unix" worked as
advertised.

As additional background for anyone who might be interested.

I've been having difficulties getting the serialization library to build
and execute all tests since I implemented "visibility" for osx and unix
systems.  MSVC implements this by default.  This is much harder than it
should be due to

a) the "visibility" attributes vary in subtle ways across platforms.
b) the serialization library makes this more difficult as it seeks to
separate support for wide vs non-wide archives in separate dlls.

For a while I made progress by making changes and pushing them to the
develop branch and relying on the boost test matrix.  But It got to the
point where I could make no more progress with this method.  I run a mac
mini which I purchased because of a strong unix underpinning, good
support for the Clang compiler as of late I have interest in more
"cutting edge" stuff.   My current system has a large SDD and 4 cores so
it runs very fast.  Boost build exploits these cores to good advantage.
To address my problems with the serialization library I first installed
"Parallels" (c) then installed ubuntu linux.  This setup works quite
well.  In short order I was able to get things straightened out on
almost all linux platforms.  I dragged my feet with windows.  I have
many years experience with windows.  I changed to my mac mini above in
large part because I found that there was too much IT overhead dealing
with windows.  Constant upgrades of OS and VS etc.  Developing with
CLang on my osx system has been much better for me.

But couldn't get the mingw tests to pass on the test matrix so I
installed a windows system under "Parallels".  Then I installed cygwin
and msys under windows.  Using boost build, I've got things to pass
under both these systems.  I now how to go back and test the other
combinations under osx - clang, darwin-gcc, shared/static, debug/release
etc.  This takes a lot of time.  Maybe I'll be able to check in by early
next week.

One great thing about this system is that it lets me share the file
system among the different environments. So I run all tests with the
same files. Also it shares the "Library Status" test matrix so I now get
a humoungous test matrix which shows all the test results making it easy
to compare results across os,compilers, stl version, etc. etc.

Robert Ramey

_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: setup to test mngw- ...

Boost - Testing mailing list
In reply to this post by Boost - Testing mailing list
On 19/10/2017 0:03, Robert Ramey via Boost-Testing wrote:

> I was really hoping that installing some version of MSYS with it's shell
> would give me similar results to cygwin. But alas, there are multiple
> versions of this just as there are for the mngw compiler.  It appears
> that there is the "official" one and the "better" one.  It's quite
> confusing.  But your explanation has encouraged me to investigate this
> further.

Running mingw is really hard due to path issues. Here's what I do to
configure regressions runners:

I install a Mingw-w64 compiler. Say in:

C:\Programs\mingw-builds\i686-7.1.0-posix-dwarf-rt_v5-rev2\

then I put a file named gcc-7.1.bat in:

C:\Programs\mingw-builds\i686-7.1.0-posix-dwarf-rt_v5-rev2\mingw32\bin\gcc-7.1.bat

The .bat file contains the commands:

@echo off
set
PATH=C:\Programs\mingw-builds\i686-7.1.0-posix-dwarf-rt_v5-rev2\mingw32\bin;%PATH%
g++ %*

Finally I add the compiler to user-config.jam with several c++ standard
compliance versions:

#GCC 7.1
using gcc : 7.1c++17 :
C:/Programs/mingw-builds/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin/gcc-7.1.bat
: <cxxflags>"-pipe -fmax-errors=1 -std=c++17 -Wall -Wextra -pedantic
-Wno-deprecated-declarations -Wno-long-long -Werror" <linkflags>"-pipe" ;
using gcc : 7.1c++14 :
C:/Programs/mingw-builds/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin/gcc-7.1.bat
: <cxxflags>"-pipe -fmax-errors=1 -std=c++14 -Wall -Wextra -pedantic
-Wno-deprecated-declarations -Wno-long-long -Werror" <linkflags>"-pipe" ;
using gcc : 7.1c++11 :
C:/Programs/mingw-builds/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin/gcc-7.1.bat
: <cxxflags>"-pipe -fmax-errors=1 -std=c++11 -Wall -Wextra -pedantic
-Wno-deprecated-declarations -Wno-long-long -Werror" <linkflags>"-pipe" ;
using gcc : 7.1c++03 :
C:/Programs/mingw-builds/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin/gcc-7.1.bat
: <cxxflags>"-pipe -fmax-errors=1 -std=c++03 -Wall -Wextra -pedantic
-Wno-deprecated-declarations -Wno-long-long -Werror" <linkflags>"-pipe" ;

Then I can run tests as:

c:\Data\Libs\boost\libs\move\test>..\..\..\b2 toolset=gcc-7.1c++17

I hope it helps.

Ion
_______________________________________________
Boost-Testing mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-testing