This list is closed, nobody may subscribe to it.
2014 |
Jan
|
Feb
|
Mar
(6) |
Apr
(57) |
May
(43) |
Jun
(24) |
Jul
(21) |
Aug
(70) |
Sep
(112) |
Oct
(107) |
Nov
(150) |
Dec
(23) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2015 |
Jan
(35) |
Feb
(58) |
Mar
(64) |
Apr
(131) |
May
(71) |
Jun
(31) |
Jul
(29) |
Aug
(30) |
Sep
(22) |
Oct
(13) |
Nov
(46) |
Dec
(22) |
2016 |
Jan
(29) |
Feb
(49) |
Mar
(79) |
Apr
(67) |
May
(14) |
Jun
(5) |
Jul
(40) |
Aug
(31) |
Sep
(23) |
Oct
(34) |
Nov
(38) |
Dec
(28) |
2017 |
Jan
(36) |
Feb
(61) |
Mar
(18) |
Apr
(37) |
May
(25) |
Jun
(65) |
Jul
(20) |
Aug
(41) |
Sep
(17) |
Oct
(21) |
Nov
(29) |
Dec
(10) |
2018 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(9) |
May
(5) |
Jun
(4) |
Jul
(5) |
Aug
(10) |
Sep
(12) |
Oct
(7) |
Nov
|
Dec
(3) |
2019 |
Jan
(16) |
Feb
(3) |
Mar
(33) |
Apr
(2) |
May
(17) |
Jun
(10) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
|
Nov
(6) |
Dec
(19) |
2020 |
Jan
(6) |
Feb
(8) |
Mar
(6) |
Apr
(17) |
May
(8) |
Jun
(12) |
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(9) |
Dec
|
2021 |
Jan
(1) |
Feb
(8) |
Mar
(7) |
Apr
|
May
(8) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Stephen L. <ste...@st...> - 2014-05-07 06:39:53
|
For the record, monotone is now compiling successfully with msys2/mingw64 and msys2/mingw32. Attached are the install instructions. -- -- Stephe |
From: Jon b. <jon...@gm...> - 2014-05-06 19:05:36
|
When I try to compile something with scons I get this message: scons: Reading SConscript files ... EnvironmentError: No module named Actio: File "/build32/kvazaar-master/SConstruct", line 19: """) File "/usr/lib/python2.7/site-packages/SCons/Script/SConscript.py", line 607: env = self.factory() File "/usr/lib/python2.7/site-packages/SCons/Script/SConscript.py", line 587: default_env = SCons.Defaults.DefaultEnvironment() File "/usr/lib/python2.7/site-packages/SCons/Defaults.py", line 88: _default_env = SCons.Environment.Environment(*args, **kw) File "/usr/lib/python2.7/site-packages/SCons/Environment.py", line 1003: apply_tools(self, tools, toolpath) File "/usr/lib/python2.7/site-packages/SCons/Environment.py", line 107: env.Tool(tool) File "/usr/lib/python2.7/site-packages/SCons/Environment.py", line 1787: tool(self) File "/usr/lib/python2.7/site-packages/SCons/Tool/__init__.py", line 183: self.generate(env, *args, **kw) File "/usr/lib/python2.7/site-packages/SCons/Tool/default.py", line 40: for t in SCons.Tool.tool_list(env['PLATFORM'], env): File "/usr/lib/python2.7/site-packages/SCons/Tool/__init__.py", line 801: linker = FindTool(linkers, env) or linkers[0] File "/usr/lib/python2.7/site-packages/SCons/Tool/__init__.py", line 682: t = Tool(tool) File "/usr/lib/python2.7/site-packages/SCons/Tool/__init__.py", line 97: module = self._tool_module() File "/usr/lib/python2.7/site-packages/SCons/Tool/__init__.py", line 148: raise SCons.Errors.EnvironmentError(e) Am 06.05.2014 20:32, schrieb Alexey Pavlov: > 06 мая 2014 г., в 22:30, Jon bae <jon...@gm...> написал(а): > >> Hello everybody, >> is there a special trick to get scons to work? I was thinking I can use >> the msys2 python2 and scons. Is that not right? >> >> My profile looks like this: >> >> PYTHONHOME=/usr >> PYTHONPATH=/usr/lib/python2.7 >> SCONS_LIB_DIR=/usr/lib/python2.7/site-packages >> >> PATH=".:/global32/bin:/local32/bin:/mingw32/bin:${MSYS2_PATH}:/opt/bin:/opt/TortoiseHg:${PYTHONHOME}" >> export PATH PYTHONPATH >> > What problems with using SCONS? MSYS2 has its own scons package. > See: > https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-mesa/PKGBUILD#L37 > > Regards, > Alexey. > >> Best Regards! >> >> Jonathan >> >> >> >> ------------------------------------------------------------------------------ >> Is your legacy SCM system holding you back? Join Perforce May 7 to find out: >> • 3 signs your SCM is hindering your productivity >> • Requirements for releasing software faster >> • Expert tips and advice for migrating your SCM now >> http://p.sf.net/sfu/perforce >> _______________________________________________ >> Msys2-users mailing list >> Msy...@li... >> https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Alexey P. <ale...@gm...> - 2014-05-06 18:32:54
|
06 мая 2014 г., в 22:30, Jon bae <jon...@gm...> написал(а): > Hello everybody, > is there a special trick to get scons to work? I was thinking I can use > the msys2 python2 and scons. Is that not right? > > My profile looks like this: > > PYTHONHOME=/usr > PYTHONPATH=/usr/lib/python2.7 > SCONS_LIB_DIR=/usr/lib/python2.7/site-packages > > PATH=".:/global32/bin:/local32/bin:/mingw32/bin:${MSYS2_PATH}:/opt/bin:/opt/TortoiseHg:${PYTHONHOME}" > export PATH PYTHONPATH > What problems with using SCONS? MSYS2 has its own scons package. See: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-mesa/PKGBUILD#L37 Regards, Alexey. > Best Regards! > > Jonathan > > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Jon b. <jon...@gm...> - 2014-05-06 18:30:23
|
Hello everybody, is there a special trick to get scons to work? I was thinking I can use the msys2 python2 and scons. Is that not right? My profile looks like this: PYTHONHOME=/usr PYTHONPATH=/usr/lib/python2.7 SCONS_LIB_DIR=/usr/lib/python2.7/site-packages PATH=".:/global32/bin:/local32/bin:/mingw32/bin:${MSYS2_PATH}:/opt/bin:/opt/TortoiseHg:${PYTHONHOME}" export PATH PYTHONPATH Best Regards! Jonathan |
From: Hannes D. <ss...@ya...> - 2014-05-05 18:28:59
|
Alexey Pavlov <ale...@gm...> schrieb am 18:53 Montag, 5.Mai 2014: 05 мая 2014 г., в 19:54, Hannes Domani <ss...@ya...> написал(а): > > Since recently, when running 'pacman -Syu', libtool added the dependency of gcc. > > Was this intentional, or was there some special reason for this? > > > This is wrong. I will fix it today. Already fixed, thanks. Btw., msys2 is awesome. |
From: Alexey P. <ale...@gm...> - 2014-05-05 16:53:39
|
05 мая 2014 г., в 19:54, Hannes Domani <ss...@ya...> написал(а): > Hello > > Since recently, when running 'pacman -Syu', libtool added the dependency of gcc. > Was this intentional, or was there some special reason for this? > This is wrong. I will fix it today. Regards, Alexey. > Regards > Domani Hannes > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Hannes D. <ss...@ya...> - 2014-05-05 15:54:15
|
Hello Since recently, when running 'pacman -Syu', libtool added the dependency of gcc. Was this intentional, or was there some special reason for this? Regards Domani Hannes |
From: Alexpux <al...@gm...> - 2014-04-30 19:22:51
|
30 апр. 2014 г., в 22:58, Stephen Leake <ste...@st...> написал(а): > Alexey Pavlov <al...@gm...> writes: > >> I see you include MSYS2 includes instead MINGW includes. You can do it >> only if you build monotone with MSYS-gcc > > I was confused about which pcre package to install; it is now the mingw one. > This is because you don’t answer for my questions. I can’t help you if you just write what you want without dealing with us. Regards, Alexey. > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Stephen L. <ste...@st...> - 2014-04-30 18:58:29
|
Alexey Pavlov <al...@gm...> writes: > I see you include MSYS2 includes instead MINGW includes. You can do it > only if you build monotone with MSYS-gcc I was confused about which pcre package to install; it is now the mingw one. -- -- Stephe |
From: Alexey P. <al...@gm...> - 2014-04-30 08:47:20
|
2014-04-30 11:44 GMT+03:00 Stephen Leake <ste...@st...>: > Stephen Leake <ste...@st...> writes: > > >> There are two possible fixes here; >> >> 1) include c:/ in all absolute Windows paths (ie >> "c:/Msys2/msys64/include"), so msys2 knows it is an absolute path, >> and won't change it >> >> 2) use msys2 paths when the path is inside an msys2 mounted directory >> tree (ie "-I/usr/include"), so the change msys2 makes to the path is >> correct. > > with these fixes and "-i --login" applied, monotone configure now runs > to completion. > > Now I'm running into "sizeof int == sizeof pointer, right?" errors. > Sigh. > I see you include MSYS2 includes instead MINGW includes. You can do it only if you build monotone with MSYS-gcc > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Stephen L. <ste...@st...> - 2014-04-30 08:44:11
|
Stephen Leake <ste...@st...> writes: > There are two possible fixes here; > > 1) include c:/ in all absolute Windows paths (ie > "c:/Msys2/msys64/include"), so msys2 knows it is an absolute path, > and won't change it > > 2) use msys2 paths when the path is inside an msys2 mounted directory > tree (ie "-I/usr/include"), so the change msys2 makes to the path is > correct. with these fixes and "-i --login" applied, monotone configure now runs to completion. Now I'm running into "sizeof int == sizeof pointer, right?" errors. Sigh. -- -- Stephe |
From: Alexey P. <al...@gm...> - 2014-04-30 08:30:19
|
2014-04-30 11:25 GMT+03:00 Alexey Pavlov <ale...@gm...>: > > 30 апр. 2014 г., в 12:15, Stephen Leake <ste...@st...> написал(а): > >> Ray Donnelly <min...@gm...> writes: >> >>> MSYS2 programs link to the msys dll, yes, and that performs the path >>> conversions at the right times yes, so when a program asks to spawn >>> another program, msys2 intercepts and translates the MSYS2 paths it >>> sees (sometimes it guesses this wrong) to Windows paths, iff the >>> program to run is *not* another MSYS2 program (which doesn't need or >>> want native Windows paths). This is one of the key things that MSYS2 >>> does and Cygwin does not do, it's a part of MSYS2's sympathy for the >>> Windows OS. >> >> Let me try to interpret the currently failing configure test in >> light of this. >> >> Simplified, the command line that is failing is: >> >> g++ -v -c -I/Msys2/msys64/include conftest.cpp >> > You need to have «-I/msys64/include» Hmm. Seems something wrong with your include paths. To help you I need to know next things: 1. You use mingw compiler to build or msys compiler. 2. Show me your msys2 directory organization. > > Regards, > Alexey. >> Here I'm trying to tell g++ where pcre.h is; it's not in one of the >> standard include dirs that g++ uses (a separate issue in itself ;). >> >> The relevant part of the g++ output is (comments interspersed): >> >> COLLECT_GCC_OPTIONS='-v' '-c' '-I' 'C:/Msys2/msys64/Msys2/msys64/include' '-shared-libgcc' '-mtune=generic' '-march=x86-64' >> >> the -I path "/Msys2/msys64/include" has been changed to >> "C:/Msys2/msys64/Msys2/msys64/include" - NOT what I wanted. >> >> ignoring nonexistent directory "C:/Msys2/msys64/Msys2/msys64/include" >> >> This is due to the erroneous path change above >> >> >> There are two possible fixes here; >> >> 1) include c:/ in all absolute Windows paths (ie >> "c:/Msys2/msys64/include"), so msys2 knows it is an absolute path, >> and won't change it >> >> 2) use msys2 paths when the path is inside an msys2 mounted directory >> tree (ie "-I/usr/include"), so the change msys2 makes to the path is >> correct. >> >> >> The erroneous change above was done by bash, before g++ was spawned. But when g++ >> spawns cpp.exe, the msys2 dll does a similar path conversion. So all >> paths at that point had better include c:/, or not be in a msys2 mounted >> directory tree. >> >> -- >> -- Stephe >> >> ------------------------------------------------------------------------------ >> "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 >> _______________________________________________ >> Msys2-users mailing list >> Msy...@li... >> https://lists.sourceforge.net/lists/listinfo/msys2-users > > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Alexey P. <ale...@gm...> - 2014-04-30 08:25:26
|
30 апр. 2014 г., в 12:15, Stephen Leake <ste...@st...> написал(а): > Ray Donnelly <min...@gm...> writes: > >> MSYS2 programs link to the msys dll, yes, and that performs the path >> conversions at the right times yes, so when a program asks to spawn >> another program, msys2 intercepts and translates the MSYS2 paths it >> sees (sometimes it guesses this wrong) to Windows paths, iff the >> program to run is *not* another MSYS2 program (which doesn't need or >> want native Windows paths). This is one of the key things that MSYS2 >> does and Cygwin does not do, it's a part of MSYS2's sympathy for the >> Windows OS. > > Let me try to interpret the currently failing configure test in > light of this. > > Simplified, the command line that is failing is: > > g++ -v -c -I/Msys2/msys64/include conftest.cpp > You need to have «-I/msys64/include» Regards, Alexey. > Here I'm trying to tell g++ where pcre.h is; it's not in one of the > standard include dirs that g++ uses (a separate issue in itself ;). > > The relevant part of the g++ output is (comments interspersed): > > COLLECT_GCC_OPTIONS='-v' '-c' '-I' 'C:/Msys2/msys64/Msys2/msys64/include' '-shared-libgcc' '-mtune=generic' '-march=x86-64' > > the -I path "/Msys2/msys64/include" has been changed to > "C:/Msys2/msys64/Msys2/msys64/include" - NOT what I wanted. > > ignoring nonexistent directory "C:/Msys2/msys64/Msys2/msys64/include" > > This is due to the erroneous path change above > > > There are two possible fixes here; > > 1) include c:/ in all absolute Windows paths (ie > "c:/Msys2/msys64/include"), so msys2 knows it is an absolute path, > and won't change it > > 2) use msys2 paths when the path is inside an msys2 mounted directory > tree (ie "-I/usr/include"), so the change msys2 makes to the path is > correct. > > > The erroneous change above was done by bash, before g++ was spawned. But when g++ > spawns cpp.exe, the msys2 dll does a similar path conversion. So all > paths at that point had better include c:/, or not be in a msys2 mounted > directory tree. > > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Stephen L. <ste...@st...> - 2014-04-30 08:15:41
|
Ray Donnelly <min...@gm...> writes: > MSYS2 programs link to the msys dll, yes, and that performs the path > conversions at the right times yes, so when a program asks to spawn > another program, msys2 intercepts and translates the MSYS2 paths it > sees (sometimes it guesses this wrong) to Windows paths, iff the > program to run is *not* another MSYS2 program (which doesn't need or > want native Windows paths). This is one of the key things that MSYS2 > does and Cygwin does not do, it's a part of MSYS2's sympathy for the > Windows OS. Let me try to interpret the currently failing configure test in light of this. Simplified, the command line that is failing is: g++ -v -c -I/Msys2/msys64/include conftest.cpp Here I'm trying to tell g++ where pcre.h is; it's not in one of the standard include dirs that g++ uses (a separate issue in itself ;). The relevant part of the g++ output is (comments interspersed): COLLECT_GCC_OPTIONS='-v' '-c' '-I' 'C:/Msys2/msys64/Msys2/msys64/include' '-shared-libgcc' '-mtune=generic' '-march=x86-64' the -I path "/Msys2/msys64/include" has been changed to "C:/Msys2/msys64/Msys2/msys64/include" - NOT what I wanted. ignoring nonexistent directory "C:/Msys2/msys64/Msys2/msys64/include" This is due to the erroneous path change above There are two possible fixes here; 1) include c:/ in all absolute Windows paths (ie "c:/Msys2/msys64/include"), so msys2 knows it is an absolute path, and won't change it 2) use msys2 paths when the path is inside an msys2 mounted directory tree (ie "-I/usr/include"), so the change msys2 makes to the path is correct. The erroneous change above was done by bash, before g++ was spawned. But when g++ spawns cpp.exe, the msys2 dll does a similar path conversion. So all paths at that point had better include c:/, or not be in a msys2 mounted directory tree. -- -- Stephe |
From: Stephen L. <ste...@st...> - 2014-04-30 07:42:50
|
Ray Donnelly <min...@gm...> writes: > I think if you set MSYSTEM=MSYS and called bash with the arguments "-i > --login" then that might be enough to get the same environment, I was not doing "-i --login". I had actually figured that out for msys, but didn't set things up clearly enough in my emacs config to remember it. Sigh. -- -- Stephe |
From: Ray D. <min...@gm...> - 2014-04-30 07:10:04
|
Indeed. MSYS2 programs link to the msys dll, yes, and that performs the path conversions at the right times yes, so when a program asks to spawn another program, msys2 intercepts and translates the MSYS2 paths it sees (sometimes it guesses this wrong) to Windows paths, iff the program to run is *not* another MSYS2 program (which doesn't need or want native Windows paths). This is one of the key things that MSYS2 does and Cygwin does not do, it's a part of MSYS2's sympathy for the Windows OS. On Wed, Apr 30, 2014 at 8:06 AM, Ray Donnelly <min...@gm...> wrote: > I think if you set MSYSTEM=MSYS and called bash with the arguments "-i > --login" then that might be enough to get the same environment, Alexey > will know better though. > > On Wed, Apr 30, 2014 at 8:03 AM, Stephen Leake > <ste...@st...> wrote: >> Ray Donnelly <min...@gm...> writes: >> >>> It may be that you need to get the latest config.sub and config.guess from >>> savannah that includes msys2 detection. >> >> That would help, but it's not hard specifying --build=. >> >> One problem I have is I prefer to run bash under Emacs, but I'm >> apparently not setting up msys2 bash in the same way that >> msys2_shell.bat does, because I get different results when I run under >> Emacs vs in msys2_shell.bat. I'll read thru msys2_shell.bat again ... >> >> -- >> -- Stephe >> >> ------------------------------------------------------------------------------ >> "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 >> _______________________________________________ >> Msys2-users mailing list >> Msy...@li... >> https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Ray D. <min...@gm...> - 2014-04-30 07:06:07
|
I think if you set MSYSTEM=MSYS and called bash with the arguments "-i --login" then that might be enough to get the same environment, Alexey will know better though. On Wed, Apr 30, 2014 at 8:03 AM, Stephen Leake <ste...@st...> wrote: > Ray Donnelly <min...@gm...> writes: > >> It may be that you need to get the latest config.sub and config.guess from >> savannah that includes msys2 detection. > > That would help, but it's not hard specifying --build=. > > One problem I have is I prefer to run bash under Emacs, but I'm > apparently not setting up msys2 bash in the same way that > msys2_shell.bat does, because I get different results when I run under > Emacs vs in msys2_shell.bat. I'll read thru msys2_shell.bat again ... > > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Stephen L. <ste...@st...> - 2014-04-30 07:05:30
|
Stephen Leake <ste...@st...> writes: > Ray Donnelly <min...@gm...> writes: > >> msys2 should convert paths depending on the nature of the executable >> (msys vs native). > > do you mean "g++" instead of "msys2"? Or is it "the msys2 dll that g++ uses to access the file system" that does the path conversion? -- -- Stephe |
From: Stephen L. <ste...@st...> - 2014-04-30 07:03:21
|
Ray Donnelly <min...@gm...> writes: > It may be that you need to get the latest config.sub and config.guess from > savannah that includes msys2 detection. That would help, but it's not hard specifying --build=. One problem I have is I prefer to run bash under Emacs, but I'm apparently not setting up msys2 bash in the same way that msys2_shell.bat does, because I get different results when I run under Emacs vs in msys2_shell.bat. I'll read thru msys2_shell.bat again ... -- -- Stephe |
From: Alexpux <al...@gm...> - 2014-04-30 02:35:13
|
30 апр. 2014 г., в 5:38, Stephen Leake <ste...@st...> написал(а): > Ray Donnelly <min...@gm...> writes: > >> Your goal is to build monotone for native Windows 64bit? > > Yes. > >> Here's a rundown of the steps I tried: >> >> Download and unpack msys2-base-x86_64-20140216.tar.xz, I'm going to do >> this to E:\monotone and pretend you did the same just to simplify the >> instructions. > > I installed to c:\msys2 > > One possible complication: I have Cygwin installed at c:\, so /bin is > the Cygwin bin. But that doesn't seem to be a problem so far. You need to not have Cygwin bin directory in the PATH. > >> Since you want to build Win64 software, you should run >> E:\monotone\msys64\mingw64_shell.bat >> .. It will create the initial environment. >> $ exit >> run E:\monotone\msys64\mingw64_shell.bat >> $ pacman -Syu >> it will update the core system causing DLL address conflicts and we >> need to rebase the MSYS dlls. >> $ exit >> wait for bash to go away (can take 20-30 seconds), then run >> E:\monotone\msys64\autorebase.bat then run >> E:\monotone\msys64\mingw64_shell.bat > > same as my list so far. > >> .. install base development tools: >> $ pacman -S base-devel tar >> $ exit >> wait for bash to go away again then run >> E:\monotone\msys64\autorebase.bat again then run >> E:\monotone\msys64\mingw64_shell.bat again. Since we'll not update any >> more MSYS DLLs this should be the last time we need to do this. >> .. install monotone dependencies which I guess are: >> $ pacman -S mingw-w64-x86_64-toolchain mingw64/mingw-w64-x86_64-boost >> mingw64/mingw-w64-x86_64-gettext mingw64/mingw-w64-x86_64-libiconv >> mingw64/mingw-w64-x86_64-libidn mingw64/mingw-w64-x86_64-lua Maybe you need mingw-w64-x86_64-lua51? > >> mingw64/mingw-w64-x86_64-pcre mingw64/mingw-w64-x86_64-pkgconf >> mingw64/mingw-w64-x86_64-sqlite3 mingw64/mingw-w64-x86_64-zlib > > I installed mingw-w64-x86_64-toolchain, which includes several of the > above. > > I could not find out which package actually installs g++; 'pacman -Qo > g++' gives 'error: No package owns /usr/mingw64/bin/g++'. So I don't > know how to minimize the number of packages installed (not critical). g++ is installed by mingw-w64-x86_64-gcc package. > >> .. then we need to build botan. I hoped we had botan already as a >> package (I guess you compiled it already?) but it seems not, and my >> quick attempt to build it failed: > > I had no problems with botan once I fixed the directory separators in > configure. > > I'm currently stuck running configure for monotone; it's giving several > odd errors. > > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |
From: Ray D. <min...@gm...> - 2014-04-30 01:42:55
|
It may be that you need to get the latest config.sub and config.guess from savannah that includes msys2 detection. I must go to bed but we'll pick up again tomorrow. On Apr 30, 2014 2:39 AM, "Stephen Leake" <ste...@st...> wrote: > Ray Donnelly <min...@gm...> writes: > > > Your goal is to build monotone for native Windows 64bit? > > Yes. > > > Here's a rundown of the steps I tried: > > > > Download and unpack msys2-base-x86_64-20140216.tar.xz, I'm going to do > > this to E:\monotone and pretend you did the same just to simplify the > > instructions. > > I installed to c:\msys2 > > One possible complication: I have Cygwin installed at c:\, so /bin is > the Cygwin bin. But that doesn't seem to be a problem so far. > > > Since you want to build Win64 software, you should run > > E:\monotone\msys64\mingw64_shell.bat > > .. It will create the initial environment. > > $ exit > > run E:\monotone\msys64\mingw64_shell.bat > > $ pacman -Syu > > it will update the core system causing DLL address conflicts and we > > need to rebase the MSYS dlls. > > $ exit > > wait for bash to go away (can take 20-30 seconds), then run > > E:\monotone\msys64\autorebase.bat then run > > E:\monotone\msys64\mingw64_shell.bat > > same as my list so far. > > > .. install base development tools: > > $ pacman -S base-devel tar > > $ exit > > wait for bash to go away again then run > > E:\monotone\msys64\autorebase.bat again then run > > E:\monotone\msys64\mingw64_shell.bat again. Since we'll not update any > > more MSYS DLLs this should be the last time we need to do this. > > .. install monotone dependencies which I guess are: > > $ pacman -S mingw-w64-x86_64-toolchain mingw64/mingw-w64-x86_64-boost > > mingw64/mingw-w64-x86_64-gettext mingw64/mingw-w64-x86_64-libiconv > > mingw64/mingw-w64-x86_64-libidn mingw64/mingw-w64-x86_64-lua > > mingw64/mingw-w64-x86_64-pcre mingw64/mingw-w64-x86_64-pkgconf > > mingw64/mingw-w64-x86_64-sqlite3 mingw64/mingw-w64-x86_64-zlib > > I installed mingw-w64-x86_64-toolchain, which includes several of the > above. > > I could not find out which package actually installs g++; 'pacman -Qo > g++' gives 'error: No package owns /usr/mingw64/bin/g++'. So I don't > know how to minimize the number of packages installed (not critical). > > > .. then we need to build botan. I hoped we had botan already as a > > package (I guess you compiled it already?) but it seems not, and my > > quick attempt to build it failed: > > I had no problems with botan once I fixed the directory separators in > configure. > > I'm currently stuck running configure for monotone; it's giving several > odd errors. > > -- > -- Stephe > > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users > |
From: Stephen L. <ste...@st...> - 2014-04-30 01:39:04
|
Ray Donnelly <min...@gm...> writes: > Your goal is to build monotone for native Windows 64bit? Yes. > Here's a rundown of the steps I tried: > > Download and unpack msys2-base-x86_64-20140216.tar.xz, I'm going to do > this to E:\monotone and pretend you did the same just to simplify the > instructions. I installed to c:\msys2 One possible complication: I have Cygwin installed at c:\, so /bin is the Cygwin bin. But that doesn't seem to be a problem so far. > Since you want to build Win64 software, you should run > E:\monotone\msys64\mingw64_shell.bat > .. It will create the initial environment. > $ exit > run E:\monotone\msys64\mingw64_shell.bat > $ pacman -Syu > it will update the core system causing DLL address conflicts and we > need to rebase the MSYS dlls. > $ exit > wait for bash to go away (can take 20-30 seconds), then run > E:\monotone\msys64\autorebase.bat then run > E:\monotone\msys64\mingw64_shell.bat same as my list so far. > .. install base development tools: > $ pacman -S base-devel tar > $ exit > wait for bash to go away again then run > E:\monotone\msys64\autorebase.bat again then run > E:\monotone\msys64\mingw64_shell.bat again. Since we'll not update any > more MSYS DLLs this should be the last time we need to do this. > .. install monotone dependencies which I guess are: > $ pacman -S mingw-w64-x86_64-toolchain mingw64/mingw-w64-x86_64-boost > mingw64/mingw-w64-x86_64-gettext mingw64/mingw-w64-x86_64-libiconv > mingw64/mingw-w64-x86_64-libidn mingw64/mingw-w64-x86_64-lua > mingw64/mingw-w64-x86_64-pcre mingw64/mingw-w64-x86_64-pkgconf > mingw64/mingw-w64-x86_64-sqlite3 mingw64/mingw-w64-x86_64-zlib I installed mingw-w64-x86_64-toolchain, which includes several of the above. I could not find out which package actually installs g++; 'pacman -Qo g++' gives 'error: No package owns /usr/mingw64/bin/g++'. So I don't know how to minimize the number of packages installed (not critical). > .. then we need to build botan. I hoped we had botan already as a > package (I guess you compiled it already?) but it seems not, and my > quick attempt to build it failed: I had no problems with botan once I fixed the directory separators in configure. I'm currently stuck running configure for monotone; it's giving several odd errors. -- -- Stephe |
From: Stephen L. <ste...@st...> - 2014-04-30 01:32:07
|
Ray Donnelly <min...@gm...> writes: > msys2 should convert paths depending on the nature of the executable > (msys vs native). do you mean "g++" instead of "msys2"? > I've got a strong feeling that you should start from scratch I just did, twice :) > so I am writing a complete run down of getting everything in place to > start working on monotone. Are you interested in me completing this > guide? Yes. Attached is what I have so far. -- -- Stephe |
From: Stephen L. <ste...@st...> - 2014-04-30 00:57:10
|
I'm getting configure failures that appear to be caused by g++ not returning status to the msys64 shell correctly. For example: checking whether plain char is signed... no config.log shows: configure:7042: checking whether plain char is signed configure:7060: g++ -c -I/Msys2/msys64/include -I/Msys2/msys64/mingw64/include -g -O2 -Wall conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:20:12: warning: variable 'test_array' set but not used [-Wunused-but-set-variable] static int test_array [1 - 2 * !(((int)(char)-1) < 0)]; ^ configure:7060: $? = 0 configure: failed program was: But g++ did not fail; it only reported a warning. Running the same g++ command directly in the msys64 shell, followed by 'echo $?', gives 0. But adding 'echo $?' to the configure script gives 1. So something is different when run by the configure script. Several similar tests are failing similarly, but others are passing. -- -- Stephe |
From: Ray D. <min...@gm...> - 2014-04-29 23:42:01
|
Here's my start from scratch instructions anyway. I got as far as having trouble with botan, but it's too late in the evening now. You can of course have multiple MSYS2/MinGW instances on your machine without conflicts, so long as you don't run two (different) instances at once (due to DLL rebasing issues). Your goal is to build monotone for native Windows 64bit? Here's a rundown of the steps I tried: Download and unpack msys2-base-x86_64-20140216.tar.xz, I'm going to do this to E:\monotone and pretend you did the same just to simplify the instructions. Since you want to build Win64 software, you should run E:\monotone\msys64\mingw64_shell.bat .. It will create the initial environment. $ exit run E:\monotone\msys64\mingw64_shell.bat $ pacman -Syu it will update the core system causing DLL address conflicts and we need to rebase the MSYS dlls. $ exit wait for bash to go away (can take 20-30 seconds), then run E:\monotone\msys64\autorebase.bat then run E:\monotone\msys64\mingw64_shell.bat .. install base development tools: $ pacman -S base-devel tar $ exit wait for bash to go away again then run E:\monotone\msys64\autorebase.bat again then run E:\monotone\msys64\mingw64_shell.bat again. Since we'll not update any more MSYS DLLs this should be the last time we need to do this. .. install monotone dependencies which I guess are: $ pacman -S mingw-w64-x86_64-toolchain mingw64/mingw-w64-x86_64-boost mingw64/mingw-w64-x86_64-gettext mingw64/mingw-w64-x86_64-libiconv mingw64/mingw-w64-x86_64-libidn mingw64/mingw-w64-x86_64-lua mingw64/mingw-w64-x86_64-pcre mingw64/mingw-w64-x86_64-pkgconf mingw64/mingw-w64-x86_64-sqlite3 mingw64/mingw-w64-x86_64-zlib .. then we need to build botan. I hoped we had botan already as a package (I guess you compiled it already?) but it seems not, and my quick attempt to build it failed: In file included from build/include/botan/certstor.h:11:0, from src/lib/cert/x509/certstor.cpp:8: build/include/botan/x509cert.h:228:7: note: Botan::X509_Certificate::X509_Certificate() X509_Certificate() {} ^ build/include/botan/x509cert.h:228:7: note: candidate expects 0 arguments, 1 provided build/include/botan/x509cert.h:221:7: note: Botan::X509_Certificate::X509_Certificate(const std::vector<unsigned char>&) X509_Certificate(const std::vector<byte>& in); ^ .. if you have any hints on that the please let me know. Of course the goal for botan (and then monotone) is to make a PKGBUILD recipe, for example something like https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libpng/PKGBUILD Cheers, Ray. On Tue, Apr 29, 2014 at 11:11 PM, Stephen Leake <ste...@st...> wrote: > Stephen Leake <ste...@st...> writes: > >> Stephen Leake <ste...@st...> writes: >> >>> Ray Donnelly <min...@gm...> writes: >>> >>>> pacman -S mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain >>> >>> That helps, thanks. >> >> I take it back :) >> >> configure is trying to find the Botan I installed, but g++ doesn't >> seem understand the filesystem: > > I thought the solution might be to use mingw-w64-cross-toolchain, but > that does not install gcc or g++; > > $ ls /Msys2/msys64/bin/*gcc* > /Msys2/msys64/bin/msys-gcc_s-seh-1.dll > /Msys2/msys64/bin/msys-gccpp-1.dll > $ ls /Msys2/msys64/bin/*gcc* > /Msys2/msys64/bin/msys-gcc_s-seh-1.dll > /Msys2/msys64/bin/msys-gccpp-1.dll > > -- > -- Stephe > > ------------------------------------------------------------------------------ > "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 > _______________________________________________ > Msys2-users mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msys2-users |