Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception
On 21/03/2017 07:43, Ruben Van Boxem wrote: > Op 21 mrt. 2017 8:07 a.m. schreef "Liu Hao" > : > > On 2017/3/20 20:49, Jon Turney wrote: >> Windows 10 now has a separate exception for OutputDebugStringW, rather > than >> converting the string to ANSI and raising DBG_PRINTEXCEPTION_C. >> >> (See https://ntquery.wordpress.com/2015/09/07/windows-10-new- > anti-debug-outputdebugstringw/) > It can also be found here: > https://github.com/x64dbg/x64dbg/commit/50008401ee71b7d84fa2bc6dec1591 > 7f0f21e94e > > Because this is a Windows 10 thing it should probably be wrapped inside > an `#if _WIN32_WINNT >= ??? ... #endif` block. Nevertheless I don't > think we should apply this until we start adding Win10 stuff. This value is not guarded in that way in the SDK. I'm not sure why that might be. > Win10 stuff has been added before. I don't see how this should be any > different? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception
Windows 10 now has a separate exception for OutputDebugStringW, rather than
converting the string to ANSI and raising DBG_PRINTEXCEPTION_C.
(See
https://ntquery.wordpress.com/2015/09/07/windows-10-new-anti-debug-outputdebugstringw/)
Signed-off-by: Jon Turney
---
mingw-w64-headers/include/ntstatus.h | 1 +
mingw-w64-headers/include/winnt.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/mingw-w64-headers/include/ntstatus.h
b/mingw-w64-headers/include/ntstatus.h
index 6e95af7..49298ee 100644
--- a/mingw-w64-headers/include/ntstatus.h
+++ b/mingw-w64-headers/include/ntstatus.h
@@ -161,6 +161,7 @@
#define DBG_RIPEXCEPTION ((NTSTATUS)0x40010007)
#define DBG_CONTROL_BREAK ((NTSTATUS)0x40010008)
#define DBG_COMMAND_EXCEPTION ((NTSTATUS)0x40010009)
+#define DBG_PRINTEXCEPTION_WIDE_C ((NTSTATUS)(0x4001000A)
#define RPC_NT_UUID_LOCAL_ONLY ((NTSTATUS)0x40020056)
#define RPC_NT_SEND_INCOMPLETE ((NTSTATUS)0x400200AF)
#define STATUS_CTX_CDM_CONNECT ((NTSTATUS)0x400A0004)
diff --git a/mingw-w64-headers/include/winnt.h
b/mingw-w64-headers/include/winnt.h
index a855801..6ac9f3e 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -1299,6 +1299,7 @@ inline ENUMTYPE &operator ^= (ENUMTYPE &a, ENUMTYPE b) {
return (ENUMTYPE &)(((i
#define DBG_RIPEXCEPTION ((DWORD)0x40010007)
#define DBG_CONTROL_BREAK ((DWORD)0x40010008)
#define DBG_COMMAND_EXCEPTION ((DWORD)0x40010009)
+#define DBG_PRINTEXCEPTION_WIDE_C ((DWORD)(0x4001000A)
#define STATUS_GUARD_PAGE_VIOLATION ((DWORD)0x8001)
#define STATUS_DATATYPE_MISALIGNMENT ((DWORD)0x8002)
#define STATUS_BREAKPOINT ((DWORD)0x8003)
--
2.8.3
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions
Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are
correctly decorated with WINAPI (= stdcall on x86), so linkage works
correctly on x86.
---
mingw-w64-headers/include/pdh.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-headers/include/pdh.h b/mingw-w64-headers/include/pdh.h
index 7185f53..772aa5f 100644
--- a/mingw-w64-headers/include/pdh.h
+++ b/mingw-w64-headers/include/pdh.h
@@ -555,14 +555,14 @@ extern "C" {
#define PdhVerifySQLDB __MINGW_NAME_AW(PdhVerifySQLDB)
#if (_WIN32_WINNT >= 0x0600)
-PDH_STATUS PdhAddEnglishCounterA(
+PDH_FUNCTION PdhAddEnglishCounterA(
PDH_HQUERY hQuery,
LPCSTR szFullCounterPath,
DWORD_PTR dwUserData,
PDH_HCOUNTER *phCounter
);
-PDH_STATUS PdhAddEnglishCounterW(
+PDH_FUNCTION PdhAddEnglishCounterW(
PDH_HQUERY hQuery,
LPCWSTR szFullCounterPath,
DWORD_PTR dwUserData,
@@ -571,17 +571,17 @@ PDH_STATUS PdhAddEnglishCounterW(
#define PdhAddEnglishCounter __MINGW_NAME_AW(PdhAddEnglishCounter)
-PDH_STATUS PdhCollectQueryDataWithTime(
+PDH_FUNCTION PdhCollectQueryDataWithTime(
PDH_HQUERY hQuery,
LONGLONG *pllTimeStamp
);
-PDH_STATUS PdhValidatePathExA(
+PDH_FUNCTION PdhValidatePathExA(
PDH_HLOG hDataSource,
LPCSTR szFullPathBuffer
);
-PDH_STATUS PdhValidatePathExW(
+PDH_FUNCTION PdhValidatePathExW(
PDH_HLOG hDataSource,
LPCWSTR szFullPathBuffer
);
--
2.8.3
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] About the recent sourceforge events
If you've not already investigated it for options for the binary downloads, this is worth considering and currently free for OSS https://bintray.com/ It could be compelling when combined with some of the other mentions. Jon On Thu, Jun 11, 2015 at 12:04 PM, Ivan Garramona wrote: > Hi Ruben, i think public repos doesn't have any user limits on bitbucket. > > -- > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] asctime_r duplications
I slip-streamed Jacek's patch into time.h and successfully built go1.4
flavors (windows/amd64, windows/386, linux/amd64, linux/386,
darwin/amd64, darwin/386) from my local C:\Apps\go-git repo.
I currently don't use the MSYS2 mingw-w64-{i686,x86_64}-go pkgs. Now
that I know about the them I'll try to find time to look at the
PKGBUILD's
On 1/7/15, Ray Donnelly wrote:
> On Wed, Jan 7, 2015 at 2:45 PM, Jon wrote:
>> Looks to be the issue behind my recent go build fail...
>>
>> $ pacman -Q | grep mingw
>> mingw-w64-x86_64-binutils-git 2.25.r81689.f30b244-3
>> mingw-w64-x86_64-bzip2 1.0.6-2
>> mingw-w64-x86_64-cloog 0.18.1-3
>> mingw-w64-x86_64-crt-git 4.0.0.4388.c7e4f8f-1
>> mingw-w64-x86_64-gcc 4.9.2-2
>> mingw-w64-x86_64-gcc-libs 4.9.2-2
>> mingw-w64-x86_64-gmp 6.0.0-2
>> mingw-w64-x86_64-headers-git 4.0.0.4388.c7e4f8f-1
>> mingw-w64-x86_64-isl 0.13-1
>> mingw-w64-x86_64-libiconv 1.14-2
>> mingw-w64-x86_64-libwinpthread-git 4.0.0.4370.d008dc5-1
>> mingw-w64-x86_64-mpc 1.0.2-2
>> mingw-w64-x86_64-mpfr 3.1.2.p11-1
>> mingw-w64-x86_64-winpthreads-git 4.0.0.4370.d008dc5-1
>> mingw-w64-x86_64-zlib 1.2.8-5
>>
>>
>> C:\Apps\go-git [go_1.4 +8 ~0 -0 !]> .\buildall.ps1
>>
>> ---> building for windows/amd64 platform
>>
>> # Building C bootstrap tool.
>> cmd/dist
>>
>> # Building compilers and Go bootstrap tool.
>> lib9
>> libbio
>> liblink
>> cmd/cc
>> cmd/gc
>> cmd/6l
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o: In function
>> `asctime_r':
>> C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
>> multiple definition of
>> `asctime_r'
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
>> first defined here
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o: In function
>> `asctime_r':
>> C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
>> multiple definition of
>> `asctime_r'
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
>> first defined here
>> ...SNIP...
>> collect2.exe: error: ld returned 1 exit status
>> go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused
>> -Wno-sign-compare -Wno-missing-braces -Wno-parentheses
>> -Wno-unknown-pragmas -Wno-switch -Wno-comment
>> -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe
>> -Wuninitialized -O2 -fmessage-length=0 -o
>> C:\Apps\go-git\pkg\tool\windows_amd64\6l.exe -m64
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\elf.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\go.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldelf.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldmacho.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldpe.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\lib.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\macho.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pcln.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pe.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pobj.o
>> C:\Users\Jon\AppData\Local\Temp\go9683.tmp\symtab.o C:\Us
>>
>
> You'll need to rebuild mingw-w64-headers from the PKGBUILD for now.
>
> p.s. The MSYS2/MinGW-w64 go packages are AFAIK, under maintained, do
> you think you could take a look at our PKGBUILD sometime to see if
> it's correct / working well? I'm not asking you to adopt it, just to
> kick the tyres once if you don't mind?
>
>> On 1/7/15, Ray Donnelly wrote:
>>> On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song
>>> wrote:
>>>> On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban
>>>> wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> On 01/07/15 09:06, Alexey Pavlov wrote:
>>>>>> Ladt changes to time functions lead to multiple definitions of
>>>>>> "asctime_r" in some programs. For example,
>>>>>
>>>>> I just pushed a fixup:
>>>>> http://sourceforge.net/p/mingw-w64/mingw-w64/ci/9f52135b2fa1336d63cda12c502f1790797387fa
>>>>>
>>>>> I wonder why it didn't cause errors in my case...
>>>>>
>>>>
>>>> Thanks. It cause gcc build failure because more than one source file
>>>> includ
Re: [Mingw-w64-public] asctime_r duplications
Looks to be the issue behind my recent go build fail... $ pacman -Q | grep mingw mingw-w64-x86_64-binutils-git 2.25.r81689.f30b244-3 mingw-w64-x86_64-bzip2 1.0.6-2 mingw-w64-x86_64-cloog 0.18.1-3 mingw-w64-x86_64-crt-git 4.0.0.4388.c7e4f8f-1 mingw-w64-x86_64-gcc 4.9.2-2 mingw-w64-x86_64-gcc-libs 4.9.2-2 mingw-w64-x86_64-gmp 6.0.0-2 mingw-w64-x86_64-headers-git 4.0.0.4388.c7e4f8f-1 mingw-w64-x86_64-isl 0.13-1 mingw-w64-x86_64-libiconv 1.14-2 mingw-w64-x86_64-libwinpthread-git 4.0.0.4370.d008dc5-1 mingw-w64-x86_64-mpc 1.0.2-2 mingw-w64-x86_64-mpfr 3.1.2.p11-1 mingw-w64-x86_64-winpthreads-git 4.0.0.4370.d008dc5-1 mingw-w64-x86_64-zlib 1.2.8-5 C:\Apps\go-git [go_1.4 +8 ~0 -0 !]> .\buildall.ps1 ---> building for windows/amd64 platform # Building C bootstrap tool. cmd/dist # Building compilers and Go bootstrap tool. lib9 libbio liblink cmd/cc cmd/gc cmd/6l C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o: In function `asctime_r': C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238: multiple definition of `asctime_r' C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238: first defined here C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o: In function `asctime_r': C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238: multiple definition of `asctime_r' C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238: first defined here ...SNIP... collect2.exe: error: ld returned 1 exit status go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -Wuninitialized -O2 -fmessage-length=0 -o C:\Apps\go-git\pkg\tool\windows_amd64\6l.exe -m64 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\elf.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\go.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldelf.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldmacho.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldpe.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\lib.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\macho.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pcln.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pe.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pobj.o C:\Users\Jon\AppData\Local\Temp\go9683.tmp\symtab.o C:\Us On 1/7/15, Ray Donnelly wrote: > On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song > wrote: >> On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban >> wrote: >>> Hi Alexey, >>> >>> On 01/07/15 09:06, Alexey Pavlov wrote: >>>> Ladt changes to time functions lead to multiple definitions of >>>> "asctime_r" in some programs. For example, >>> >>> I just pushed a fixup: >>> http://sourceforge.net/p/mingw-w64/mingw-w64/ci/9f52135b2fa1336d63cda12c502f1790797387fa >>> >>> I wonder why it didn't cause errors in my case... >>> >> >> Thanks. It cause gcc build failure because more than one source file >> include time.h, then asctime_r got implemented more than once. > > Ditto, fixes problems on MSYS2. Alexey, can you re-package > mingw-w64-headers as this problem will hit a lot of people very soon > otherwise. > >> >> -- >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take >> a >> look and join the conversation now. http://goparallel.sourceforge.net >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.so
Re: [Mingw-w64-public] 4.8.x and 4.9.x linking with libgcc default
On Mon, Jun 9, 2014 at 10:33 AM, Jon wrote:
>
> On Mon, Jun 9, 2014 at 10:20 AM, Jon wrote:
>
>>
>> On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
>>
>>> The 4.8.x series changed its default behavior re: libgcc linking when on
>>> Windows
>>>
>>> http://gcc.gnu.org/gcc-4.8/changes.html#windows
>>>
>>> I'm testing with my environment to confirm 4.9.x default libgcc linking
>>> behavior (for both exes and dlls) for the following two toolchains because
>>> the GCC 4.9 changelog makes no mention of the issue.
>>>
>>> 1) mingw-w64 mingw-builds:
>>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/
>>>
>>> 2) msys2 mingw:
>>> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/
>>>
>>> While I'm testing, niXman and Alexey please confirm your toolchain's
>>> default behavior re: libgcc linking.
>>>
>>>
>> Testing the above 4.9.0 toolchains on a small sample of projects (e.g. -
>> openssl), for the scenarios where libgcc is linked in I get the following
>> results:
>>
>> * 32bit mingw-w64 mingw-builds => implicit link to `libgcc_s_sjlj-1.dll`
>> * 32bit msys2 mingw32 => implicit link to `libgcc_s_dw2-1.dll`
>>
>> * 64bit mingw-w64 mingw-builds and msys2 mingw64 => no implicit link to
>> `libgcc_s_seh-1.dll`
>>
>> Is this expected?
>>
>> I was surprised that in cases where the 32bit 4.9.0 toolchains linked to
>> `libgcc_s_{sjlj,dw2}-1.dll`, the 64bit 4.9.0 toolchains did not appear to
>> correspondingly link to `libgcc_s_seh-1.dll`.
>>
>
> Hit send too fast, the 64bit results should say:
>
> * 64bit mingw-w64 mingw-builds => no implicit link to `libgcc_s_sjlj-1.dll`
> * 64bit msys2 mingw64 => no implicit link to `libgcc_s_seh-1.dll`
>
> If it's not clear, I tested with the threads-win32 and sjlj toolchains
> from mingw-w64 mingw-builds and the mingw-w64-{i686,x86_64}-gcc 4.9.0-4
> pacman packages from msys2.
>
Lovely, I'm talking to myself here. If this is an obvious RTFM question,
please end the pain with a helpful link ;)
If not, one of you more knowledgeable chaps please explain why, for the
same built artifacts, the above 32bit 4.9.0 toolchains create implicit
libgcc links but the 64bit toolchains do not? I would have expected both to
behave similarly wrt implicit libgcc linking.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 4.8.x and 4.9.x linking with libgcc default
On Mon, Jun 9, 2014 at 10:20 AM, Jon wrote:
>
> On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
>
>> The 4.8.x series changed its default behavior re: libgcc linking when on
>> Windows
>>
>> http://gcc.gnu.org/gcc-4.8/changes.html#windows
>>
>> I'm testing with my environment to confirm 4.9.x default libgcc linking
>> behavior (for both exes and dlls) for the following two toolchains because
>> the GCC 4.9 changelog makes no mention of the issue.
>>
>> 1) mingw-w64 mingw-builds:
>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/
>>
>> 2) msys2 mingw:
>> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/
>>
>> While I'm testing, niXman and Alexey please confirm your toolchain's
>> default behavior re: libgcc linking.
>>
>>
> Testing the above 4.9.0 toolchains on a small sample of projects (e.g. -
> openssl), for the scenarios where libgcc is linked in I get the following
> results:
>
> * 32bit mingw-w64 mingw-builds => implicit link to `libgcc_s_sjlj-1.dll`
> * 32bit msys2 mingw32 => implicit link to `libgcc_s_dw2-1.dll`
>
> * 64bit mingw-w64 mingw-builds and msys2 mingw64 => no implicit link to
> `libgcc_s_seh-1.dll`
>
> Is this expected?
>
> I was surprised that in cases where the 32bit 4.9.0 toolchains linked to
> `libgcc_s_{sjlj,dw2}-1.dll`, the 64bit 4.9.0 toolchains did not appear to
> correspondingly link to `libgcc_s_seh-1.dll`.
>
Hit send too fast, the 64bit results should say:
* 64bit mingw-w64 mingw-builds => no implicit link to `libgcc_s_sjlj-1.dll`
* 64bit msys2 mingw64 => no implicit link to `libgcc_s_seh-1.dll`
If it's not clear, I tested with the threads-win32 and sjlj toolchains from
mingw-w64 mingw-builds and the mingw-w64-{i686,x86_64}-gcc 4.9.0-4 pacman
packages from msys2.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 4.8.x and 4.9.x linking with libgcc default
On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
> The 4.8.x series changed its default behavior re: libgcc linking when on
> Windows
>
> http://gcc.gnu.org/gcc-4.8/changes.html#windows
>
> I'm testing with my environment to confirm 4.9.x default libgcc linking
> behavior (for both exes and dlls) for the following two toolchains because
> the GCC 4.9 changelog makes no mention of the issue.
>
> 1) mingw-w64 mingw-builds:
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/
>
> 2) msys2 mingw:
> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/
>
> While I'm testing, niXman and Alexey please confirm your toolchain's
> default behavior re: libgcc linking.
>
>
Testing the above 4.9.0 toolchains on a small sample of projects (e.g. -
openssl), for the scenarios where libgcc is linked in I get the following
results:
* 32bit mingw-w64 mingw-builds => implicit link to `libgcc_s_sjlj-1.dll`
* 32bit msys2 mingw32 => implicit link to `libgcc_s_dw2-1.dll`
* 64bit mingw-w64 mingw-builds and msys2 mingw64 => no implicit link to
`libgcc_s_seh-1.dll`
Is this expected?
I was surprised that in cases where the 32bit 4.9.0 toolchains linked to
`libgcc_s_{sjlj,dw2}-1.dll`, the 64bit 4.9.0 toolchains did not appear to
correspondingly link to `libgcc_s_seh-1.dll`.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] 4.8.x and 4.9.x linking with libgcc default
The 4.8.x series changed its default behavior re: libgcc linking when on Windows http://gcc.gnu.org/gcc-4.8/changes.html#windows I'm testing with my environment to confirm 4.9.x default libgcc linking behavior (for both exes and dlls) for the following two toolchains because the GCC 4.9 changelog makes no mention of the issue. 1) mingw-w64 mingw-builds: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/ 2) msys2 mingw: http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ While I'm testing, niXman and Alexey please confirm your toolchain's default behavior re: libgcc linking. Thank you. Jon -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Update OpenGL headers
On 06/05/2014 14:33, LRN wrote: > On 06.05.2014 17:26, Kai Tietz wrote: >> 2014-05-06 15:01 GMT+02:00 LRN: >> Patch is of course ok. I just wanted a note on mailing-list that you've >> update to current (which version?). > OpenGL 4.4, i think. > > In my RSS feed there's an entry about OpenGL 4.4 dated 2014.03.20, and one of > the headers is dated 2014.03.19. And http://www.opengl.org/registry/ says 4.4 > as well. If you want a more fine grained version, you can use the svn revision number from the svn repository at https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/GL/ I think the links on the Khronos website just point to the latest version there, although they might be some manually chosen version instead. -- "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] [MSYS2 request] add manifest file to patch archive
On Wed, May 14, 2014 at 4:07 PM, Jon wrote: > Similar to how msys includes a `patch.exe.manifest` file in it's 2.6.1 > patch archive from > > http://sourceforge.net/projects/mingw/files/MSYS/Extension/ > > please consider adding a manifest file to an updated release of msys2's > 2.7.1 patch (i686 and x86_64) archives. > > A manifest file is one of the workarounds to patch's UAC problems on > Windows. > Please disregard this noise. I now see both i686 and x86_64 flavors have embedded manifests. -- "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] [MSYS2 request] add manifest file to patch archive
Similar to how msys includes a `patch.exe.manifest` file in it's 2.6.1 patch archive from http://sourceforge.net/projects/mingw/files/MSYS/Extension/ please consider adding a manifest file to an updated release of msys2's 2.7.1 patch (i686 and x86_64) archives. A manifest file is one of the workarounds to patch's UAC problems on Windows. -- "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 Mon, Apr 28, 2014 at 2:32 PM, Adrien Nader wrote: > On Mon, Apr 28, 2014, Jon wrote: > > On Mon, Apr 28, 2014 at 10:03 AM, LRN wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 28.04.2014 17:04, JonY wrote: > > > > On 4/28/2014 19:53, Ruben Van Boxem wrote: > > > >> Different repositories may sound like a nice idea, but keeping them > in > > > >> sync can be a pain, depending on the complexity of the subprojects. > I > > > >> believe stuff like ironcrate, winpthreads and perhaps the > > > >> mingw-w64-tools folder deserve their own repo, as they are very > seperate > > > >> from the headers+crt. These latter two I'd suggest to keep > together, as > > > >> that will reduce the chances of wrong versions being used together > and > > > >> allow 1 commit to change both to keep them aligned without any > hassle. > > > >> In contrast, I would try to move away from a seperate "experimental" > > > >> directory, and instead inject these changes into a branch (or > several, > > > >> so that each finished feature can be merged easily). Branches and > > > >> merging are the git way, and rebasing allows for clean merges. > > > >> > > > > > > > > For ease of migration, every module in trunk would go into the same > repo, > > > > so that would include winpthreads and mingw-w64-tools. I'm not sure > if we > > > > can "exclude" files from the import unless we want to completely > break > > > > apart trunk into components. However, I am also trying to avoid too > many > > > > separate repos and git submodules. > > > > > > > > Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper > > > > (with anything from experimental if applicable), web, and > experimental > > > (if > > > > it actually justifies a separate repo, otherwise, it might be > archived > > > and > > > > left as is on SVN). > > > > > > My experience so far: > > > 1) When i build gcc, i often need to build mingw-w64-headers, > mingw-w64-crt > > > and winpthreads not together, but separately, at different points of > time. > > > To > > > this end i'm svn-checkouting from a subdirectory to get only one of the > > > three. > > > I don't remember whether git has that ability; possibly not. If that > is the > > > case, these may need to go into separate repos (possibly submodules?). > > > > > > 2) The git branches are for "branching out" from the main development > line > > > (and merging back at some later point), not for completely separate > stuff. > > > If > > > you keep completely different stuff in different branches, switching > > > branches > > > (which usually takes less than a second) will take a long time > (depending > > > on > > > the size, up to 10 seconds or more). The svn "branches" are more like > git > > > "repos" - completely independent, they just "live together" :) > > > > > > > > While you're investigating different git repo structures, I highly > suggest > > you investigate git's lightly documented "orphan" branches. These allow > > multiple disparate branches to exist in a single repo. They allow you to > > create "blank slate" style branches based upon a very early initial > commit. > > They work quite different than the merge friendly git branches you > > typically see documented. You can still cherrypick from other branches if > > needed. > > > > https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html > > > > For example, say you want winpthreads on it's own branch that doesn't > > contain winpthreads unrelated commits. Create the orphan branch similar > to > > > > # is an initial commit that typically includes only your > > `.gitattributes` and `.gitignore` files. Consider > > # to be the "primordial" branch commit. > > git checkout --orphan winpthreads > > > > # discover that the primordial branch commit is already > > staged; commit it > > # as the winpthreads branch initial commit > > git commit -m "Initial commit; project attributes and ignores" > > > > # add all the winpthreads specific code to this otherwise > > git commit -am "Add win
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014 at 10:03 AM, LRN wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 28.04.2014 17:04, JonY wrote: > > On 4/28/2014 19:53, Ruben Van Boxem wrote: > >> Different repositories may sound like a nice idea, but keeping them in > >> sync can be a pain, depending on the complexity of the subprojects. I > >> believe stuff like ironcrate, winpthreads and perhaps the > >> mingw-w64-tools folder deserve their own repo, as they are very seperate > >> from the headers+crt. These latter two I'd suggest to keep together, as > >> that will reduce the chances of wrong versions being used together and > >> allow 1 commit to change both to keep them aligned without any hassle. > >> In contrast, I would try to move away from a seperate "experimental" > >> directory, and instead inject these changes into a branch (or several, > >> so that each finished feature can be merged easily). Branches and > >> merging are the git way, and rebasing allows for clean merges. > >> > > > > For ease of migration, every module in trunk would go into the same repo, > > so that would include winpthreads and mingw-w64-tools. I'm not sure if we > > can "exclude" files from the import unless we want to completely break > > apart trunk into components. However, I am also trying to avoid too many > > separate repos and git submodules. > > > > Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper > > (with anything from experimental if applicable), web, and experimental > (if > > it actually justifies a separate repo, otherwise, it might be archived > and > > left as is on SVN). > > My experience so far: > 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt > and winpthreads not together, but separately, at different points of time. > To > this end i'm svn-checkouting from a subdirectory to get only one of the > three. > I don't remember whether git has that ability; possibly not. If that is the > case, these may need to go into separate repos (possibly submodules?). > > 2) The git branches are for "branching out" from the main development line > (and merging back at some later point), not for completely separate stuff. > If > you keep completely different stuff in different branches, switching > branches > (which usually takes less than a second) will take a long time (depending > on > the size, up to 10 seconds or more). The svn "branches" are more like git > "repos" - completely independent, they just "live together" :) > > While you're investigating different git repo structures, I highly suggest you investigate git's lightly documented "orphan" branches. These allow multiple disparate branches to exist in a single repo. They allow you to create "blank slate" style branches based upon a very early initial commit. They work quite different than the merge friendly git branches you typically see documented. You can still cherrypick from other branches if needed. https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html For example, say you want winpthreads on it's own branch that doesn't contain winpthreads unrelated commits. Create the orphan branch similar to # is an initial commit that typically includes only your `.gitattributes` and `.gitignore` files. Consider # to be the "primordial" branch commit. git checkout --orphan winpthreads # discover that the primordial branch commit is already staged; commit it # as the winpthreads branch initial commit git commit -m "Initial commit; project attributes and ignores" # add all the winpthreads specific code to this otherwise git commit -am "Add winpthreads source" # tag the commit with a well-known tag (IIRC, these types of tags are isolated to a single branch so you # likely want some namespacing) git tag winpthreads-0.5.1 # what have I just done? git log --decorate --oneline # make it so git push && git push --tags Regarding git vs. mercurial on windows, I use both on a daily basis, like both, but prefer git. The only performance complaint I've had relates to garbage collection. If you try to `git gc --aggressive --prune=now` a large repo, you'll often find that the gc fails due to memory issues even on my 23GB x64 laptop. This is easily solved by setting the `gc.aggressivewindow` config option to a lower value. I'm interested in hearing what perf issues John E. has run into. -- "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] Shell
On 12/26/13, Vincent Torri wrote: > you can't use windows cmd to run configure scripts. You must use MSYS' > terminal, Cygwin's terminal or other terminals which do the same job. > > regards > > Vincent Torri > > > On Thu, Dec 26, 2013 at 9:26 AM, wrote: >> >> Using the windows cmd box terminal console, then on Win-Buids which is >> using MinGW64. >> How do you compile a source package which comes with a "configure" shell >> script made for the *nix world? >> C:\Users\Jon\Documents\CDev\winpthreads-svn\build>cmd -v Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\Jon\Documents\CDev\winpthreads-svn\build>echo %PATH% C:\Apps\DevTools\msys\bin;C:\Apps\DevTools\mingw\bin;... C:\Users\Jon\Documents\CDev\winpthreads-svn\build>sh --version GNU bash, version 4.2.45(2)-release (x86_64-pc-msys) ... C:\Users\Jon\Documents\CDev\winpthreads-svn\build>sh -c "../configure --build=x86_64-w64-mingw32" checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking for gcc... gcc checking whether the C compiler works... yes ... configure: creating ./config.status config.status: creating Makefile config.status: creating tests/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands C:\Users\Jon\Documents\CDev\winpthreads-svn\build>echo %errorlevel% 0 -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads kill
> > Also: Where should I get the sources for winpthreads? > > http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/ -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 use of MSYSTEM
On Sat, Nov 23, 2013 at 12:55 PM, Alexpux wrote:
>
> 23 нояб. 2013 г., в 13:56, Jon написал(а):
>
> > To confirm, the only effect of setting MSYSTEM (e.g. - setting to MSYS,
> MINGW32, or MINGW64) in an MSYS2 + mingw-w64 environment is (a) uname
> changes its output, and therefore (b) config.guess spews one of the
> following three?
> >
> > ${UNAME_MACHINE}-pc-mingw64
> > ${UNAME_MACHINE}-pc-mingw32
> > ${UNAME_MACHINE}-pc-msys
> >
> In general yes.
> Also if you set MSYSTEM before starting MSYS then /etc/profile uses it for
> setting PATH variable depend on MSYSTEM variable.
> I do it for using toolchains installed with pacman.
>
>
Thank you.
Given that /etc/profile currently sources from /etc/profile.d and it
appears that uname is sensitive to dynamic MSYSTEM changes, I'm
experimenting with a /etc/profile.d/toolchain.sh defining `toolchain ()`
that switches PATH and MSYSTEM values (defaults to MSYS) when used like
toolchain [ls] # list currently selected toolchain
toolchain msys
toolchain mingw32
toolchain mingw64
I prefer this style rather than the current style of having to select a
specific .bat to start the shell.
Once I get something I like, I'll send it to you for review. You can decide
whether you like it enough to include it in MSYS2
Jon
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 use of MSYSTEM
To confirm, the only effect of setting MSYSTEM (e.g. - setting to MSYS,
MINGW32, or MINGW64) in an MSYS2 + mingw-w64 environment is (a) uname
changes its output, and therefore (b) config.guess spews one of the
following three?
${UNAME_MACHINE}-pc-mingw64
${UNAME_MACHINE}-pc-mingw32
${UNAME_MACHINE}-pc-msys
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?
On Mon, Nov 18, 2013 at 4:06 PM, Alexey Pavlov wrote: > > > > 2013/11/19 Jon > >> >> >> On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov wrote: >> >>> >>> >>> >>> 2013/11/19 Jon >>> >>>> >>>> On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem < >>>> vanboxem.ru...@gmail.com> wrote: >>>> >>>>> 2013/11/18 Alexey Pavlov >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2013/11/18 Jon >>>>>> >>>>>>> Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an >>>>>>> awful idea? >>>>>>> >>>>>>> [mingw] >>>>>>> #Server = >>>>>>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/$arch >>>>>>> Server = >>>>>>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64 >>>>>>> >>>>>> >>>>>> $arch specify MSYS architecture >>>>>> This is my experimental repo and I prefer to not install any mingw >>>>>> packages from here while I done it. >>>>>> >>>>>>> >>>>>>> >>>>>>> I don't believe there are any MSYS2 32bit exes or DLLs attempting to >>>>>>> pull in 64bit DLLs from the mingw repo. >>>>>>> >>>>>>> I'm just experimenting at the moment, but I want you understand >>>>>>> if/how MSYS2 will allow mixed configurations or require something like >>>>>>> https://wiki.archlinux.org/index.php/Multilib >>>>>>> >>>>>>> MSYS has not support for multilib. >>>>>> Now I'm working on creating mingw toolchains that can be installed >>>>>> via pacman. >>>>>> I already create two separate bat files in msys root - mingw32_shell >>>>>> and mingw64_shell that switch PATH variable to support mingw toolchains. >>>>>> I will install mingw toolchains into /mingw32 and /mingw64 folders. >>>>>> And they do not conflict in this case. >>>>>> When you run mingw32_shell then PATH=/mingw32/bin:$PATH >>>>>> >>>>> >>>>> Tiny hint on this: why not install them in the usual >>>>> /usr/[bin,]? and use symlinks to switch between the two as >>>>> unprefixed "gcc". Additional bonus: you can use the many Arch PKGBUILDs >>>>> (nearly?) unmodified to provide a ton of 3rd party libraries. Just a >>>>> thought ;-) >>>>> >>>>> >>>>>> >>>>>> >>>>>>> On one hand, it might be nice to be able have a single MSYS2 install >>>>>>> (32 or 64bit) drive EITHER a 32bit OR 64bit toolchain with a switcher >>>>>>> script. Essentially, enable multilib builds at a higher level than gcc's >>>>>>> `-m32` and `-m64` option level. >>>>>>> >>>>>>> I don't plan to provide multilib mingw toolchains for msys >>>>>> repository. You can create your own repo and do what you want) But I add >>>>>> support to install both 32 and 64 bit mingw toolchains in one msys in few >>>>>> days I think. >>>>>> >>>>> >>>>> Multilib is indeed a mess from a packaging standpoint. I chose not to >>>>> go that direction with my Arch stuff. You can check the PKGBUILDs in the >>>>> AUR to see how easy it is to get stuff built, installed, and working in a >>>>> streamlined way. >>>>> >>>>> >>>> My sloppy use of "multilib" was confusingly imprecise. >>>> >>>> I should have said something like "use a single MSYS2 install to be >>>> able to build 32 or 64bit goodies by being able to easily switch between a >>>> 32bit or 64bit mingw-w64 toolchain. I don't want the other form of >>>> multilib. >>>> >>>> I think you're on the right path Alexey and I like the idea of using >>>> symlinks to choose rather than having to start a shell by choosing between >>>> mingw32_shell.bat and mingw64_shell.bat. I'd prefer to start MSYS2 (either >>>> 32bit or 64bit) and then call a script that does the symlink magic. >>>> >>>> As I answer on Ruben mail, I don't support symlinks in default >>> configuration. Now I prefer to use two mount points or folder inside msys - >>> /mingw32 and mingw64. >>> >>> If you want easily switch between toolchains You can write small script >>> that switch PATH variable and set MSYSTEM=MINGW*. It's easily. >>> >> >> I prefer the two mount points /mingw32 and /mingw64 as well. It should >> be easy to write a small script for PATH and MSYSTEM. Maybe even play with >> a script that symlinks /mingw to either /mingw32 or /mingw64. Bad idea? >> >> When will you have a MSYS2 version to test that has the /mingw32 and >> /mingw64 mount point support? >> > > In few days > Fabulous. Whenever you think it's ready I look forward to testing, both from inside a mintty shell and from cmd.exe via sh -c "...". -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?
On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov wrote: > > > > 2013/11/19 Jon > >> >> On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem < >> vanboxem.ru...@gmail.com> wrote: >> >>> 2013/11/18 Alexey Pavlov >>> >>>> >>>> >>>> >>>> 2013/11/18 Jon >>>> >>>>> Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an >>>>> awful idea? >>>>> >>>>> [mingw] >>>>> #Server = >>>>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/$arch >>>>> Server = >>>>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64 >>>>> >>>> >>>> $arch specify MSYS architecture >>>> This is my experimental repo and I prefer to not install any mingw >>>> packages from here while I done it. >>>> >>>>> >>>>> >>>>> I don't believe there are any MSYS2 32bit exes or DLLs attempting to >>>>> pull in 64bit DLLs from the mingw repo. >>>>> >>>>> I'm just experimenting at the moment, but I want you understand if/how >>>>> MSYS2 will allow mixed configurations or require something like >>>>> https://wiki.archlinux.org/index.php/Multilib >>>>> >>>>> MSYS has not support for multilib. >>>> Now I'm working on creating mingw toolchains that can be installed via >>>> pacman. >>>> I already create two separate bat files in msys root - mingw32_shell >>>> and mingw64_shell that switch PATH variable to support mingw toolchains. >>>> I will install mingw toolchains into /mingw32 and /mingw64 folders. And >>>> they do not conflict in this case. >>>> When you run mingw32_shell then PATH=/mingw32/bin:$PATH >>>> >>> >>> Tiny hint on this: why not install them in the usual >>> /usr/[bin,]? and use symlinks to switch between the two as >>> unprefixed "gcc". Additional bonus: you can use the many Arch PKGBUILDs >>> (nearly?) unmodified to provide a ton of 3rd party libraries. Just a >>> thought ;-) >>> >>> >>>> >>>> >>>>> On one hand, it might be nice to be able have a single MSYS2 install >>>>> (32 or 64bit) drive EITHER a 32bit OR 64bit toolchain with a switcher >>>>> script. Essentially, enable multilib builds at a higher level than gcc's >>>>> `-m32` and `-m64` option level. >>>>> >>>>> I don't plan to provide multilib mingw toolchains for msys repository. >>>> You can create your own repo and do what you want) But I add support to >>>> install both 32 and 64 bit mingw toolchains in one msys in few days I >>>> think. >>>> >>> >>> Multilib is indeed a mess from a packaging standpoint. I chose not to go >>> that direction with my Arch stuff. You can check the PKGBUILDs in the AUR >>> to see how easy it is to get stuff built, installed, and working in a >>> streamlined way. >>> >>> >> My sloppy use of "multilib" was confusingly imprecise. >> >> I should have said something like "use a single MSYS2 install to be able >> to build 32 or 64bit goodies by being able to easily switch between a 32bit >> or 64bit mingw-w64 toolchain. I don't want the other form of multilib. >> >> I think you're on the right path Alexey and I like the idea of using >> symlinks to choose rather than having to start a shell by choosing between >> mingw32_shell.bat and mingw64_shell.bat. I'd prefer to start MSYS2 (either >> 32bit or 64bit) and then call a script that does the symlink magic. >> >> As I answer on Ruben mail, I don't support symlinks in default > configuration. Now I prefer to use two mount points or folder inside msys - > /mingw32 and mingw64. > > If you want easily switch between toolchains You can write small script > that switch PATH variable and set MSYSTEM=MINGW*. It's easily. > I prefer the two mount points /mingw32 and /mingw64 as well. It should be easy to write a small script for PATH and MSYSTEM. Maybe even play with a script that symlinks /mingw to either /mingw32 or /mingw64. Bad idea? When will you have a MSYS2 version to test that has the /mingw32 and /mingw64 mount point support? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?
On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem wrote: > 2013/11/18 Alexey Pavlov > >> >> >> >> 2013/11/18 Jon >> >>> Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an >>> awful idea? >>> >>> [mingw] >>> #Server = >>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/$arch >>> Server = >>> https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64 >>> >> >> $arch specify MSYS architecture >> This is my experimental repo and I prefer to not install any mingw >> packages from here while I done it. >> >>> >>> >>> I don't believe there are any MSYS2 32bit exes or DLLs attempting to >>> pull in 64bit DLLs from the mingw repo. >>> >>> I'm just experimenting at the moment, but I want you understand if/how >>> MSYS2 will allow mixed configurations or require something like >>> https://wiki.archlinux.org/index.php/Multilib >>> >>> MSYS has not support for multilib. >> Now I'm working on creating mingw toolchains that can be installed via >> pacman. >> I already create two separate bat files in msys root - mingw32_shell and >> mingw64_shell that switch PATH variable to support mingw toolchains. >> I will install mingw toolchains into /mingw32 and /mingw64 folders. And >> they do not conflict in this case. >> When you run mingw32_shell then PATH=/mingw32/bin:$PATH >> > > Tiny hint on this: why not install them in the usual /usr/[bin,]? > and use symlinks to switch between the two as unprefixed "gcc". Additional > bonus: you can use the many Arch PKGBUILDs (nearly?) unmodified to provide > a ton of 3rd party libraries. Just a thought ;-) > > >> >> >>> On one hand, it might be nice to be able have a single MSYS2 install (32 >>> or 64bit) drive EITHER a 32bit OR 64bit toolchain with a switcher script. >>> Essentially, enable multilib builds at a higher level than gcc's `-m32` and >>> `-m64` option level. >>> >>> I don't plan to provide multilib mingw toolchains for msys repository. >> You can create your own repo and do what you want) But I add support to >> install both 32 and 64 bit mingw toolchains in one msys in few days I think. >> > > Multilib is indeed a mess from a packaging standpoint. I chose not to go > that direction with my Arch stuff. You can check the PKGBUILDs in the AUR > to see how easy it is to get stuff built, installed, and working in a > streamlined way. > > My sloppy use of "multilib" was confusingly imprecise. I should have said something like "use a single MSYS2 install to be able to build 32 or 64bit goodies by being able to easily switch between a 32bit or 64bit mingw-w64 toolchain. I don't want the other form of multilib. I think you're on the right path Alexey and I like the idea of using symlinks to choose rather than having to start a shell by choosing between mingw32_shell.bat and mingw64_shell.bat. I'd prefer to start MSYS2 (either 32bit or 64bit) and then call a script that does the symlink magic. Fantastic so far :) Jon -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?
Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an awful idea? [mingw] #Server = https://sourceforge.net/projects/msys2/files/REPOS/MINGW/$arch Server = https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64 I don't believe there are any MSYS2 32bit exes or DLLs attempting to pull in 64bit DLLs from the mingw repo. I'm just experimenting at the moment, but I want you understand if/how MSYS2 will allow mixed configurations or require something like https://wiki.archlinux.org/index.php/Multilib On one hand, it might be nice to be able have a single MSYS2 install (32 or 64bit) drive EITHER a 32bit OR 64bit toolchain with a switcher script. Essentially, enable multilib builds at a higher level than gcc's `-m32` and `-m64` option level. Horrible idea because impossible or too many corner cases and too hard to maintain, or interesting enough to look into? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 mpfr upgrade via pacman error
> You need rebase dlls. Close MSYS2 and execute autorebase.bat from msys > root directory > Will the dlls always need to be rebased after an upgrade? If not, which specific upgrade scenarios will need a rebase? Perhaps a comment added to autorebase.bat summarizing the scenarios that require rebasing. -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 mpfr upgrade via pacman error
On Sun, Nov 17, 2013 at 1:06 PM, Jon wrote: > $ pacman -Syu > :: Synchronizing package databases... > msys 75.5 KiB 337K/s 00:00 > [] 100% > :: Starting full system upgrade... > resolving dependencies... > looking for conflicting packages... > > Packages (4) bash-4.2.045-3 mpfr-3.1.2.p4-1 msys2-base-1.1-2 > pacman-4.1.2..6ed8784-1 > > Total Download Size:1.46 MiB > Total Installed Size: 7.89 MiB > Net Upgrade Size: -0.12 MiB > > :: Proceed with installation? [Y/n] > :: Retrieving packages ... > bash-4.2.045-3-i686 666.0 KiB 814K/s 00:01 > [] 100% > mpfr-3.1.2.p4-1-i686 220.0 KiB 348K/s 00:01 > [] 100% > msys2-base-1.1-2-any 19.8 KiB 227K/s 00:00 > [] 100% > pacman-4.1.2..6ed87... 585.6 KiB 479K/s 00:01 > [] 100% > (4/4) checking keys in keyring > [] 100% > (4/4) checking package integrity > [] 100% > (4/4) loading package files > [] 100% > (4/4) checking for file conflicts > [] 100% > (4/4) checking available disk space > [] 100% > (1/4) upgrading bash > [] 100% > (2/4) upgrading mpfr > [] 100% > 1 [main] pacman 3328 child_info_fork::abort: > C:\Apps\msys32\bin\msys-lzo2-2.dll: Loaded to different address: > parent(0x36) != child(0x3D) > error: could not fork a new process (Resource temporarily unavailable) > (3/4) upgrading msys2-base > [########] 100% > (4/4) upgrading pacman > [] 100% > After the above upgrade, this also occurs: Jon@Black ~ $ pacman -Su warning: database file for 'mingw' does not exist :: Starting full system upgrade... there is nothing to do Jon@Black ~ $ pacman -Syu :: Synchronizing package databases... error: failed retrieving file 'mingw.db' from sourceforge.net : The requested URL returned error: 404 Not Found error: failed to update mingw (download library error) msys is up to date :: Starting full system upgrade... there is nothing to do Jon@Black ~ $ ping sourceforge.net Pinging sourceforge.net [216.34.181.60] with 32 bytes of data: Reply from 216.34.181.60: bytes=32 time=71ms TTL=242 Reply from 216.34.181.60: bytes=32 time=63ms TTL=242 Reply from 216.34.181.60: bytes=32 time=66ms TTL=242 Reply from 216.34.181.60: bytes=32 time=64ms TTL=242 Ping statistics for 216.34.181.60: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 63ms, Maximum = 71ms, Average = 66ms -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 mpfr upgrade via pacman error
$ pacman -Syu :: Synchronizing package databases... msys 75.5 KiB 337K/s 00:00 [] 100% :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... Packages (4) bash-4.2.045-3 mpfr-3.1.2.p4-1 msys2-base-1.1-2 pacman-4.1.2..6ed8784-1 Total Download Size:1.46 MiB Total Installed Size: 7.89 MiB Net Upgrade Size: -0.12 MiB :: Proceed with installation? [Y/n] :: Retrieving packages ... bash-4.2.045-3-i686 666.0 KiB 814K/s 00:01 [] 100% mpfr-3.1.2.p4-1-i686 220.0 KiB 348K/s 00:01 [] 100% msys2-base-1.1-2-any 19.8 KiB 227K/s 00:00 [] 100% pacman-4.1.2..6ed87... 585.6 KiB 479K/s 00:01 [] 100% (4/4) checking keys in keyring [] 100% (4/4) checking package integrity [] 100% (4/4) loading package files [] 100% (4/4) checking for file conflicts [] 100% (4/4) checking available disk space [] 100% (1/4) upgrading bash [] 100% (2/4) upgrading mpfr [] 100% 1 [main] pacman 3328 child_info_fork::abort: C:\Apps\msys32\bin\msys-lzo2-2.dll: Loaded to different address: parent(0x36) != child(0x3D) error: could not fork a new process (Resource temporarily unavailable) (3/4) upgrading msys2-base [] 100% (4/4) upgrading pacman [] 100% -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] changing a DLLs load-time dynamic link dependency
On Fri, Nov 15, 2013 at 3:56 AM, Kai Tietz wrote: > 2013/11/15 Jon : > > After skimming LRN's ntldd https://github.com/LRN/ntldd tool, reading > tinype > > again http://www.phreedom.org/research/tinype/ and updating my upx > > http://upx.sourceforge.net/ I'm curious if binary tweaks to mingw built > DLLs > > (e.g. - libffi, libxml2, etc) could easily solve one of the mingw/VC++ > > integration issues. > > > > Specifically, the using-the-same-msvcrt-version issue. Mingw GCC's > default > > to linking against msvcrt.dll and the VC++ compilers link to other > versions > > depending up toolchain version. > > > > The only "fix" I'm aware of is creative use of GCC spec files when > building > > from source. One day I'll find time to swing back to work on my > > symlink-to-multiple-spec-files hack, but there's also the missing .a file > > concern. > > > > Could an easier solution be to simply build your DLL library (e.g. - > libffi) > > with GCC that load-time dynamic links to msvcrt.dll, then munge the PE > > format to replace the reference to msvcrt.dll (a string?) to say > > msvcr120.dll (another string?) and then fixup all effected > > references/addresses in the DLL library? > > > > Essentially build a tool that creates binary copies of the original > > msvcrt.dll load-time linked DLL that switches the load-time link info to > > reference another msvcr*.dll version. Nothing else. Similar to working in > > the frequency domain rather than the time domain. > > > > Completely bypass source and spec file issues and just generate slightly > > tweaked clones of your original DLL. > > > > I've not spent enough time with the PE format or the MSFT system DLL > Export > > Address tables, dynamic linker, ordinals, et al to know if this idea is > DOA, > > but it's highly likely some of you know. > > > > I'm making a lot of assumptions, but what are the showstoppers to this > idea? > > Anyone tried this, working on this, or know of a tool (binutils?) that > > already does this? RTFM links to get smarter? > > > > Thanks, Jon > > To introduce delayed-loading isn't working 100%. The > none-function-imports especially making troubles here. Well, for > proper decorated "dllimport"-ed symbols it works. Nevertheless are > all feature of auto-import not working (pseudo-relocation etc). > > IMHO it would be easier to write a tool, which modifies the PE-header > of a DLL/EXE. > > Regards, > Kai > > Ah, so if I'm trying to change from this scenario exe (VC++) --> DLL (mingw-w64) --> msvcrt.dll to this scenario via binary hacks to the DLL exe (VC++) --> DLL (mingw-w64) --> msvcr110.dll are you saying I need to learn how to modify the PE header of *only* the mingw-w64 DLL, or are you saying *both* the DLL and exe PE headers need to be modified? Also, are you saying that the VC++ exe should *not* be delay load linked (i.e. - no /DELAYLOAD linker option) because this doesn't work reliably? I'm also assuming if I'm able to build this Frankenstein mingw-w64 DLL linked with msvcr110.dll not msvcrt.dll, I could still use pexports or gendef to create the .def required by VC++'s lib tool to create the import lib needed to link to the new mingw-w64 DLL that is linked to msvcr110.dll. Correct? Another wacky idea...is it possible to create a custom linker script https://sourceware.org/binutils/docs/ld/Scripts.html#Scripts that could persuade ld and its binutils friends to do this rewriting as part of its job of creating the mingw-w64 DLL? Jon -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] changing a DLLs load-time dynamic link dependency
After skimming LRN's ntldd https://github.com/LRN/ntldd tool, reading tinype again http://www.phreedom.org/research/tinype/ and updating my upx http://upx.sourceforge.net/ I'm curious if binary tweaks to mingw built DLLs (e.g. - libffi, libxml2, etc) could easily solve one of the mingw/VC++ integration issues. Specifically, the using-the-same-msvcrt-version issue. Mingw GCC's default to linking against msvcrt.dll and the VC++ compilers link to other versions depending up toolchain version. The only "fix" I'm aware of is creative use of GCC spec files when building from source. One day I'll find time to swing back to work on my symlink-to-multiple-spec-files hack, but there's also the missing .a file concern. Could an easier solution be to simply build your DLL library (e.g. - libffi) with GCC that load-time dynamic links to msvcrt.dll, then munge the PE format to replace the reference to msvcrt.dll (a string?) to say msvcr120.dll (another string?) and then fixup all effected references/addresses in the DLL library? Essentially build a tool that creates binary copies of the original msvcrt.dll load-time linked DLL that switches the load-time link info to reference another msvcr*.dll version. Nothing else. Similar to working in the frequency domain rather than the time domain. Completely bypass source and spec file issues and just generate slightly tweaked clones of your original DLL. I've not spent enough time with the PE format or the MSFT system DLL Export Address tables, dynamic linker, ordinals, et al to know if this idea is DOA, but it's highly likely some of you know. I'm making a lot of assumptions, but what are the showstoppers to this idea? Anyone tried this, working on this, or know of a tool (binutils?) that already does this? RTFM links to get smarter? Thanks, Jon -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 correct HOME setup
On Wed, Nov 13, 2013 at 3:53 PM, Alexpux wrote: > > 14 нояб. 2013 г., в 0:48, Jon написал(а): > > > On Wed, Nov 13, 2013 at 3:36 PM, Alexpux wrote: > >> >> 14 нояб. 2013 г., в 0:31, Jon написал(а): >> >> I'm an old cygwin user who went astray years ago and would like to >> confirm my MSYS2 setup. >> >> Here's what I'm doing to have a sandboxed style setup that isolates my >> normal windows setup. For example, I don't want MSYS2's default >> /etc/profile to think HOME is C:\Users\Jon. I want it to think HOME is >> %MSYS_INSTALL_DIR%/home/Jon and use/modify files in that location. >> >> 1) Create a desktop shortcut with >> >> C:\Windows\System32\cmd.exe /e:on /v:on /k C:\Apps\msys32\msys2_shell.bat >> >> >> 2) Modify MSYS2's msys2_shell.bat to include >> >> set HOME=%~dp0home\Jon >> >> >> You don’t need it. >> >> >> >> 3) Place the mingw-w64 official toolchain in C:\Apps\DevTools\mingw >> (actually it's a windows directory symlink to >> C:\Apps\DevTools\toolchains\mingwbuilds-64-4.8.2) >> >> >> 4) Update /etc/fstab to include >> >> C:/Apps/DevTools/mingw /usr/local/mingw >> >> >> It seems to be OK, but there's one oddity I've found so far. When I use >> the shortcut, I'm dumped in `~` which pwd's to /usr/home/Jon. When I `cd ~` >> I'm told I'm in /home/Jon and pwd shows the same thing. Also, my >> /etc/passwd entry shows /home/Jon. >> >> I suspect this is just cygwin's aliasing magic making things nicer for >> me. But I want to check that my HOME update in msys2_shell.bat should be OK. >> >> >> You have HOME=/home/user by default without needed any changes. >> >> *$ echo $HOME* >> */home/alexey* >> >> >> > Not in my case, and the default hammers my existing > %HOMEPATH%%HOMEDIR%/.bash_history. > > Perhaps I have something else clobbering the setup? > > Jon@Black ~ > $ pwd > /c/Users/Jon > > Jon@Black ~ > $ cd $HOME > > Jon@Black ~ > $ pwd > /c/Users/Jon > > Jon@Black ~ > $ echo $HOME > /c/Users/Jon > > Jon@Black ~ > $ cd ~ > > Jon@Black /home/Jon > $ pwd > /home/Jon > > > > Probably you have %HOME% variable in system environment. > > Facepalm. Thought I checked that. C:\>set H HOME=C:\Users\Jon HOMEDRIVE=C: HOMEPATH=\Users\Jon Sorry for the noise Alexey :( -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 correct HOME setup
> Jon@Black ~ > $ cd ~ > > Jon@Black /home/Jon > $ pwd > /home/Jon > Sorry, the above is not correct in the default case. The correct version is: Jon@Black ~ $ cd ~ -bash: cd: /home/Jon: No such file or directory Jon@Black ~ $ pwd /c/Users/Jon My earlier experiments with HOME in msys2_shell.bat had created /home/Jon and populated it from /etc/skel. The creation of /home/Jon and use of /etc/skel didn't happen when I first started (and restarted) MSYS2 with the default. -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 correct HOME setup
On Wed, Nov 13, 2013 at 3:36 PM, Alexpux wrote: > > 14 нояб. 2013 г., в 0:31, Jon написал(а): > > I'm an old cygwin user who went astray years ago and would like to confirm > my MSYS2 setup. > > Here's what I'm doing to have a sandboxed style setup that isolates my > normal windows setup. For example, I don't want MSYS2's default > /etc/profile to think HOME is C:\Users\Jon. I want it to think HOME is > %MSYS_INSTALL_DIR%/home/Jon and use/modify files in that location. > > 1) Create a desktop shortcut with > > C:\Windows\System32\cmd.exe /e:on /v:on /k C:\Apps\msys32\msys2_shell.bat > > > 2) Modify MSYS2's msys2_shell.bat to include > > set HOME=%~dp0home\Jon > > > You don’t need it. > > > > 3) Place the mingw-w64 official toolchain in C:\Apps\DevTools\mingw > (actually it's a windows directory symlink to > C:\Apps\DevTools\toolchains\mingwbuilds-64-4.8.2) > > > 4) Update /etc/fstab to include > > C:/Apps/DevTools/mingw /usr/local/mingw > > > It seems to be OK, but there's one oddity I've found so far. When I use > the shortcut, I'm dumped in `~` which pwd's to /usr/home/Jon. When I `cd ~` > I'm told I'm in /home/Jon and pwd shows the same thing. Also, my > /etc/passwd entry shows /home/Jon. > > I suspect this is just cygwin's aliasing magic making things nicer for me. > But I want to check that my HOME update in msys2_shell.bat should be OK. > > > You have HOME=/home/user by default without needed any changes. > > *$ echo $HOME* > */home/alexey* > > > Not in my case, and the default hammers my existing %HOMEPATH%%HOMEDIR%/.bash_history. Perhaps I have something else clobbering the setup? Jon@Black ~ $ pwd /c/Users/Jon Jon@Black ~ $ cd $HOME Jon@Black ~ $ pwd /c/Users/Jon Jon@Black ~ $ echo $HOME /c/Users/Jon Jon@Black ~ $ cd ~ Jon@Black /home/Jon $ pwd /home/Jon -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 correct HOME setup
I'm an old cygwin user who went astray years ago and would like to confirm my MSYS2 setup. Here's what I'm doing to have a sandboxed style setup that isolates my normal windows setup. For example, I don't want MSYS2's default /etc/profile to think HOME is C:\Users\Jon. I want it to think HOME is %MSYS_INSTALL_DIR%/home/Jon and use/modify files in that location. 1) Create a desktop shortcut with C:\Windows\System32\cmd.exe /e:on /v:on /k C:\Apps\msys32\msys2_shell.bat 2) Modify MSYS2's msys2_shell.bat to include set HOME=%~dp0home\Jon 3) Place the mingw-w64 official toolchain in C:\Apps\DevTools\mingw (actually it's a windows directory symlink to C:\Apps\DevTools\toolchains\mingwbuilds-64-4.8.2) 4) Update /etc/fstab to include C:/Apps/DevTools/mingw /usr/local/mingw It seems to be OK, but there's one oddity I've found so far. When I use the shortcut, I'm dumped in `~` which pwd's to /usr/home/Jon. When I `cd ~` I'm told I'm in /home/Jon and pwd shows the same thing. Also, my /etc/passwd entry shows /home/Jon. I suspect this is just cygwin's aliasing magic making things nicer for me. But I want to check that my HOME update in msys2_shell.bat should be OK. -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New to Mingw-w64 looking for Links, Tutorials, advice from the community
On Tue, Nov 12, 2013 at 2:47 PM, ResQue wrote: > Hello all > > New to Mingw-w64 looking for Links, Tutorials, advice from the community? > > 1) Put yourself in an adventurous mindset that tolerates ambiguity. You may have to be more patient than you'd like and may have to reign in the "I just want to build sh*t now!" urge. >;-> Trust me, the time you spend investing in understanding more about your tools, the better the payoff in the mid and long term. 2) Since you're new to mingw-w64, move the the front edge and focus on the new MSYS2 and the new official binary toolchain downloads for windows. Combine them into a workable toolchain that you can place on `PATH` and use to build from the command line. For example, assuming you have a 64-bit windows system, these will be interesting: http://sourceforge.net/projects/msys2/files/Base/i686/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-win32/seh/ Don't allow yourself to get stuck for too long setting up the toolchain. The goal is to learn by doing, but it shouldn't be so frustrating that you give up and walk away. Try it on your own, but when you're stuck, create a short, descriptive email and post it hear to ask for help. If your main dev box is not windows, you'll need to set up a cross compiling toolchain. 3) Use pacman included in the update MSYS2 to customize MSYS2 so that it can build many open source packages https://wiki.archlinux.org/index.php/pacman 4) Once you've confirmed you've got an operational toolchain, pick an open source package of interest and learn to build it. Pick software that you actually have a need to use. Of course, DuckDuckGo and other spelunking techniques will help, but also check out how others have automated builds paying particular attention to their use of `configure` and `make`. For example: https://www.gitorious.org/sbuild/sbuild/source/a8f47daae77bb2390843250fbe6445fed784d866:src/mingw/libarchive-3.1.2-2/pkgbuild.sh#L284-303 https://github.com/jonforums/buildlets/blob/master/build_libiconv.ps1#L44-L57 https://www.gitorious.org/sbuild/sbuild/source/a8f47daae77bb2390843250fbe6445fed784d866:src/mingw/libiconv-1.14-2/pkgbuild.sh#L306-324 http://cgit.notk.org/adrien/yypkg/slackware64-current.git/tree/l/libffi/libffi.SlackBuild https://github.com/jonforums/buildlets/blob/master/build_zlib.ps1 5) Once you've got a working toolchain and are familiar with `configure`, `make`, `gcc` and have built a few things, I ask that you blog about your mingw-w64 set up as well as post a message (link to your blog) with "tutorial" in the title. Even if you don't have a blog, a tutorial email to this list would be awesome. Hopefully others will share some of their hard won "secrets" :) It's a great thing you're a newcomer to mingw-w64 and I'd love to see this project get the benefit of a tutorial based upon your adventurous ramp up. Tutorial style documentation is lacking and many of us take for granted the challenges of setting up a workable toolchain for the first time. Jon -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 BASE package selection
Understood. I think a vote is a bad idea because everyone has their favorite they'd like to see in BASE. By accommodating too many favorites and trying to please all of us, BASE will become too large. The beauty of pacman is that it is easy for any of use to enhance BASE to ones specific needs. That said, I believe autoconf, automake, and libtool belong in BASE because they're almost always used to build open source code. I'm advocating for their inclusion. I have an alternate suggestion to voting. See who responds to this issue and *you* make the final decision on the tradeoffs between convenience and size. I trust your instincts and choices. Since we now have pacman (thank you!) there's very little downside. :) On Tue, Nov 12, 2013 at 2:56 PM, Alexey Pavlov wrote: > > > > 2013/11/12 Jon > >> Why were the following packages not selected for inclusion in this >> version of the BASE download? >> >> msys autoconf 2.69-1 >> msys automake 1.14-1 >> msys libtool 2.4.2-1 >> >> > There are many candidates to BASE group but need to understand that it > increase size. > > I want to suggest to vote for the packages to be in the base system. > > You can view all packages that repo has by: > > pacman -Ss > > > > >> >> -- >> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps >> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access >> Free app hosting. Or install the open source package on any LAMP server. >> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> > > > -- > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 BASE package selection
Why were the following packages not selected for inclusion in this version of the BASE download? msys autoconf 2.69-1 msys automake 1.14-1 msys libtool 2.4.2-1 -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
Oh Alexey you madcap. And in honor of Get to Know Your Inner Scot Day, let me be the first to shout a hearty FUCK YES. Oh hell, JonY's going to ban me... # setup a desktop shortcut with `C:\Windows\System32\cmd.exe /e:on /v:on /k C:\Apps\msys32\msys2_shell.bat`...yea mintty options! ...and: Jon@Black ~ $ pacman -Syu :: Synchronizing package databases... msys is up to date :: Starting full system upgrade... there is nothing to do Jon@Black ~ $ pacman -Sl ...[SNIP]... msys bash 4.2.045-1 [installed] msys bash-completion 2.1-1 [installed] ...[SNIP]... msys xz 5.0.5-1 Jon@Black ~ $ pacman -S xz resolving dependencies... looking for conflicting packages... Packages (1) xz-5.0.5-1 Total Download Size: 0.12 MiB Total Installed Size: 0.85 MiB :: Proceed with installation? [Y/n] :: Retrieving packages ... xz-5.0.5-1-i686 118.5 KiB 95.4K/s 00:01 [] 100% (1/1) checking keys in keyring [] 100% (1/1) checking package integrity [] 100% (1/1) loading package files [] 100% (1/1) checking for file conflicts [] 100% (1/1) checking available disk space [] 100% (1/1) installing xz [] 100% warning: directory ownership differs on /usr/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/bin/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/doc/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/man/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/man/man1/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/cs/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/de/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/fr/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/it/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/pl/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/pl/LC_MESSAGES/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/it/LC_MESSAGES/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/fr/LC_MESSAGES/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/de/LC_MESSAGES/ filesystem: 1002:513 package: 1000:513 warning: directory ownership differs on /usr/share/locale/cs/LC_MESSAGES/ filesystem: 1002:513 package: 1000:513 Jon@Black ~ $ xz --version xz (XZ Utils) 5.0.5 liblzma 5.0.5 Jon@Black ~ $ pacman -Q | grep xz xz 5.0.5-1 On Tue, Nov 12, 2013 at 7:43 AM, Alexpux wrote: > > 12 нояб. 2013 г., в 16:36, Óscar Fuentes написал(а): > > > Hello Alexey, > > > > Alexey Pavlov writes: > > > >> Today I want to announce that MSYS2 now has console package manager - > >> pacman that is ported from Arch Linux. I'm still working on porting > pacman > >> but it work in general. > > > > It worked correctly here with > > > > $ pacman -Sy > > > > $ pacman -S git > > > > > > > > $ git --version > > git version 1.8.4.3 > > > > There were lots of warnings on pacman's output, like this: > > > > atención: directory ownership differs on /usr/ > > filesystem: 1003:513 package: 1000:513 > > atención: directory ownership differs on /usr/bin/ > > filesystem: 1003:513 package: 1000:513 > > > > "atención" here means "warning». > > Sorry, I don’t see this warnings but I try to investigate. > > > > > This is a great addition. I was a bit wary of MSYS2 size and coverage > > (it contained too much stuff that I'll never use and can conflict with > > other installed software) but now I have no excuse for delaying the > > switch to MSYS2. Thanks so much. > > > > > > > -- > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > Explore > > techniques for threading, error checking, porting, and tuning. Get the > most > > from the latest Intel processors and coprocessor
Re: [Mingw-w64-public] MSYS2 discussions OT for this list?
On Sat, Nov 9, 2013 at 12:11 PM, Alexpux wrote: > > 09 нояб. 2013 г., в 8:45, Jon написал(а): > > After reviewing sbuild's use of MSYS2 artifacts to provide toolchains and > then some > > > https://www.gitorious.org/sbuild/sbuild/source/a8f47daae77bb2390843250fbe6445fed784d866:buildall.py#L33-149 > > I have MSYS2 related questions for LRN, Alexey, and others on this list > who may be involved with MSYS2 and care to provide feedback. > > That said, this ML is targeted to mingw-w64 issues rather than general > issues best addressed at places like stackoverflow. > > My questions relate to assembling of a development toolkit similar to what > I did when I was contributing to this project: > > > https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68 > > https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingwbuilds.rb > > I plan to do something similar for my buildlets pet project > > https://github.com/jonforums/buildlets > > but base the automated toolchain builds upon assembling a minimal set of > MSYS2 artifacts (smaller than sbuild's and Alexey's full-featured MSYS2 > project) with nixMan and Alexey's official mingw-w64 toolchains for windows. > > > Just now I work on creating MSYS2 repository based on ported Arch Linux > pacman (package manager). In a week, I think, I upload repository to site > and you can get only what you want. In next MSYS2 release I plan to add > packman as package manager for MSYS2. Then you can update, install and > uninstall MSYS2 packages from MSYS2 console when you need. > > Alexey, you continue to amaze :) My primary non-windows OS is Arch followed by Ubuntu Server. Hearing about your plans for a pacman port is, well, spectactular. I'm a bit speechless, but grinning ear to ear. I can't wait to play with your pacman + MSYS2 repo and see how I can integrate it into my powershell based buildlet pet project. Dammit...another very cool siren song to distract and consume free time >;-> -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 discussions OT for this list?
After reviewing sbuild's use of MSYS2 artifacts to provide toolchains and then some https://www.gitorious.org/sbuild/sbuild/source/a8f47daae77bb2390843250fbe6445fed784d866:buildall.py#L33-149 I have MSYS2 related questions for LRN, Alexey, and others on this list who may be involved with MSYS2 and care to provide feedback. That said, this ML is targeted to mingw-w64 issues rather than general issues best addressed at places like stackoverflow. My questions relate to assembling of a development toolkit similar to what I did when I was contributing to this project: https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68 https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingwbuilds.rb I plan to do something similar for my buildlets pet project https://github.com/jonforums/buildlets but base the automated toolchain builds upon assembling a minimal set of MSYS2 artifacts (smaller than sbuild's and Alexey's full-featured MSYS2 project) with nixMan and Alexey's official mingw-w64 toolchains for windows. Kai or JonY...is this primarily MSYS2 topic out-of-scope for this ML and I should directly contact LRN and Alexey? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [OT] stand alone git aware patch tool for windows?
>> What is patch not doing that you want? It should be able to > >> handle git diff output if you pass the magic -p option or modify > >> the resulting diff a bit. > >> > >> > > I need a no-install exe that can apply both git and unified style > > patches as-is without requiring manual tweaks to the patch. > > Generating diffs isn't a concern. > > > > Good point, I'll play again with > > http://sourceforge.net/projects/gnuwin32/files/patch/2.5.9-7/ with > > some git style patches. > > AFAIK, GNU patch is able to apply patches that git format-patch > produces. So a statically-linked version of it would do the trick, i > imagine. > > I hope so. But that would mean either my memory is bad or I've been far too lazy ;) > > Personally, i use Python as a base for such things. Python and a > minimal 20MB subset of MSYS2 packages (wget, tar, xz) that require no > installation or setup. > > Nice. I see I need to look at your sbuild project again to see what clever things you're doing to subset MSYS2. One day buildlets is going to sprout a toolchain buildlet that downloads and assembles minimal MSYS2 plus mingwbuilds-based 32 and 64bit toolchains for those who don't already have a favorite toolchain installed. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [OT] stand alone git aware patch tool for windows?
On Fri, Nov 8, 2013 at 11:12 AM, Ruben Van Boxem wrote: > 2013/11/8 Jon > >> Largely irrelevant these days given how well git and mercurial run on >> windows, but is anyone aware of a self-contained patch exe that runs on >> windows and understands both unified diffs and git diffs? >> >> The goal is to have a simple, single file, no dependency patching tool >> for use with automated build recipes like a few of you maintain. Last time >> I looked the gnuwin32 `patch` port didn't support git style diffs. >> >> I'd thought of spelunking the git or mercurial source to try to extract >> the `git apply` or `hg import` functionality into a single exe, but other >> siren songs have been more distracting. >> > > Don't bother. There are a thousand ways of getting git to give you a diff. > See e.g. here for tips: > http://stackoverflow.com/questions/4610744/can-i-get-a-patch-compatible-output-from-git-diff > > What is patch not doing that you want? It should be able to handle git > diff output if you pass the magic -p option or modify the resulting diff a > bit. > > I need a no-install exe that can apply both git and unified style patches as-is without requiring manual tweaks to the patch. Generating diffs isn't a concern. Good point, I'll play again with http://sourceforge.net/projects/gnuwin32/files/patch/2.5.9-7/ with some git style patches. Essentially, I'm giving into my OCD quest for the "perfect" source build recipe framework on windows. For example, my buildlets toy project https://github.com/jonforums/buildlets/blob/master/README.md has minimal pre-install requirements and it iteratively bootstaps itself and its tools, eg - 7za. A user downloads the bootstrap script via curl, wget, or a powershell one-liner, runs the bootstrap script which downloads needed tools and desired buildlets. Then run the buildlet which downloads source and builds x32 or x64 and a SHA1 checksum. Done. Other than requiring a ming/mingw-w64 based toolchain and a `toolchain.json` config file describing the toolchains, there's not much other pre-install work required beyond having powershell 3.0+ and .NET v3.5+ installed. Next step is to add true patching capability because this is, well, a bit too lame to call patching: https://github.com/jonforums/buildlets/blob/master/build_openssl.ps1#L61-L65 I'm close to just requiring the user to have git installed and use `git apply` when necessary on a library of patches similar to what Alexey and nixMan maintain. What I really want is a self contained patch tool as part of the project living in https://github.com/jonforums/buildlets/tree/master/tools that gets "download installed" as part of the current bootstrapping process. It needs to comprehend any unified or git style diff I create or hijack from Alexey and others ;) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [OT] stand alone git aware patch tool for windows?
Largely irrelevant these days given how well git and mercurial run on windows, but is anyone aware of a self-contained patch exe that runs on windows and understands both unified diffs and git diffs? The goal is to have a simple, single file, no dependency patching tool for use with automated build recipes like a few of you maintain. Last time I looked the gnuwin32 `patch` port didn't support git style diffs. I'd thought of spelunking the git or mercurial source to try to extract the `git apply` or `hg import` functionality into a single exe, but other siren songs have been more distracting. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] conflicting EXCEPTION_REGISTRATION types with tcl/tk 8.6.1
the link to the tcltk buildlet
https://github.com/jonforums/buildlets/blob/master/build_tcltk.ps1#L79-L80
On Thu, Nov 7, 2013 at 10:41 PM, Jon wrote:
> While updating my powershell-based build recipes ("buildlets") for 64-bit
> and other things, I get the following build errors on Win8.1 64bit using
> `x64-msys2-20131022.tar.xz` and the mingw32-make reloaded version of
> `x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z`.
>
> No errors when using mingw.org msys and the older mingwbuilds
> `x32-4.7.3-release-win32-sjlj-rev1.7z` toolchain.
>
> The only mildly interesting part of the buildlet is addressing the
> `config.guess` problem of not being able to guess the `x86_64-w64-mingw32`
> system type. But it appears irrelevant to what looks to be a mingw-w64
> header issue.
>
> mingw-w64 header issue, or tcl/tk issue, or something I've messed up in
> the config?
>
>
>
> PS buildlets-git> .\build_tcltk.ps1 8.6.1 -x64
> ---> validating tcl8.6.1-src.tar.gz
> ---> validating tk8.6.1-src.tar.gz
> ---> extracting tcl8.6.1-src.tar.gz
> ---> extracting tk8.6.1-src.tar.gz
> ---> activating toolchain [64-bit]
> ---> configuring tcl8.6.1 [64-bit]
> ---> building tcl8.6.1 [64-bit]
> C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWin32Dll.c:42:3:
> error: conflicting
> types for 'EXCEPTION_REGISTRATION'
> } EXCEPTION_REGISTRATION;
>^
> In file included from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\minwindef.h:146:0,
> from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windef.h:8,
> from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windows.h:69,
> from
> C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/win/tclWinPort.h:36,
> from
> C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/generic/tclPort.h:21,
> from
> C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/generic/tclInt.h:36,
> from
> C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWinInt.h:15,
> from
> C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWin32Dll.c:14:
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\winnt.h:3554:43: note:
> previous declaration
> of 'EXCEPTION_REGISTRATION' was here
> typedef EXCEPTION_REGISTRATION_RECORD EXCEPTION_REGISTRATION;
> ^
> make: *** [tclWin32Dll.o] Error 1
>
> ...[SNIP]...
>
> ---> activating toolchain [64-bit]
> ---> configuring tk8.6.1 [64-bit]
> ---> building tk8.6.1 [64-bit]
> C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin32Dll.c:30:3:
> error: conflicting types for 'EXCEPTION_REGISTRATION'
> } EXCEPTION_REGISTRATION;
>^
> In file included from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\minwindef.h:146:0,
> from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windef.h:8,
> from
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windows.h:69,
> from
> C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin.h:36,
> from
> C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWinInt.h:26,
> from
> C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin32Dll.c:12:
> c:\apps\devtools\mingw\x86_64-w64-mingw32\include\winnt.h:3554:43: note:
> previous declaration
> of 'EXCEPTION_REGISTRATION' was here
> typedef EXCEPTION_REGISTRATION_RECORD EXCEPTION_REGISTRATION;
>^
> make: *** [tkWin32Dll.o] Error 1
>
>
>
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] conflicting EXCEPTION_REGISTRATION types with tcl/tk 8.6.1
While updating my powershell-based build recipes ("buildlets") for 64-bit
and other things, I get the following build errors on Win8.1 64bit using
`x64-msys2-20131022.tar.xz` and the mingw32-make reloaded version of
`x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z`.
No errors when using mingw.org msys and the older mingwbuilds
`x32-4.7.3-release-win32-sjlj-rev1.7z` toolchain.
The only mildly interesting part of the buildlet is addressing the
`config.guess` problem of not being able to guess the `x86_64-w64-mingw32`
system type. But it appears irrelevant to what looks to be a mingw-w64
header issue.
mingw-w64 header issue, or tcl/tk issue, or something I've messed up in the
config?
PS buildlets-git> .\build_tcltk.ps1 8.6.1 -x64
---> validating tcl8.6.1-src.tar.gz
---> validating tk8.6.1-src.tar.gz
---> extracting tcl8.6.1-src.tar.gz
---> extracting tk8.6.1-src.tar.gz
---> activating toolchain [64-bit]
---> configuring tcl8.6.1 [64-bit]
---> building tcl8.6.1 [64-bit]
C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWin32Dll.c:42:3:
error: conflicting
types for 'EXCEPTION_REGISTRATION'
} EXCEPTION_REGISTRATION;
^
In file included from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\minwindef.h:146:0,
from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windef.h:8,
from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windows.h:69,
from
C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/win/tclWinPort.h:36,
from
C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/generic/tclPort.h:21,
from
C:/Users/Jon/Documents/CDev/buildlets-git/tcl8.6.1/generic/tclInt.h:36,
from
C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWinInt.h:15,
from
C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWin32Dll.c:14:
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\winnt.h:3554:43: note:
previous declaration
of 'EXCEPTION_REGISTRATION' was here
typedef EXCEPTION_REGISTRATION_RECORD EXCEPTION_REGISTRATION;
^
make: *** [tclWin32Dll.o] Error 1
...[SNIP]...
---> activating toolchain [64-bit]
---> configuring tk8.6.1 [64-bit]
---> building tk8.6.1 [64-bit]
C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin32Dll.c:30:3:
error: conflicting types for 'EXCEPTION_REGISTRATION'
} EXCEPTION_REGISTRATION;
^
In file included from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\minwindef.h:146:0,
from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windef.h:8,
from
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\windows.h:69,
from
C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin.h:36,
from
C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWinInt.h:26,
from
C:\Users\Jon\Documents\CDev\buildlets-git\tk8.6.1\win\tkWin32Dll.c:12:
c:\apps\devtools\mingw\x86_64-w64-mingw32\include\winnt.h:3554:43: note:
previous declaration
of 'EXCEPTION_REGISTRATION' was here
typedef EXCEPTION_REGISTRATION_RECORD EXCEPTION_REGISTRATION;
^
make: *** [tkWin32Dll.o] Error 1
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw32-make errors in mingw-w64 25.09.2013, rev2 toolchain
Thanks Alexey. I can now build gvim.exe and xxd.exe with the mingw32-make repack of `x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z` On Wed, Oct 2, 2013 at 10:21 AM, Jon wrote: > On Win8 64bit using the recent mingw-w64 binary toolchain > `x86_64-4.8.1-release-win32-seh-rt_v3-rev2.7z` to build vim from source, I > see the following errors due to mingw32-make behavior: > > C:\Apps\vim-hg>gcc --version > gcc (rev2, Built by MinGW-W64 project) 4.8.1 > ... > > C:\Apps\vim-hg\src>mingw32-make -f Make_ming.mak gvim.exe xxd/xxd.exe > mkdir gobjnative > mingw32-make: Interrupt/Exception caught (code = 0xc005, addr = > 0x07FCE1A9296F) > > OK, ignore and try again... > > C:\Apps\vim-hg\src>mingw32-make -f Make_ming.mak gvim.exe xxd/xxd.exe > gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 > -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT > -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME > -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 > -fomit-frame-pointer -freg-struct-return -s blowfish.c -o > gobjnative/blowfish.o > gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 > -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT > -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME > -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 > -fomit-frame-pointer -freg-struct-return -s buffer.c -o gobjnative/buffer.o > ... > gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 > -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT > -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME > -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 > -fomit-frame-pointer -freg-struct-return -s os_w32exe.c -o > gobjnative/os_w32exe.o > mingw32-make: Interrupt/Exception caught (code = 0xc005, addr = > 0x07FCE1A9296F) > > These errors do not occur when: > > a) I do a 32bit build using mingw32-make from the mingwbuilds 4.7.3 > toolchain `x32-4.7.3-release-win32-sjlj-rev1.7z`, or > b) Use the original 64bit setup but prepend MSYS2 > (x64-msys2-beta2-20130909.tar.xz) to %PATH% and use `make` instead of > `mingw32-make` > > I'm still investigating, but is anyone else able to reproduce or also > having problems with mingw32-make? > > Jon > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] to test for MinGW64
No. You gave an answer to a question Incongruous did not ask. Unfortunately, your answer could confuse newcomers searching this ML. Read Incongruous' post again. It said "I would like to test for MinGW64 to include or exclude some code..." I think LRN, Ruben, and the FAQ provided the correct answers. On Wed, Oct 16, 2013 at 5:26 PM, Edscott Wilson < edscott.wilson.gar...@gmail.com> wrote: > If you use gnu autotools it's really simple. Just put something like this > into configure.ac > > AC_CHECK_HEADERS(windows.h) > > And then use > > #ifdef HAVE_WINDOWS_H > do this > #else > do that > #endif > > > > 2013/10/16 Incongruous > >> Thanks everyone. >> >> *From:* Incongruous >> *Sent:* Tuesday, October 15, 2013 6:06 AM >> *To:* MinGW-64 Mailinglist >> *Subject:* [Mingw-w64-public] to test for MinGW64 >> >> I would like to test for MinGW64 to include or exclude some code; >> something like: >> #ifdef MinGW64 >> doThis(); >> #endif >> #ifdef __MSV__ >> doSomthingElse >> #endif >> >> is this possible? >> > -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] to test for MinGW64
On Tue, Oct 15, 2013 at 7:23 AM, Ruben Van Boxem wrote: > 2013/10/15 LRN > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 15.10.2013 14:06, Incongruous wrote: >> > I would like to test for MinGW64 to include or exclude some code; >> something like: >> > #ifdef MinGW64 >> > doThis(); >> > #endif >> > #ifdef __MSV__ >> > doSomthingElse >> > #endif >> > >> > is this possible? >> > >> #ifdef __MINGW64_VERSION_MAJOR >> doThis (); >> #endif >> #ifdef _MSC_VER >> doSomethingElse (); >> #endif >> > > If you need to test GCC, Clang or MSVC, use __GNUC__, __clang__, or > _MSC_VER (this one is also defined on Intel and Clang under certain > circumstances) > > If you need to test MinGW(-w64) vs MSVC, use __MINGW32__ vs _MSC_VER > > If you need to test MinGW-w64 vs MinGW.org, use __MINGW64_VERSION_MAJOR > (this one requires you to include a MinGW-w64 header before it is defined). > > A nice collection of most of these is located here: > http://sourceforge.net/p/predef/wiki/Home/ > > > Ruben > >From the FAQ Compilation section,s "How can I check for mingw-w64 headers?" http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%20Check%20For%20Mingw-w64 Perhaps it needs refreshed to add Ruben's backgrounder tidbits. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] sbuild update - mingw-w64 3.0.1+ and more
On Fri, Oct 11, 2013 at 1:47 AM, LRN wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sbuild (i686 MSYS2 + i686 mingw-w64) was updated. > Impressive. Similar to my other post, I'm assuming you're OK with additional download traffic to `mingw_base_url_template` if I get interested in conscripting your prebuilt i686 binaries? What's your thoughts/plans on updating to support x86_64-w64-mingw32 in addition to i686-w64-mingw32? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Win-builds 1.3-alpha1 (formerly "yypkg mingw-builds")
On Fri, Oct 11, 2013 at 3:41 AM, Adrien Nader wrote: > Hi, > > I am pleased to announce the first alpha for the 1.3 release of > win-builds.org. > > Interesting and this is certainly humorous http://cgit.notk.org/adrien/yypkg/win-builds.git/tree/hall_of_shame.html If I become interested in using some of your prebuilt binary packages http://win-builds.org/current/packages/windows_64/package_list.html but don't want to use your build machinery because I have my own scheme for automating the downloads and other steps https://github.com/jonforums/buildlets/blob/master/buildlet_utils.ps1#L27-L118 I'm assuming you're OK with extra download traffic being generated to the location mentioned here? http://cgit.notk.org/adrien/yypkg/win-builds.git/tree/get-all-prebuilt-binaries-i686.sh If bandwidth is an issue for you, I'll stop investigating :) Also, using a sample size of 1 it appears all your 32 and 64bit binaries link to `msvcrt.dll` (when applicable) rather than linking to the version specific DLLs. Is this true? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] "Which compiler should I use"
On Sat, Oct 5, 2013 at 3:15 PM, Baruch Burstein wrote: > > On Sat, Oct 5, 2013 at 4:52 AM, Jon wrote: > >> >> Heh heh, Incongruous it's your luck day. >> >> JonY, gave you all the answers and you didn't even have to dig. Oh well, >> the Socratic method is overrated and irritating after about two questions ;) >> >> I have been trying to piece together this type of information for the > past few months (when I have time). Do you know of any good source for > things like this (understanding the different parts of the toolchain and > how they work together, compiling and cross compiling, binutils, etc.). I > have basically been using Google when I know the name of the puzzle piece I > need info about, but I don't even always know that, and depending on the > tool/stage. Google may be very helpful or near useless (not actually > Google, but the available documentation is sometimes very lacking) > > Rather than searching for The Single Source of Knowledge, I've found the melding of multiple sources of info with relentless curiosity and experimentation to be potent. Throw enough info at one's brain, mix in roll-up-your-sleeves-sweat-equity, court serendipity (force yourself to experience new people and new ideas), introspect, have patience to let time work its magic, and I think you'll be shocked at how skilled you become. Patience and managing ones own expectations is critical. We often cause ourselves great angst and frustration by falling prey to the expectation that learning all the tools and different platform intricacies should happen instantaneously. Progress is chunky. Sometimes a lot happens all at once, other times it's incremental. One step at a time regardless of the step size. Oh, but you were looking for something a bit less abstract? ;) While each of us best learn in our own individualistic way, I've found the following to be helpful. I'm very interested in hearing from others on the ML about their Learning Accelerators. 1a) Create toy apps to learn the fundamentals of gcc/g++ and the key binutils tools: ld, nm, objdump, and ar. Focus on learning the basics of what the tools are used for and don't get mired down in trying to remember all the options and corner cases. Iterate. 1b) Read the docs. Seriously. Maintainers often pour their souls into creating good documentation. Don't be so lazy as to disregard/disrespect their time and efforts. Where maintainers haven't invested in good documentation, jump in and help document. Writing good documentation often leads to in-depth understanding. https://sourceware.org/binutils/docs-2.23.1/binutils/index.html http://gcc.gnu.org/onlinedocs/ In particular, I found Ian Lance Taylor's series on linkers to be, well, incredible http://www.airs.com/blog/archives/38 1c) Spelunk for cool system introspection tools. For example, on Windows these are invaluable: http://technet.microsoft.com/en-us/sysinternals/ http://winitor.com/ http://dependencywalker.com/ http://www.rohitab.com/apimonitor 1d) Investigate all your toy apps with GDB. 2) Familiarize yourself with the PE and ELF specifications. Bite a bit off at a time and iterate rather than getting overwhelmed. 3) Familiarize yourself with how DLLs and SOs work and how different OS loaders utilize them. 4) Invest time to lurk on this and other MLs. Take the time to try to understand the posts with patches. For example, there is a lot to learn from looking at recent patches from dw and LRN. 5) The autoconf documentation is a great way to gain a different perspective on building apps. While I dislike (loathe is a bit to over the top) autotools I have great respect for their power. Although the Quasimodo of build tools makes things much easier for me, I've yet to be converted into a raving partisan. https://www.gnu.org/software/autoconf/manual/index.html 6) Work on increasingly more challenging problems. Specifically, search out the difficult bugs in your favorite open source projects and tackle them with abandon. Who cares how long it might take as long as you find the obstacle to be an interesting next challenge. While there's a lot to be said with playing with self-created toy apps, NOTHING is as valuable to your learning as conquering meaningful, real-world challenges that cause you to interact with other people interested in the same area and court serendipity. Jon -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] "Which compiler should I use"
> > > > Good luck with spelunking the awesomeness that makes up your MinGW-w64 > > toolchain. > > > > Do go on. > > Your turn. I'm waiting to learn some cool new build tool tricks from you or others :) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] "Which compiler should I use"
Heh heh, Incongruous it's your luck day. JonY, gave you all the answers and you didn't even have to dig. Oh well, the Socratic method is overrated and irritating after about two questions ;) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] "Which compiler should I use"
On Fri, Oct 4, 2013 at 11:14 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04.10.2013 18:15, Incongruous wrote:
> > Which of these compilers should I use if I want to compile in 64bit?
> >
> > /bin/g++.exe
> > /bin/x86_64-w64-mingw32-g++.exe
> >
> >
> > Is this correct?
> >
> > if(OS_64_BIT){
> >/bin/g++.exe
> > }
> > else{
> >/bin/x86_64-w64-mingw32-g++.exe
> > }
>
> No.
>
> 1) gcc compiles for its target triplet.
> 2) target triplet is put into prefix (i.e. x86_64-w64-mingw32 is the
> prefix for g++)
> 3) target triplet can be found by invoking `gcc -dumpmachine'
> 4) if gcc has no prefix (i.e. just g++.exe), then -dumpmachine is the
> only way to find the target (well, not really, but this is what you
> should use).
> 5) on sane systems (MSYS2-based sbuild, most GNU systems) `gcc', `g++'
> and other un-prefixed executables are, in fact, symbolic links to real,
> prefixed executables
>
> Another point that you should keep in mind is where gcc looks for libs
> and headers.
> Run `echo | [] -E -v -' to see where it looks for headers.
> Run `[] -print-search-dirs' to see where it looks for
> libs (replace [] with the executable name).
>
> So, your assessment makes no sense. g++ could be the right thing to use.
> Or maybe it isn't. You will never know until you check its target.
> x86_64-w64-mingw32-g++ is not the right thing to use for non-64-bit
> OSes, because it compiles for 64-bit OSes (that is obvious from its
> prefix). Most likely (let's keep it real - usually people don't mix
> unprefixed i686-gcc with prefixed x86_64-gcc) both executables will
> produce x86_64 code.
>
> If you do want to actually compile for i686 and x86_64, you need either
> a multilib toolchain (these are rare; if you do find one, use -m32 and
> - -m64 to set its target) or two separate toolchains.
>
> If toolchains are native, you can't mix them in the same directory, as
> they look in the same directories for libs and headers, and their libs
> are different (but have the same names).
> If toolchains are not native (are cross-compilers; self-targetted or not
> - - that does not matter) you may be able to mix them in the same
> directory, as they look for stuff in subdirectories. Note that
> i have never tried to do that, and generally don't use cross-compilers.
>
> Finally, if you use autotools, then you don't have to select which
> compiler to use, as configure script will do that for you. You only need
> to specify the right --build or --host
>
>
Incongruous, fantastic to see your desire to deeply understand how your
toolchain.
You just need to spend some time connecting all the dots by playing with
the different build tools.
Keep with it and make sure you FIRST try things, fall down, get back up,
and do it again rather than simply lobbing question after question to ML's.
But don't run your head against the wall TOO many times. If you've narrowed
things down to a simple test scenario and it keeps failing no matter what
you try, ask the gurus here. Give them the simple test scenario, your
assumptions, and a brief description of what you've tried.
In addition to LRN's awesome feedback, here are a few other comments...
1) Hold off spelunking autotools (aka AutoHell) until you're comfortable
with gcc/g++, ld, binutils, and make. Autotools is the Quasimodo of
software tools. Horrific to look at but incredibly powerful. It and the
people who developed it and continue to support it deserve your respect.
The documentation is very good and will help you understand triplets,
--build, --host, and --target mentioned by LRN.
https://www.gnu.org/software/autoconf/manual/index.html
2) Write an insanely simple program and practice with your tools until
you're familiar with their capabilities. For example, with this trivial C++
program
# file: hello.cc
#include
static void say_hello()
{
std::cout << "Hello C++ World!" << std::endl;
}
int main() {
say_hello();
return 0;
}
start playing, and keep playing, until you learn more about the tools. GDB
is a great friend, but I won't show it below. These examples are from my
Win8 64bit on a W530 using an official MinGW-w64 64bit binary toolchain
(win32 threading, SEH exception handling) built and maintained by the
fabulous niXman and Alexey.
C:\Users\Jon\Documents\CDev\sandbox>gcc --version
gcc (rev2, Built by MinGW-W64 project) 4.8.1
...
# basic use of g++ compiler driver (why did I call it a "compiler driver?")
C:\Users\Jon\Documents\CDev\sandbox>g++ -Wall -o hello.exe hello.cc
# eh? gcc can compile C++ programs?
C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o hello.exe hello
Re: [Mingw-w64-public] [doc] "Which compiler should I use" FAQ entry
On Thu, Oct 3, 2013 at 5:27 AM, JonY wrote: > On 10/3/2013 06:27, Jon wrote: > > FAQ entry added under Execution section > > > > https://sourceforge.net/apps/trac/mingw-w64/wiki/FAQ > > > > Answer added as > > > > > https://sourceforge.net/apps/trac/mingw-w64/wiki/Usable%20compiler%20executable > > > > Correct, modify, or make clearer as you see fit. If you don't have edit > > privileges reply to this thread and I'll make appropriate changes. > > > I would change to since sysroot can mean something else. > > Done. This more closely matches http://gcc.gnu.org/install/finalinstall.html > Likewise, sometimes, there is no "gcc.exe", only > "x86_64-w64-mingw32-gcc.exe", depending on your download. > > "gcc" could be set to target for anything, while > "x86_64-w64-mingw32-gcc" makes it explicitly clear that you are > compiling for 64bit windows. > > This should already be covered by my overuse of "depending upon how your toolchain was built" cross compiling is another closely related concept, which may not be the > case here, since it is perfectly alright to install and use gcc, with a > fully qualified target triplet prefix in the name. > > Good point. While we need to mention name prefixing in the answer, we shouldn't further confuse with too much cross compiling info. I've attempted to clarify the Long Answer a bit more. See if you agree with the changes. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [doc] "Which compiler should I use" FAQ entry
FAQ entry added under Execution section https://sourceforge.net/apps/trac/mingw-w64/wiki/FAQ Answer added as https://sourceforge.net/apps/trac/mingw-w64/wiki/Usable%20compiler%20executable Correct, modify, or make clearer as you see fit. If you don't have edit privileges reply to this thread and I'll make appropriate changes. Jon -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw32-make errors in mingw-w64 25.09.2013, rev2 toolchain
On Win8 64bit using the recent mingw-w64 binary toolchain `x86_64-4.8.1-release-win32-seh-rt_v3-rev2.7z` to build vim from source, I see the following errors due to mingw32-make behavior: C:\Apps\vim-hg>gcc --version gcc (rev2, Built by MinGW-W64 project) 4.8.1 ... C:\Apps\vim-hg\src>mingw32-make -f Make_ming.mak gvim.exe xxd/xxd.exe mkdir gobjnative mingw32-make: Interrupt/Exception caught (code = 0xc005, addr = 0x07FCE1A9296F) OK, ignore and try again... C:\Apps\vim-hg\src>mingw32-make -f Make_ming.mak gvim.exe xxd/xxd.exe gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s blowfish.c -o gobjnative/blowfish.o gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s buffer.c -o gobjnative/buffer.o ... gcc -c -Iproto -DWIN32 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=native -Wall -O3 -fomit-frame-pointer -freg-struct-return -s os_w32exe.c -o gobjnative/os_w32exe.o mingw32-make: Interrupt/Exception caught (code = 0xc005, addr = 0x07FCE1A9296F) These errors do not occur when: a) I do a 32bit build using mingw32-make from the mingwbuilds 4.7.3 toolchain `x32-4.7.3-release-win32-sjlj-rev1.7z`, or b) Use the original 64bit setup but prepend MSYS2 (x64-msys2-beta2-20130909.tar.xz) to %PATH% and use `make` instead of `mingw32-make` I'm still investigating, but is anyone else able to reproduce or also having problems with mingw32-make? Jon -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW64\bin... 32/64 bits compier?
On Tue, Oct 1, 2013 at 6:15 PM, JonY wrote: > On 10/1/2013 22:49, Jon wrote: > > What you likely lack is free time and the desire to maintain > documentation. > > Understandable. > > > > Since you seem free, you can prepare the text, I'll look through it and > reformat it for the wiki, sounds good? > > I'd like to, but I'm in the middle of legal preparations and not free. I'll create the FAQ entry I committed to providing. Verbose replies simply imply that I'm interested in the topic (great mingw-w64 docs that reduce questions and help busy maintainers not repeat themselves) not that I currently have free time. Perhaps in the future. Near term, my snippets of free time are already spoken for. I'm distracted by the siren song of Alexey and niXman's build recipes for the official mingw-w64 binary toolchains. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW64\bin... 32/64 bits compier?
On Tue, Oct 1, 2013 at 5:24 AM, JonY wrote: > On 10/1/2013 07:34, Jon wrote: > > Bottom line: MinGW-w64 project documentation needs help starting with the > > FAQ. Add a specific entry addressing Incongruous' question and make this > > one go away. > > > > Will you be willing to do it? I'm no good at judging what material is > suitable for new users. > > If I still have access rights I'll add this one. You're mistaken. You're perfect for judging what new FAQ entries should be added, new user or not. You: a) are a long-standing, experienced mingw-w64 (and cygwin?) contributor/maintainer b) still care enough to stay engaged on the ML c) have a point-of-view (aka opinionated) that you willingly add to discussions d) love to provide verbose answers. oh, wait... What you likely lack is free time and the desire to maintain documentation. Understandable. That said, for the FAQ, why don't you write a list of ML Topics I'm Tired of Seeing Rehashed Ad Infinitum and add them bit by bit to the FAQ as you get spare moments. Other experienced mingw-w64 contributors could do the same as well as take a bit of time to review/cull the existing doco. Good doco allows wonderfully concise responses such as: "RTFM http:/link/to/our/awesome/doco/dont-be-so-lazy-next-time/" -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MinGW64\bin... 32/64 bits compier?
On Mon, Sep 30, 2013 at 3:35 PM, Kai Tietz wrote: > We have this in our FAQ AFAIR. But once again, never - and I mean > NEVER - use the executable you find in //bin. Only > use the variant in /bin folder. > In your case the later is the proper one (bin\x86_64-w64-mingw32-g++.exe). > The other in //bin (in your case > x86_64-w64-mingw32/bin/g++.exe) is for internal use of some > build-tools. I repeat myself here. Never, really never call these > executables directly!. > > The target-prefix before the gcc-tool is caused by the fact that you > are using a cross-compiler. > > To control the bitness of target is done via the switches -m32/-m64. > Of course you need to make sure that your used toolchain was actual > setup-ed proper for multilib-scenario. Otherwise you will run into > troubles as no runtime for one target might be present. > > Hope this solves your confusion a bit. > > Regards, > Kai > > JonY claims "This question has been asked so many times it is not funny." OK, then make this one go away. If this newcomer question keeps coming up it's likely that either (a) Incongruous is just too damn lazy to spelunk the FAQ, or (b) the FAQ is lacking. I can't speak to (a) but after looking at the FAQ, the FAQ isn't helpful for this common question. Specifically, which FAQ entry gives The Answer? Is it this (outdated) entry titled "What file should I download? / What do the names mean?" where one has to scroll almost to the bottom for item (4) under the "What do you want" section to find this self-conflicting summary? "4) Would you like a prefixed (g++ = bin/g++.exe) or non-prefixed toolchain? Prefixed means the command you run for g++ will be bin/i686-w64-mingw32-g++.exe (for the 32bit toolchains). Non-Prefixed means the command you run for g++ will be bin/g++.exe. All of the automatically built toolchains are prefixed and the sezero toolchains (under personal builds) are not prefixed. You can turn a prefixed toolchain into a non-prefixed toolchain by renaming the prefixed files in the bin directory and removing the prefix. ..." Or if it's not in the FAQ, is this the wiki page http://sourceforge.net/apps/trac/mingw-w64/wiki/GeneralUsageInstructions in which newcomers are supposed to spelunk to the "Installing the toolchain" -> "Windows native" section describing TDM-GCC and interpret this as the answer? "You should be ready to go. Execute i686-w64-mingw32-gcc -v or x86_w64-w64-mingw32-gcc -v to see that everything has gone well." Or is it documented somewhere else except in ML posts? Bottom line: MinGW-w64 project documentation needs help starting with the FAQ. Add a specific entry addressing Incongruous' question and make this one go away. At least the response to anyone so bold to ask the question again could be the always entertaining RTFM and a FAQ link. And who knows, maybe JonY will find the ML questions to be just a bit more funny. Pfft, who am I kidding...I just want to see JonY tersely tell someone to RTFM ;) Jon -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Announcement: mingw-builds and mingw-w64 are joining forces
> > Well, let us see how many traffic will come up for this. For now I > > would like to see discussions like this on our public mailing list. > > > > If we find out that traffic is too high, then we can still create > > another mail-list for it. > > Okay. > > I wasn't suggesting another mailing list, but a separate email on _this_ ML summarizing areas where you could use help in maintaining the official mingw-w64 toolchains. Advertise the areas where you need help, if any. Perhaps some on this list have spare time to help out on specific tasks. That said, you guys have the toolchain build/deploy process running nicely, so maybe more "help" would just make things worse ;) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Announcement: mingw-builds and mingw-w64 are joining forces
On Mon, Sep 23, 2013 at 11:17 AM, niXman wrote: > 2013/9/23 Kai Tietz: > > Hello everybody, > > > > As you may have noticed, we are already providing builds from > > mingw-builds on our download page. both mingw-builds and mingw-w64 will > > be joining ventures together. Both Alexey and niXman will both ensure > > that pre-built toolchains have regular maintenance and releases. This was > > necessary after Ruben announced his plans to retire from providing his > > awesome pre-built toolchains. > > > > As personal toolchain releases are important to our users, and to avoid > > misunderstanding, responsibility for user support of these toolchains > > will be equally shared between all toolchain providers. > > > > Our recommendation on using the mingw-builds variant is geared towards > > providing new users an easy starting point rather than to single out > > other providers. We encourage more developers and users to join in as > > regular toolchain providers via our "personal build" section. > > > > We are happy that we were able to join forces with mingw-builds, and > > fill by this > > a gap for our users in providing toolchains they need. > > > > We hope you give Alexey and niXman a warm welcome and a chance to grow > > into their new positions! > > Thank you, Kai! > > > At present I and Alexey provide builds as "Personal builds", that in > fact is not our goal. Our goal is to provide "Official builds". To do > this, we need the help of mingw-w64 users, in the form of feedback. I > am asking all of you to try out our builds and report the result. > > The nearest plans include the following objects: > 1. To complete the porting of mingw-builds scripts for the possibility > to use it with osx/nix platforms. > 2. To create an universal online installer of the precompiled > toolchains for win/osx/nix. > 3. To create a collection of precompiled OpenSource libraries for > C/C++ programming languages. > > Fabulous. Kai: nicely done...thanks for avoiding terseness and providing enough verbiage to help set expectations and tone. Feedback in no particular priority: 1) Immediately begin placing the builds in an "Official Builds" dir that is a sibling to the current "Personal Builds" dir. 2) Maintain the mingw-builds build scripts in a public git repo similar to Reuben (does not have to be on GH). Perhaps this is already done today and I've been too lazy to find anything but the `mingw-builds-3.0.0.zip` download. 3) An installer is fantastic, but please continue to ensure the components are usable and downloadable without the installer. This is important for those of us who stitch together custom toolchains by scripting the download/extraction of your base (binary) components. 4) Start a separate thread that lists specific areas (small and large) where you guys could use community help in building and maintaining the official mingw-w64 builds. Will official mingw-w64 builds be available only for 4.8.1+, or will a limited number of earlier versions also be supported? For me, I currently only care about 4.7.x and 4.8.1+ In addition to Alexey and niXman, a big "Thank You" to all mingw-w64 contributors who make this effort of providing usable binary toolchains possible. Jon -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers
On Sat, Sep 14, 2013 at 9:44 AM, Ruben Van Boxem wrote: > Op 14-sep.-2013 13:50 schreef "Erik van Pienbroek" > het volgende: > > > > > JonY schreef op za 14-09-2013 om 19:24 [+0800]: > > > Daily automated tarballs already done by buildbot. Probably need to add > > > something like svnversion to generate release revision info in a > special > > > header. > > > > I personally think daily releases are a bit too much bleeding edge. Of > > course they're useful to developers and dedicated testers, but we can't > > expect regular users to keep up with this. So for regular users we need > > to have something that is between 'stable' and 'dev'. Therefore I think > > having a bi-weekly 'testing' release would be a nice compromise which > > can be realized with minimal effort. > > I think you guys are missing the main problem: the fact that for the last > half year, trunk was necessary to build the latest GCC version. I'm > confident the whole trunk stability question will descend into only murmurs > if a stable version can be guaranteed that can be used to build GCC. This > is I think the main reason a lot of people are complaining. This should be > very much avoided in the future IMHO. > > Just my 2c, > > Ruben > > i'd like to hear nixman and alexey's perspective as it relates to the mingw-builds binaries. jon -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Merging MinGW-builds and MinGW-w64
> 2013/7/21 Kai Tietz: > > Hi > > > > as far as I remember we discussed that we shouldn't touch first hand old > > structure. First building up new tree and then move *unnecessary* parts > > away, or/and at least announce changes in front with community to avoid such > > fallouts. It is worse to have some changes/temporary fallouts. > > Nevertheless we have to inform before changing way of access. > > Hmm... > Ok. > > -- > Regards, > niXman niXman, Perhaps you are planning a followup email to this thread that summarizes the next steps, the expected directory structure, the timeline, etc. If so, after you, Kai, and JonY have sync'd up again on the details, I'd be happy to proofread the email before you send it out. Since English is not the mother language of all members of this ML, as a native English speaker I might be able to help make the followup email a bit more clear. Actually, I'd volunteer Erik van Pienbroek to review (his style is both informative and readable) but I don't know him well enough to try to stick him with this one ;) Bottom line: if you'd like another set of eyes to review for English and clarity, I'd be more than happy to assist. Just email me a version off-list. If not, that's fine and I'm looking forward to the new `mingw-w64-builds` directory contents of "official" builds :) Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Change of SF.net file tree
On Sat, 20 Jul 2013 11:41:46 -0400 Earnie Boyd wrote: > On Sat, Jul 20, 2013 at 10:15 AM, Ozkan Sezer wrote: > > On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem > > wrote: > >> Hi, > >> > >> Although I am not strictly against it, it seems the MinGW-w64 files tree > >> has > >> dramatically changed, invalidating any old links to files. > >> > >> I'd appreciate if something like this happens, the person making the change > >> notifies this list. Unless I missed the message (which is possible), this > >> did not happen. > >> > >> Please note that all links to my builds I have been posting on the internet > >> are now useless. This is not a good thing. > >> > >> Ruben > >> > > > > Noticed it upon reading your mail. > > > > It is a bit annoying, yes, but if your links are to files and not > > to directories, and if each of your files have unique file names, > > then posting download links like: > > http://sourceforge.net/project/downloading.php?group_id=202880&filename=x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb.7z > > ... may save you from such troubles in the future: 202880 is the > > project group id for mingw-w64. (And no, I don't know if sf.net > > would drop support for this in the future.) > > Or use "http://prdownloads.sourceforge.net/mingw-w64/?download". > SF keeps an index of file names by project to know where on the file > system it exists. This style of download link still appears to work both manually curl -L -O http://downloads.sourceforge.net/mingw-w64/i686-w64-mingw32-gcc-4.8.0-win32_rubenvb.7z and with the browser auto-handling redirects. Jon -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs
On Mon, 15 Jul 2013 11:02:20 +0400 niXman wrote: > 2013/7/15 Jon: > > When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built artifacts > > have a runtime dependency on > > `libgcc_s_sjlj-1.dll`. This is not the case when I use the rubenvb > > toolchains. > > Just now I checked with [1] and [2] and found no dependency on > `libgcc_s_sjlj-1.dll` > What am I doing wrong? > > > [1] > http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/sjlj/x64-4.8.1-release-win32-sjlj-rev2.7z > [2] > http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/sjlj/x64-4.8.1-release-win32-sjlj-rev1.7z Sorry, I wasn't clear. It seems that only the built DLLs (not exes) have a dependency on `libgcc_s_sjlj-1.dll` when I build with [1] but not [2]. For example, the DLLs built for both Lua and UnQLite (and Ruby using different build helper) using these build recipes: Lua: https://github.com/jonforums/buildlets/blob/master/build_lua.ps1#L60-L72 UnQLite: https://github.com/jonforums/buildlets/blob/master/build_unqlite.ps1#L60-L72 When I use PEStudio [3] v7.19 for static analysis, I see the DLLs are trying to import the following symbols from `libgcc_s_sjlj-1.dll`: ** unqlite.dll ** __divdi3 __moddi3 __udivdi3 __umoddi3 ** lua52.dll ** __udivdi3 __umoddi3 I'm still investigating to try to discover if I've misconfigured my automated build helpers. Jon [1] http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-win32/sjlj/x32-4.8.1-release-win32-sjlj-rev2.7z [2] http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/i686-w64-mingw32-gcc-4.7.4-release-win32_rubenvb.7z [3] http://www.winitor.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Not understanding SJLJ dependency tradeoffs
When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built artifacts have a runtime dependency on `libgcc_s_sjlj-1.dll`. This is not the case when I use the rubenvb toolchains. My understanding is that the `libgcc_s_sjlj-1.dll` dependency is only required for C++, not C, apps due to exception handling support. As I don't spend much time with C++, I'd like to better understand the build and runtime tradeoffs with SJLJ. Specifically: 1) Is minimizing toolchain build complexity the main benefit of an extra SJLJ DLL dependency for C apps? 2) What toolchain build setting(s) allows rubenvb builds to *not* create the SJLJ DLL dependency for C apps? 3) When using the mingwbuilds toolchain, is there a gcc option (eg. -Wl,--static-sjlj-lib) to suppress the SJLJ DLL dependency? Something lovely like `-Wl,-Bstatic -lgcc_s_sjlj -Wl,-Bdynamic ...`? 4) What are the downsides of toolchains behaving like the rubenvb toolchains wrt SJLJ? 5) Any other important tradeoffs to be aware of? (no SEH vs Dwarf vs SJLJ discussion please ;)) Jon -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz wrote: > 2013/7/10 Jon : > >> > > While the question about what current users are using is already hard > >> > > to answer, there's IMO a bigger one: What _potential_ users are there > >> > > that aren't already using mingw-w64 :) I started looking into > >> > > mingw-w64 maybe a year ago, only to find out that > >> > > - there's no 'official' installer/ toolchain > >> > > - there are a whole bunch of 'personal' builds & mingw-w64 derived > >> > > projects > >> > > - different projects provide a myriad of different gcc versions x > >> > > architecture x exception handling mechanism x threading library > >> > > combinations (and again, little hints on what is the 'recommended' > >> > > configuration for most users). > >> > > > >> > ...SNIP... > >> > > >> > I do not say that not offering any option is the right way. But there > >> > should be something what is "default". And the "default" should be > >> > offered as that. It should be much more visible, and available in a > >> > click or two from the homepage. And last but not least, the "default" > >> > should not be tagged as a personal build. You should minimize the number > >> > of question he needs to answer to get "just some compiler to build my > >> > program with". > >> > > >> > To summarize, IMO, mingw-w64, although technically as good as it is, > >> > emits bad signals to newcomers. Unfortunately, it has always been > >> > repelling for new users and, I believe, it is also the reason why > >> > mingw-builds (although also not ideal for sure) succeeded so easily. It > >> > simply filled the gap in the demand, which you never attempted to fill. > >> > >> I believe everyone will concur. > >> > >> ...SNIP... > >> > >> In any case we now have the question: what would be official or even > >> advised? > > > > This is not a technical issue. It's primarily a mingw-w64 project > > leadership and > > simplification challenge. > > > > It's not helpful that neither Kai nor JonY has definitively weighed in on > > whether > > an official mingw-w64 default toolchain makes sense. Actually, that's not > > true. > > Awhile back Kai was very involved with announcing Ruben as the new build > > release > > mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a > > maintained, > > official, easy-to-use default toolchain in addition to the automated > > testing builds. > > Well, I assumed I was clear about that already. IMO it is absolutely > necessary that we (mingw-w64) are providing an official > toolchain-version, which we are recommenting. > To be clear here, those toolchain-releases aren't mingw-w64 releases. > The mingw-w64 releaes are just releases of our repository, not that of > combinations with other ventures. > And exactly this might be confusing here for some people. A pre-build > toolchain release is always just "one" variant of a combination using > our stuff with other ventures. That makes such releases so hard to be > marked as "recommented". > Nevertheless I agree completely that we have to provide such pre-build > toolchains, so that users have an easier access to our work. > > > > But "interpreting" or "implying" or "inferring" is not useful. Explicit > > clarification > > from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why > > this hasn't > > happened is that both already have too much on their plate and don't want > > to set the > > expectation that either will be responsible for implementing and > > maintaining an official > > toolchain like JonY appears (aweome) to be doing at > > http://cygwin.mirrors.pair.com/release/gcc4/ > > The old speak-up-and-get-stuck-with-it paradox ;) > > > > That's OK, and is why I believe the first step needs to be Kai/JonY saying > > (a) "The > > mingw-w64 project needs an official, easy-to-use toolchain", (b) "Neither > > of us > > have the bandwidth to implement/maintain it", and (c) "We're actively > > looking for > > a new committer to take on this role. If this is going to happen and be > > sustainable, > > we
Re: [Mingw-w64-public] End of rubenvb builds
> > > While the question about what current users are using is already hard to > > > answer, there's IMO a bigger one: What _potential_ users are there that > > > aren't already using mingw-w64 :) I started looking into mingw-w64 maybe > > > a year ago, only to find out that > > > - there's no 'official' installer/ toolchain > > > - there are a whole bunch of 'personal' builds & mingw-w64 derived > > > projects > > > - different projects provide a myriad of different gcc versions x > > > architecture x exception handling mechanism x threading library > > > combinations (and again, little hints on what is the 'recommended' > > > configuration for most users). > > > > > ...SNIP... > > > > I do not say that not offering any option is the right way. But there > > should be something what is "default". And the "default" should be > > offered as that. It should be much more visible, and available in a > > click or two from the homepage. And last but not least, the "default" > > should not be tagged as a personal build. You should minimize the number > > of question he needs to answer to get "just some compiler to build my > > program with". > > > > To summarize, IMO, mingw-w64, although technically as good as it is, > > emits bad signals to newcomers. Unfortunately, it has always been > > repelling for new users and, I believe, it is also the reason why > > mingw-builds (although also not ideal for sure) succeeded so easily. It > > simply filled the gap in the demand, which you never attempted to fill. > > I believe everyone will concur. > > ...SNIP... > > In any case we now have the question: what would be official or even > advised? This is not a technical issue. It's primarily a mingw-w64 project leadership and simplification challenge. It's not helpful that neither Kai nor JonY has definitively weighed in on whether an official mingw-w64 default toolchain makes sense. Actually, that's not true. Awhile back Kai was very involved with announcing Ruben as the new build release mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a maintained, official, easy-to-use default toolchain in addition to the automated testing builds. But "interpreting" or "implying" or "inferring" is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much on their plate and don't want to set the expectation that either will be responsible for implementing and maintaining an official toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/ The old speak-up-and-get-stuck-with-it paradox ;) That's OK, and is why I believe the first step needs to be Kai/JonY saying (a) "The mingw-w64 project needs an official, easy-to-use toolchain", (b) "Neither of us have the bandwidth to implement/maintain it", and (c) "We're actively looking for a new committer to take on this role. If this is going to happen and be sustainable, we need your help." Or say "The current situation is fine; mingw-w64 doesn't need an official toolchain." Either way, make things crystal clear. If an official toolchain is important to mingw-w64 and someone has the passion and time to take on the release mgr, the next step is rutheless simplification. For example, take Ruben's existing build infrastructure and morph a baseline version (non buildbot automated) into the mingw-w64 repo. As a strawman to kick about, is the following a good value-add first step? What else can be removed? 1) Build cross (Linux hosted) and non-cross (Windows hosted) on Linux as is currently done. Add build-on-Windows support via MSYS/MSYS2 later. And OS X hosted even later. 2) Keep existing C, C++, Fortran, Obj-C, and Obj-C++ language support. 3) Keep existing mingw32-make and python enabled GDB support. 4) Provide single target 32 and 64-bit compilers for only GCC 4.8.1 using Win32 threading with SEH or SJLJ. Other variants later. 5) Release binaries to a new "Official Builds" folder Two concerns. First, who's going to take on the release mgr role, and second, does this add any real value above and beyond what mingwbuilds is already providing? To help with the release mgr role, I strongly believe the toolchain build process needs to be trivial to perform so that the role is easy to transition in and out of. No one is going to step forward if the task is perceived as too onerous or requires a long-term committment. Thoughts? Jo
Re: [Mingw-w64-public] End of rubenvb builds
> That you think that mingw-builds is doing a better job as you did is > at least for our community a least one good news ... nevertheless is > mingw-builds a different venture, and I am not sure if we should drop > that easy our own toolchains. I admit that as long as mingw-builds is > well maintained, and build regular toolchains on sane-state of > toolchain, it is ok, but as soon as this might not happen anymore we > are getting in serious troubles. I don't think we should let > third-party ventures manage our work exclusive and not providing some > base-knowledge and environment by ourself. > > Thanks for your work and all the best, > Kai Playing the non-PC devils advocate role... TL;DR - actively recruit a new mingw-w64 committer passionate about and responsible for regular, developer-friendly, mingw-w64 "official" binary toolchain releases. When I first became interested in the mingw-w64 project in the era before the fabulous rubenvb and mingwbuilds toolchain availability, I quickly became maddened with lack of "usable" windows-hosted automated builds. At that time, the windows-hosted automated builds were "unusable" to me because (a) they were only provided as cross-compilers (i686-w64-mingw32-gcc.exe) not the "native" compilers (gcc.exe) that developers building on windows hosts expect. (b) the downloads were monstrous because the relevant binaries had not been stripped as part of the build process. (c) the mingw automated builds were rarely up-to-date because the mingw buildbot was not being actively maintained and kept available. To add perceived "insult" to "injury", NightStrike and JonY appeared to be overly pedantic about cross-compilers and neither seemd to "get" why the above issues were important for developers simply wanting easy-to-acquire and easy-to-use mingw-w64 based toolchains for windows hosts. As such, my original perception of the mingw-w64 project was that mingw-w64 had too few committers to do a good job, had slid into the user unfriendly swamp, and two of the committers were too arrogant (or clueless) to recognize that change was needed in order to provide great toolchains to users. Frankly, I incorrectly came to the dangerous conclusion that mingw-w64 was a poorly run project. But as I paid more attention to the ML, my initial views (except the too few committers PoV) proved to be both naive and completely wrong; I was rewarded with an all expense paid trip to Dante's Fifth Circle sunny time share reserved for those who jump to conclusions too quickly. I often wonder how many newcomers to mingw-w64 have the same poor initial perspective of the project because of the lack of official, usable toolchains. And then came the rubenvb builds to save the day with Ruben annointed as the new toolchain release manager. Then came the mingwbuilds toolchains that provided even more choice and more goodies. The salad days. Life with mingw-w64 was good. But all things change, and we can't expect one to shackle themself to the often thankless boat anchor of perpetual maintenance. I believe mingw-w64 needs a minimalistic and flexible process and build tool that enable people to easily and gracefully enter and exit the role of official, user-friendly mingw-w64 toolchain release manager. Easy to say, but at the end of the day the key challenge will always be finding people with free time who are passionate about the role. I think Kai very wisely recognizes that mingw-w64 needs to do a better job of controlling its own destiny "I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself." Third party projects like mingwbuilds, tdm, and rubenvb will always exist with the goal of adding unique value. Some will come, and some will go. This is a Very Good Thing. But it's a Bad Thing that mingw-w64 doesn't have official, user-friendly toolchains, even if (for pragmatic reasons) only windows hosted and a linux host cross-compilers are provided. The current automated builds (apparently targeted to internal testing usage) are not a solution. I'm hoping that a version of Ruben's work at https://github.com/rubenvb/MinGW-w64-build-scripts can be the foundation of a new official mingw-w64 toolchain release process. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
Corrina, My user-based perspectives embedded below for your consideration... > On Jun 8 01:56, Алексей Павлов wrote: > > 2013/6/7 Corinna Vinschen wrote: > > > A final note: I'm not opposing the fork. Under the GPL it's your > > > perfect right to do so, as long as you adhere to the license > > > requirements. But that doesn't mean I have to understand it. If the > > > DLL and the tools are exactly the same and only differ by name, then, > > > what's the point? Wouldn't it make more sense to work with us on the > > > Cygwin project instead? > > > > ...SNIP... > > The problem is this. So far I'm wondering what MSYS2 is about. It > doesn't add any useful functionality over Cygwin. And if so, why not > integrate it into Cygwin instead and only have one project for > everybody? JonY already maintains the mingw-w64 32 and 64 bit cross > toolchains as part of the Cygwin distro, so there's nothing missing for > those who want to create native applications. You assume too much when you say "..there's nothing missing..." from the current Cygwin situation. For example, while scanning the artifacts from JonY's substantial efforts at http://cygwin.mirrors.pair.com/release/gcc4/ having older 4.7.2 support is uninteresting for how I use mingw-w64 based toolchains. Furthermore, JonY's perspective on cross vs native toolchains is very different than mine. Until the mingwbuilds and ruben's mingw-w64 toolchains became available, the auto-built mingw-w64 toolchains were almost unusable for me for a variety of reasons. But is this a problem? No. I simply use mingwbuilds or ruben mingw-64 toolchains and my own tweaks to take advantage of all of JonY's amazing work without having to share JonY's workflow perspectives. It doesn't appear that I have this flexibility if I chose Cygwin. > > > Other than that I'm rather puzzled as to what MSYS2 is about, other than > to duplicate developer efforts and to split communities. Apart from > your perfect right to fork, you might nevertheless understand that I'm a > bit annoyed. Especially given the code base. Me and Kai were working > hard for months to create a 64 bit version of Cygwin, and while our > Cygwin 64 bit distro is still in test mode, you simply rip off the code > and just release your own MSYS2 distro from there. > > I can't help to feel exploited. > > While I'm glad you summarized your emotional views (sadly, too often our emotions are dismissed as somehow irrelevant (!?) and only technical or analytical views are "acceptable" or "correct" in a discussion), I truly hope you don't feel exploited. I view things very differently and think you and Kai should feel honored that someone with a different perspective than yours respected your and Kai's work enough to use it as the foundation for MSYS2, and open up the discussion on this list early in the MSYS2 development. I view Alexey's efforts as sharing rather than "ripping off" and think his work is very much a complement to the work that you and Kai have done. > Back to the technical stuff. Again, I don't understand the reason for > the fork, please explain. What is it, codewise, you really miss in > Cygwin? What non-code problems is MSYS2 trying to fix? It's been a very long time since I used Cygwin, but this discussion will cause me to go back and look at Cygwin again. That said, the following are user-perspective reasons why I currently don't use Cygwin: 1) I build native applications rather than apps dependent upon the Cygwin DLL. 2) I dislike Cygwin's `setup.exe` gui installation helper. I automate the stitching together of MSYS functionality with multiple mingw-w64 and mingw.org (non cross) toolchains to create custom toolchains. Cygwin's integrated `gcc4` support from JonY does not work for me, but I'm very thankful I can take advantage of JonY's tremendous efforts in other ways. In fact, I'm working on a tool that will use window's recent symlink behavior to easily switch toolchains via a dir symlink to locations like `C:\DevTools\mingw` in which the MSYS/MSYS2 goodies live in `C:\DevTools\bin` and the toolchains get symlinked and switched under `C:\DevTools\mingw` by a tool that works similar to MKLINK. The bottom line is that while my workflow does not appear to be a good match for Cygwin's primary use cases, I greatly benefit from MSYS (and likely MSYS2) creative and targeted use of underlying Cygwin capabilities. Even though I don't directly use Cygwin, I thank you for all your hard work and hope to always have the option of using a maintained MSYS or MSYS2 b
Re: [Mingw-w64-public] [Notice] gendef, genidl and genpeimg is now GPLv3 or later
On Sat, 30 Mar 2013 22:51:34 -0400 NightStrike wrote: > On Sat, Mar 30, 2013 at 9:28 PM, JonY wrote: > > On 3/31/2013 04:35, Jon wrote: > >> > >> With respect to > >> http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL > >> is it true that gendef, genidl, and genpeimg do not copy any part of > >> themselves > >> into their output? > > > > That is right, the tools do not replicate themselves in anyway, nor > > create any call references to themselves. The tools being end products > > as opposed to linkable libraries provide an excellent use case for the > > GPLv3 license. > > > > gendef and genidl generate listings that are largely MSVC compatible, > > genpeimg modifies PE flags. > > Doesn't gendef place restriction on the files it generates? If I understand the GPL faq entry correctly, the output of a GPL program that does not copy part of itself to its output is not covered by the GPL, so use of that output is unencumbered by the GPL. It appears your question could only be true if gendef's output is covered by something in addition to GPLv3. As JonY stated GPLv3 or later and not GPLv3 + XYZ, I'm going to assume until I hear otherwise that gendef is restricted only by the GPLv3 terms, JonY's technical response remains valid, and that the above GPL faq entry is the correct guidance to follow when consuming gendef's output. But I'm not a lawyer, and now just a bit more curious. -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Notice] gendef, genidl and genpeimg is now GPLv3 or later
On Sat, 30 Mar 2013 23:59:22 +0800 JonY wrote: > On 3/30/2013 15:47, Ruben Van Boxem wrote: > > Op 29 mrt. 2013 16:48 schreef "JonY" het > > volgende: > >> > >> Hello, > >> > >> After careful thought, we have decided to make gendef, genidl and > >> genpeimg use GPLv3 or later for all future releases. > >> > >> The change brings us closer to the Free software community, guaranteeing > >> Free access to the source code for all in perpetuity, especially for the > >> software developers and code tinkerers out there that need help. > >> > > > > Why, if I may ask, is the public domain not good enough anymore? > > > > PD unfortunately isn't encouraging constructive feedback and proper code > sharing. We moved to GPLv3+ to ensure that new code additions remain > Free rather than becoming partially non-Free in the near future. > > Note that license for previous and existing copies remain unchanged, > only future trunk-based releases are affected. I don't think retrograde > changes work. With respect to http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL is it true that gendef, genidl, and genpeimg do not copy any part of themselves into their output? -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS absolute path conflict with configure tests
> >> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb > >> > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf > >> > fu hovers around the nano-fu level. While the failure is not a mingw-w64 > >> > bug, you guys likely have a better battle-tested solution than my > >> > throw-sed-at-it impulse. > >> > > >> > This section of configure.ac > >> > > >> > http://paste.ubuntu.com/5657059/ > >> > > >> > generates this false conftest failure > >> > > >> > configure:12982: gcc -g -O2 -c conftest.S 1>&5 > >> > conftest.S:1:80: fatal error: > >> > /c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S: No > >> > such file or directory > >> >#include > >> > "/c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S" > >> > > >> > do to line 12 of configure.ac expanding into a MSYS style path style. > >> > Changing from "/c/Users/..." to "c:/Users/..." fixes the issue. > >> > > >> > Any solid mingw/mingw-w64 friendly tweaks you're just sure the upstream > >> > maintainer would be happy with? > >> > > >> > > >> Try to use $srcdir instead $ac_abs_top_srcdir > > > > On my system while running configure from the top level dir, $srcdir, > > $top_srcdir, and $ac_abs_top_srcdir all expand to an absolute MSYS style > > path. > > > > I've never seen a problem with paths like this. If you execute > configure in a separate build directory, using relative paths to the > source, does it help? Some packages are designed to not configure > properly in the source directory. Good idea, I'll try it. This quickie http://paste.ubuntu.com/5659791/ showed that _AC_SRCDIRS([.]) on line 8 causes mingw gcc's heartburn. Looks like some sort of internal ac/m4 macro, but I haven't swung back to spelunk why one would use it. Without it the `bogustest.c` contains #include "/fake-dir/fake.h" and with it `bogustest.c` contains #include "/c/Users/Jon/Documents/Linux/sandbox/fake-dir/fake.h" so it looks like it's needed to correct for some sort of pathing feature of autotools. My patience with autotools has just about reached the end, and our good friend sed is calling with something like this wrapped in a case check: sed "s|^/\([A-Za-z]\)|\1:|" That said, ac's got to have something mingw-friendly that's cleaner than the sed hammer. -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS absolute path conflict with configure tests
> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb > > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf > > fu hovers around the nano-fu level. While the failure is not a mingw-w64 > > bug, you guys likely have a better battle-tested solution than my > > throw-sed-at-it impulse. > > > > This section of configure.ac > > > > http://paste.ubuntu.com/5657059/ > > > > generates this false conftest failure > > > > configure:12982: gcc -g -O2 -c conftest.S 1>&5 > > conftest.S:1:80: fatal error: > > /c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S: No > > such file or directory > >#include > > "/c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S" > > > > do to line 12 of configure.ac expanding into a MSYS style path style. > > Changing from "/c/Users/..." to "c:/Users/..." fixes the issue. > > > > Any solid mingw/mingw-w64 friendly tweaks you're just sure the upstream > > maintainer would be happy with? > > > > > Try to use $srcdir instead $ac_abs_top_srcdir On my system while running configure from the top level dir, $srcdir, $top_srcdir, and $ac_abs_top_srcdir all expand to an absolute MSYS style path. http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html#index-top_005fsrcdir-134 -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS absolute path conflict with configure tests
I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb 4.7.2) and want to create a solid patch for configure.ac, but my autoconf fu hovers around the nano-fu level. While the failure is not a mingw-w64 bug, you guys likely have a better battle-tested solution than my throw-sed-at-it impulse. This section of configure.ac http://paste.ubuntu.com/5657059/ generates this false conftest failure configure:12982: gcc -g -O2 -c conftest.S 1>&5 conftest.S:1:80: fatal error: /c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S: No such file or directory #include "/c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S" do to line 12 of configure.ac expanding into a MSYS style path style. Changing from "/c/Users/..." to "c:/Users/..." fixes the issue. Any solid mingw/mingw-w64 friendly tweaks you're just sure the upstream maintainer would be happy with? Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Performance changes when switching to 4.8.0
> > I'm using the rubenvb with no "dw2" in the archive name, so I suppose I'm
> > using SJLJ in 32bit and SEH in 64bit?
>
> I guess so.
>
> > Can there be a 30% speed difference just due to SJLJ, even if I do not use
> > any
> > exception handling in my code?
>
> Yes, actually I had measured about 25% slow down e.g. in creator startup, and
> for the test case in the bug report it's even 300%.
>
> The jumps implementing SJLJ are automatically added to any code block that
> _might_ throw, or propagate, an exception. So you don't have to have any try
> {} catch {} blocks to get the slowdown, I understood.
>
> > Other libs may use exceptions, but my app is
> > running my code 99% of the time, as libs are only used for GUI and during
> > initialization.
>
> Well, it's enough if you're using e.g. QtCore, which is compiled with
> exception handling enabled. Only if you do -fno-exceptions for all libs you
> should be on the safe side, performance wise.
>
> > What do I risk with dw2? I've read the main guidelines, but my understanding
> > of exception handling and stack frame unwinding is too short to understand
> > if this will impact my work.
>
> There are problems (crashes) with dwarf as soon as you actually use
> exceptions, and you want them to propagate to stacks not compiled with the
> same compiler. Also Jonathan Liu reported issues with
> LoadLibrary/FreeLibrary, see http://qt-project.org/wiki/MinGW-64-bit .
>
> Anyway, we plan to switch to a dwarf toolchain for official Qt packages with
> 5.1 onwards.
Kai, Ruben: fabulous info, muchas gracias.
When building on Windows (Win7 32-bit, Win8 64-bit) I primarily use gcc to
compile C stuffage and don't think much about dwarf vs. sjlj exception
handling. Ah, but luckily things morph and I now find myself downloading
mingwbuilds `Qt-5.0.2-preview-x{32,64}.7z`. Are my 4.8.0 assumptions valid?
1) For 32/64-bit C code, dwarf vs. sjlj is a don't care and there is no
measurable performance difference.
2) For 32/64-bit C code, win32 thread model is faster and doesn't create client
code dependency on `libwinpthread-1.dll`
3) For 32-bit C++ code, on must make dwarf/sjlj and posix/win32 threading
tradeoffs. Qt 5.1+ currently recommends dwarf+posix threading combo.
4) For 64-bit C++ code, the current "best" recommendation is dwarf+seh when
using 4.8.0+ unless one has other constraints.
Any other important tradeoffs/considerations?
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Runtime error when linking MingW-w64 with MSVCR90
> 2013/3/2 Jon :
> >> > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept
> >> > liboldname.
> >> Yes, for what purpose you need it?
> >
> > I'm updating my 32/64bit build systems to better automate how I use
> > mingw/mingw-w64, and have three followup questions:
> >
> > 1) Why do mingw-w64 based toolchains (rubenvb, mingwbuilds) only provide
> > `libmoldname.a` (objects linked to msvcrt, yes?) but mingw toolchains
> > provide `libmoldname{70,71,80,90,100}[d].a`?
>
> Well, default library we support is msvcrt.dll one. So we just taken
> care about moldname for it. In general it is better to add those
> alias to the default import-library. Having here an additional
> library looks to me awkward. It adds a dependency to a none-standard
> library without a good need.
>
> > 2) If one needs symbols from `libmoldname.a` and needs to link against a
> > CRT different than msvcrt.dll, what's the best way to resolve? For the
> > majority of use cases I expect libmoldname isn't needed so one can kill it
> > in a custom spec file, but I am curious as to "The mingw-w64 Way"
>
> Best way is to make moldname obsolete at all and add those aliases
> provided by libmoldname(???).a directly within msvcr???-import
> library. See for this the '==' command of .def file syntax.
>
> > 3) My objdump/nm fu is weaker than my curiousity...what's the easiest way
> > to discover the msvcrt version used by the objects in libraries like
> > `libmoldname.a`?
>
> In objects you won't have any chance to detect that. An object-file
> references symbols, which might be only present within specific
> version of msvcr???.dll-version, but you can't actual see that
> directly. An object (as a static library) isn't finally linked and
> therefore not strictly bound to one specific runtime-version.
Ah, so it's a load-time dynamic linking operation in which the i386 PE linker
embeds info (into the final dll/exe)
that windows uses to locate the correct msvcr???.dll, correct?
If yes, shouldn't the msvcr???.dll name referenced by the object-file symbols
be in the archive so that the PE linker
knows what info to embed into the final object? For example, I see the
following in libmoldname.a via `strings`:
C:\DevKit-4.7.2\mingw\i686-w64-mingw32\lib>strings libmoldname.a | grep -B
10 -A 3 msvcr
lib32_libmoldname_a-strcasecmp.o/
lib32_libmoldname_a-strncasecmp.o/
lib32_libmoldname_a-wcscmpi.o/
dmket.o/1348512452 1000 1000 100644 582 `
.text
0`.data
.bss
.idata$4
.idata$5
.idata$7
=> msvcrt.dll
.file
fake
.text
Hmm, `objdump` must not be able to extract this info from the archive. Probably
need to find/write a little PE dumper to walk the archive.
That said, is the only way to ensure the link uses msvcr90.dll and not
msvcrt.dll
is to do the following?
1) use `-static` since the gcc runtime dll's in rubenvb and mingwbuilds link
to msvcrt.dll
2) tweak `*cpp` spec entry to add `-D__MSVCRT_VERSION__=0x0900`
3) tweak the `*libgcc:` spec entry to (a) remove `-lmoldname`, and (b)
replace `-lmsvcrt` with `-lmsvcr90`
As always, very helpful Kai. Thank you (and Ernie) for your time and detailed
feedback.
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Runtime error when linking MingW-w64 with MSVCR90
> > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept
> > liboldname.
> Yes, for what purpose you need it?
I'm updating my 32/64bit build systems to better automate how I use
mingw/mingw-w64, and have three followup questions:
1) Why do mingw-w64 based toolchains (rubenvb, mingwbuilds) only provide
`libmoldname.a` (objects linked to msvcrt, yes?) but mingw toolchains provide
`libmoldname{70,71,80,90,100}[d].a`?
2) If one needs symbols from `libmoldname.a` and needs to link against a CRT
different than msvcrt.dll, what's the best way to resolve? For the majority of
use cases I expect libmoldname isn't needed so one can kill it in a custom spec
file, but I am curious as to "The mingw-w64 Way"
3) My objdump/nm fu is weaker than my curiousity...what's the easiest way to
discover the msvcrt version used by the objects in libraries like
`libmoldname.a`?
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] stale GeneralUsageInstructions wiki (was: Windows-hosted Mingw-w64)
> PS: we do have a wiki page that no one seems to find... (I'm not blaming you, > it's just an observation :P) > http://sourceforge.net/apps/trac/mingw-w64/wiki/GeneralUsageInstructions The page needs updating in the following areas. I'd push a draft but have forgotten my credentials :( * "Downloading the toolchain": add a link to the mingwbuilds project at http://sourceforge.net/projects/mingwbuilds/files/ * Are the sezero personal builds being maintained and still relevant? If not, remove their links. * "Installing the toolchain": both rubenvb and mingwbuilds have plain and name-prefixed tools in bin/ not just the listed name-prefixed versions, e.g - `gcc.exe` and `i686-w64-mingw32-gcc.exe` * "Using the toolchain": in addition to linking to MSYS, add a link to mingwbuilds uber-MSYS at http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ * "Using the toolchain": while you mentioned JonY's favorite build tool CMake, you forgot his second favorite...waf >;-> -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)
> Just fix MSYS Autotooling for the whole thing and use libxml2! > > ;-) Indeed...it's a new year and your hard-working dev system has earned a much needed upgrade ;) Here's another way of quickly getting an msys + mingw-w64 environment. First, download and extract these MSYS files, say to `C:\DevTools`: https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68 Next, download and extract one of Ruben's 32 or 64bit toolchains https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb into a newly created `C:\DevTools\mingw` (actually, just rename his `mingw32` or `mingw64` dir to `mingw`). Finally, add `C:\DevTools\bin` and `C:\DevTools\mingw\bin` to PATH and you've got a decent toolchain. Open up a Command Prompt and type `sh` and start using autohell. Better yet, create a desktop shortcut with a `Target:` of `C:\DevKit\msys.bat --mintty`, open it up and right-click -> Options... to set all kinds of eye candy like fonts, transparency, etc. This is begging for automation from a .ps1 or .py, but that's your chance to add value. mingwbuilds looks like they've built the killer monster truck msys binary with all sorts of awesomeness. Sadly, I haven't yet played with it. http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ But your dev system won't be satisfied. It will next want a bunch of VirtualBox VM's; mine squawked until I gave it Arch, Ubuntu Server, and Snow Leopard VMs each with cross-build support. Good luck. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
> > However, if you choose to use autotools, to better support the > > build-for-windows-on-windows scenario I ask that you also maintain a > > mingw32-make compatible Makefile. IIRC, this was Ozkan's suggestion near > > the very beginning of the discussion. > > Do you mean by this "not msys" ? Yes. I like msys, but a mingw32-make Makefile as the minimal-hassle baseline is faster-to-happy as one just needs to download Ruben or Nixman's toolchain and tweak PATH. No /etc/fstab or stuffing a mingw dir under msys. Ah, are you saying other tools are needed? I'd skimmed the repo, saw `update_liblist.pl`, dismissed it and thought all could be built via Makefile(s). Sounds like I got it wrong. Jon -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
ed to do to get all those pieces to play nicely together? Clearly not all are needed, but you get the point. Waste of time, but we're all grateful to the mingw.org folks for their hard work to make the pill a little less bitter. This drama is completely unnecessary, and toxic on many levels for a project. All one should need to do is download Ruben or Nixman's build, clone ironcrate, *possibly* download 1 easy-to-install build tool (I just can't give up on cmake or waf!), tweak PATH, and off you go to nirvana. Jon -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
> >> As for your concerns about CMake being available or not: it's > >> available from all Linux and BSD variants I know because more and more > >> projects are moving to CMake because more and more projects are > >> concerned about cross-platform, including MSVC. It's not something > >> esoteric. > > > > As far as I know, there are still a lot of project against the ideas > > of using CMake to replace the autotools. > > The main reason why we do not use cmake is that it makes things much > more complicated for the end-user, while adding additional maintenance > requirements that we should get for free from the build system. > > Here's what I mean. > > In the autotools world, there is a very defined and extremely enforced > concept that above all, our goal is to make it *TRIVIAL* for the end > user to compile your software. Now let's clarify this. The end user > is the guy who knows nothing about development, nor of your project, > nor of autotools, nor of anything else. But he needs your project for > some reason. We want that guy to be able to do this: > > cd /tmp; /path/configure && make What do you expect to be the breakdown of how you (as committers) will build/debug/test ironCrate? For example, are these the right categories and reasonable estimates? 75% - Build on Linux for Linux (Wine) [1] 22% - Cross-build on Linux for Windows 2.8% - Build on Windows for Windows (all MinGW flavors) 0.2% - Build on Windows for Windows (VC++) Now turn it around. What do you expect to be the build breakdown for devs trying to use ironCrate? Jon [1] I don't use Wine, but as Wine appears focused on other DLLs not the CRT this may be nonsensical. It's pure speculation/spelunking on my part. -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
On Mon, 12 Nov 2012 07:14:42 +0800 JonY wrote: > On 11/12/2012 03:36, Pau Garcia i Quiles wrote: > > On Sun, Nov 11, 2012 at 7:05 PM, Jon wrote: > > > >> So here's the question. > >> > >> Can the method I use when cross-compiling, namely, use cmake's > >> `ExternalProject` module (causes cmake to run itself and generate > >> artifacts in a different dir) to pre-build an environment on the build > >> system that's used by the cross build > >> > >> https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L7-14 > >> > >> address JonY's need to be able to build multiple flavors of cmake object > >> libraries, carry them around, and inject them into their respective static > >> libraries? > >> > >> I don't know as I haven't investigated. > > > > I have never been in that case. So far CMake script has been enough > > for me for this kind of cases (e. g. Wt filetostring). But take a look > > at this thread or ask in the CMake mailing list ( > > http://www.cmake.org/mailman/listinfo/cmake ) > > > > http://comments.gmane.org/gmane.comp.programming.tools.cmake.user/29310 > > > > From what I gather, I'll need to: > > 1. Write an external tool/driver to do this. > 2. Split into subprojects. > 3. Have cmake call itself recursively. > > Sounds complex, now that I've thought through this a bit. > > My chief concern is that we may end up with accepting a cmake-only > subproject, requiring users to have shell interpreters for the other > code AND cmake to complete the build. This kind of adds dependency with > questionable benefits for the amount of work done just to satisfy > Windows users. > > My further concern with going all-cmake only is that some code cannot be > built with MSVC, so it very much limits the perceived value to Windows > users, in addition to rustling Linux users who don't have cmake > installed previously. At this point in the discussion, I'm hoping Ruben is still scratching his ironCrate itch by building a cmake prototype so those interested can play cd build cmake -G Ninja .. && ninja all test cmake -G "MSYS Makefiles" .. && make all test cmake -G "NMake Makefiles" .. && nmake all test cmake .. && make all test cmake -G "Visual Studio 10" .. && msbuild ALL_BUILD.vcxproj /t:Build ... while he's keeping 10% of an eyeball on this thread for answers to his original non-cmake question. And if it works nicely...hmm, better seatbelt in for the next round of threads on managing complexity ;) Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
On Sun, 11 Nov 2012 19:13:04 +0800 JonY wrote: > On 11/11/2012 18:50, Pau Garcia i Quiles wrote: > > On Sun, Nov 11, 2012 at 11:27 AM, JonY wrote: > > > >>> What were the "rigidities"? Maybe I can help > >> > >> We need to a way to inject .a libraries with additional objects compiled > >> from a different step, > > > > See add_library(OBJECT): > > > > http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library > > > > (in the past you needed to list all the source files again -the > > recommendation was to use a variable- and they would get compiled > > again, with the new -potentitally diferent- cflags) > > > > Close, but not yet. > > "Object libraries may contain only sources (and headers) that compile to > object files. They may contain custom commands generating such sources, > but not PRE_BUILD, PRE_LINK, or POST_BUILD commands. Object libraries > cannot be imported, exported, installed, or linked." In the mruby project, the single file mruby executable contains both C library code and ruby script libraries (compiled into C) that's all linked together into a static lib. I use an object library to hold the C library code and bison output https://github.com/mruby/mruby/blob/master/src/CMakeLists.txt#L9 and add to the object library to create the final static lib https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L48-53 used to build the final single file mruby executable https://github.com/mruby/mruby/blob/master/tools/mruby/CMakeLists.txt#L3-5 But that usage doesn't address your concerns listed below. Moving on... > >> and a generic way to differentiate lib32/ and > >> lib64/ def file for differing processing arguments. > > > > I'm not sure I understand. > > > > Do you mean finding out whether you are on 32-bit or 64-bit and > > generating a different .def depending on that? Or taking a different > > .def file when you are compiling depending on whether you are on > > 32-bit or 64-bit and/or generating (maybe cross-compiling) for 32-bit > > or 64-bit? > > > > Whatever it is, there is a way to determine it. Or maybe I am missing > > what you mean? > > > > Pass different arguments to process them depending if they are from > lib32 or lib64. Of course, this should be done before the Object_Library > step. > > Some of the .c sources need to be compiled twice with different CFLAGS > and injected into their respective libraries. I don't have to do this for mruby, but I think what I do to use mruby's custom tools when cross-compiling could handle this scenario. I'm hoping Pau Garcia i Quiles will weigh in here. First, some background. mruby has part of its standard library as ruby scripts which need to be combined with the C-based portions of its standard library into a final single-file exe. These ruby scripts are "compiled" to a temp C file by the `mrbc` tool which uses the object library mentioned above. https://github.com/mruby/mruby/blob/master/tools/mrbc/CMakeLists.txt#L3-7 I also had to build a simple cross-platform `xpcat` tool (as we know Windows users don't have `cat` and we don't want to force them to find a port and futz with PATH) used to combine the ruby scripts into a single file compiled by `mrbc` into a C file. https://github.com/mruby/mruby/blob/master/tools/xpcat/xpcat.c When you're cross-compiling, these internal helper tools must be built and run on the build platform in order to create the cross build. All this must be done before you create the final static lib that uses the object library. https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L3-45 So here's the question. Can the method I use when cross-compiling, namely, use cmake's `ExternalProject` module (causes cmake to run itself and generate artifacts in a different dir) to pre-build an environment on the build system that's used by the cross build https://github.com/mruby/mruby/blob/master/mrblib/CMakeLists.txt#L7-14 address JonY's need to be able to build multiple flavors of cmake object libraries, carry them around, and inject them into their respective static libraries? I don't know as I haven't investigated. Jon -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
On Sun, 11 Nov 2012 09:39:26 +0800
JonY wrote:
> On 11/11/2012 02:22, Jon wrote:
> >
> > It's unfortunate you both had bad experiences with cmake. Cmake really is
> > quite powerful, and recent syntax mods make it friendlier to use.
> >
> > For example, I contributed the following cmake build scripts to the mruby
> > project
> >
> > https://github.com/mruby/mruby/blob/master/CMakeLists.txt
> > https://github.com/mruby/mruby/blob/master/tools/CMakeLists.txt
> > https://github.com/mruby/mruby/blob/master/tools/mruby/CMakeLists.txt
> >
> > https://github.com/mruby/mruby/blob/master/cmake/modules/IntrospectSystem.cmake
> >
> > which are fairly modular and maintainable.
> >
>
> They look clean, but mods? cmake has mods? These has to be installed by
> the end user too?
I meant cmake made syntax modifications (mods) so their DSL wasn't so ugly and
hard on the eyes and fingers.
Cmake enables you the committer to provide custom helper modules to make your
build easier to use and maintain. You put these helper modules wherever you
want in your source repo and put them on cmake's module path like:
https://github.com/mruby/mruby/blob/master/CMakeLists.txt#L69
I'm allergic to autotools but this appears similar to distribution/usage of
custom m4 macros. Users don't have to install your custom helpers.
> > Another nice thing about cmake is it's concept of "toolchain files" that
> > allow you to easily modularize cross-compiling build recipes. For example,
> > with the same basic structure as above, one creates toolchain "libraries"
> > to support different platforms:
> >
>
> "Toolchain files" for every system and triplet combination that you MAY
> want to support? This is one of the parts that I do not understand about
> cmake, why does it have to make cross-compile difficult?
>
> That is kind of backwards when autotools make it so simple to support
> cross compiles.
I think of toolchain files as just one way to help make cross-compiles easier.
As these are just cmake variables
https://github.com/mruby/mruby/blob/master/cmake/Toolchain-Arch-mingw32.cmake.sample#L12-30
I could envision one could wrap them in a main CMakeLists.txt file and drive
them from the cmd line similar to our beloved configure's --host, --target, and
--build. I think you can slice-n-dice it to best match how you want users to
experience your build process.
> > And one more thing, cmake generates ninja build files (yes, the ninja
> > single-file-exe runs on Windows and is easily built on Windows using mingw)
> > in addition to the plethora of other build files it supports. I use it to
> > build on Windows, Arch, Ubuntu and my quaint little Snow Leopard VB VM.
> >
> > If you looked at cmake awhile ago and hated it's odd syntax, things have
> > gotten better. You really should look at it again starting with the 2.8
> > series. Oh look, 2.8.10.1 just came out with binary downloads for your
> > favorite system.
> >
>
> Maybe, but I am still not keen on dealing with it in the future,
> especially in the mingw-w64 repository.
Obviously, you guys have to use what works for you. I simply wanted to provide
a perspective from a person who had used cmake years ago, hated it for so long
I reverted back to a cmake noob, but tried it again using cmake 2.8 and
powerfully naive noob eyes. I was pleased, but did have to invest some time.
And looking over the cmake stuff from the LLVM folks was a decent jumpstart
http://llvm.org/svn/llvm-project/llvm/trunk/
But, I'm also a long time autotools hater (impl not concepts) so build tools
like cmake, waf, and custom written configure.{py,rb} + ninja appeal to me.
Hey, where's the `go get github.com/mingw-w64/ironcrate` recipe? ;)
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ironCrate
On Sun, 11 Nov 2012 01:22:18 +0800 JonY wrote: > On 11/10/2012 23:39, Ozkan Sezer wrote: > > On 11/10/12, Ruben Van Boxem wrote: > >> 2012/11/10 Ozkan Sezer > >> > >>> On 11/10/12, Luis Lavena wrote: > >>>> On Sat, Nov 10, 2012 at 10:54 AM, Ruben Van Boxem > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> I have the crazy idea to help with ironCrate. > >>>>> > >>>>> I have written a small CMakeLists.txt file to get automated > >>>>> compilation > >>>>> working (I know you guys favor autotools, I don't). I am running into > >>>>> some > >>>>> issues building the source from the get-go. > >>>>> > >>>> > >>>> I think CMake is already the proposed solution: > >>>> > >>>> > >>> http://sourceforge.net/apps/trac/mingw-w64/wiki/devel%20crt%20licensing,%20Coding-style,%20and%20more > >>>> > >>>> As CMake provides the generation of MinGW/MSYS makefiles and Visual > >>>> Studio project files, which is the goal of ironCrate (be compatible > >>>> with both compilers) > >>>> > >>> > >>> It still amazed why we are not using plain old makefiles. > >>> oh well.. > >>> > >>> > >> Probably because you'd have to write three sets of makefiles: nmake, msys > >> make, and mingw32-make, which really is kinda silly... > > > > I don't think that composing different makefiles for mingw- and msys- > > versions of make would be necessary but yes one would be necessary > > for nmake. Two, or even three different makefiles I consider as fair price > > against dealing with complexities and/or extra dependencies of cmake > > or autotools. > > > > Please, no cmake, even custom makefiles, shell scripts, Python scripts, > Perl scripts, just no cmake. > > cmake is a maintenance nightmare with it's shell-but-not-shell syntax. It's unfortunate you both had bad experiences with cmake. Cmake really is quite powerful, and recent syntax mods make it friendlier to use. For example, I contributed the following cmake build scripts to the mruby project https://github.com/mruby/mruby/blob/master/CMakeLists.txt https://github.com/mruby/mruby/blob/master/tools/CMakeLists.txt https://github.com/mruby/mruby/blob/master/tools/mruby/CMakeLists.txt https://github.com/mruby/mruby/blob/master/cmake/modules/IntrospectSystem.cmake which are fairly modular and maintainable. Another nice thing about cmake is it's concept of "toolchain files" that allow you to easily modularize cross-compiling build recipes. For example, with the same basic structure as above, one creates toolchain "libraries" to support different platforms: https://github.com/mruby/mruby/tree/master/cmake Want to cross-compile from your favorite Arch system? https://github.com/mruby/mruby/blob/master/cmake/Toolchain-Arch-mingw32.cmake.sample Or how about Ubuntu? https://github.com/mruby/mruby/blob/master/cmake/Toolchain-Ubuntu-mingw32.cmake.sample Or maybe you fancy OSX? https://github.com/mruby/mruby/blob/master/cmake/Toolchain-OSX-mingw32.cmake.sample Or maybe you really got bored and decided to cross-compile for OpenWRT... https://github.com/mruby/mruby/blob/master/cmake/Toolchain-OpenWRT-ANY.cmake You get the point. And one more thing, cmake generates ninja build files (yes, the ninja single-file-exe runs on Windows and is easily built on Windows using mingw) in addition to the plethora of other build files it supports. I use it to build on Windows, Arch, Ubuntu and my quaint little Snow Leopard VB VM. If you looked at cmake awhile ago and hated it's odd syntax, things have gotten better. You really should look at it again starting with the 2.8 series. Oh look, 2.8.10.1 just came out with binary downloads for your favorite system. Jon -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)
On Fri, 2 Nov 2012 15:20:10 -0400 Earnie Boyd wrote: > On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote: > > > > I settled for the "fix" of using mingw.org gcc 4.6.2 32bit but don't > > understand why it works since the 4.6.2 .pyd's still have deps on > > msvcr90.dll and msvcrt.dll...need to try again with a custom spec to force > > everything to msvcr90.dll and try with > > http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/ > > > > There are ABI changes between mingw.org's 4.6.2 and 4.7 that require > all libraries to use one or the other. I don't know if nixMan's > releases would have the same issue but if it were me I would be sure > to rebuild all libraries and modules with the same compiler. You are > likely to have issues between mingw.org's gcc built libraries and > other's releases of gcc. Ah, good to know. My goal is to use the official Python binary (VC built?) and use mingw-w64 4.7.2 (Ruben or nixMan's) to build the modules, and not have to build everything with the same toolchain. I'm hoping my load fail (and the OP's) turns out to be the issue of modules linking against two different CRT versions. PeStudio tells me my msvcrt.dll linked .pyd's try to use _errno, __dllonexit, fflush, free, malloc, and strcmp from msvcr90.dll. Looks like the infamous crossing DLL boundries/separate DLL state issue that should disappear when linking against the same CRT. Jon -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Error building python extension (DLL load failed: invalid access to memory location)
> I am trying to build compiled python modules, which use some compiled > libraries (boost, in particular). The system is Windows 7 64bit Pro. One > of them (http://pypi.python.org/pypi/minieigen/0.3-4) works fine, > another one (source not publicly available yet) does not. FYI, I had a similar (intermittent) runtime failure awhile ago on win7 ultimate 32bit when trying to use the mercurial native module: http://sourceforge.net/mailarchive/message.php?msg_id=27964784 I thought it might be due to the official python27.dll being linked against mscvr90.dll while the .pyd's try to use both mscvr90.dll and msvcrt.dll. Never got time to go back and try to debug. I settled for the "fix" of using mingw.org gcc 4.6.2 32bit but don't understand why it works since the 4.6.2 .pyd's still have deps on msvcr90.dll and msvcrt.dll...need to try again with a custom spec to force everything to msvcr90.dll and try with http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/ Jon -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?
> So I would like to get your opinion. You might have complete > different opinion about planning mingw-w64's release-cycles, so don't > hesitate to tell us what you think about this subject. First, thanks for keeping the discussion open. It has been informative so far. Second, as a consumer of mingw-w64 artifacts via Ruben and nixman's notable efforts, I share NightStrike's perspective and have the following amplifications: 1) Non-discretion based major version release cycles are likely to decrease usability if the mindset moves to only-release-at-specific-timeframes from release-when-feature-ready based upon real-world demand and committer evaluation. I much prefer that you guys stay motivated to push out features when ready than potentially waiting for artificial timeframes. The mingw-w64 project is vastly different than Ubuntu. 2) mingw-w64 is ingredient technology useful for downstream integrators such as Ruben and nixman. Changing mingw-w64 to schedule based releases may negatively affect their releases. Better to push out the features when ready and count on their expertise/ability to manage which version should be part of their release. As an added benefit, mingw-w64 committers can push certain classes of support issues downstream where they belong"Our release X.Y.Z release addresses the issue. Talk to ? and ask them update their release." Keep Ruben from slacking ;) Continue to focus on what you do well: release quality versions when they're ready, and enable downstream integrators to choose the version they feel is the best for their needs. Hard, schedule-based major version release cycles aren't a good fit for mingw-w64. Perhaps for other projects similar to Ubuntu, but not mingw-w64. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libuv build fail with 32bit rubenvb 4.7.1
On Mon, Sep 24, 2012 at 8:15 AM, Ruben Van Boxem wrote: > 2012/9/24 Ozkan Sezer >> >> On Mon, Sep 24, 2012 at 10:30 AM, Ruben Van Boxem >> wrote: >> > 2012/9/24 Jon >> >> >> >> > > fyi...the following libuv build fail still exists in >> >> > > `i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z` >> >> > > >> >> > >> >> > Yes, that's to be expected. There was no new tagged MinGW-w64 >> >> > release. >> >> > The >> >> > previous easy fix still applies. >> >> > >> >> > Ruben >> >> >> >> Yes, using tagged vs. non-tagged is an interesting call. >> > >> > >> > THat's what a "release" version usually implies. This is a choice I make >> > to >> > keep things clear. I'm also thinking about using gdb/binutils release >> > versions, even if it would only lead to more consistency. >> > >> >> >> >> But I also don't like wasting brain cells remembering >> >> lists-o-easy-fixes >> >> per toolchain, or your toolchain currently being the odd man out with >> >> code >> >> like that in a library such as libuv. >> >> >> >> >> >> mingw-builds 4.7.2: PASS >> >> tdm 4.7.1: PASS >> >> mingw 4.6.2: PASS >> >> rubenvb 4.7.2: FAIL >> >> >> > >> > All these use either the SVN v2.x or trunk MinGW-w64. I chose not to. >> > Neither will any Linux distro providing MinGW-w64. Although those might >> > backport patches if they really want to. I am not forcing you to abandon >> > your previously working/fixed toolchain. You can even just copy over all >> > of >> > mingw64/x86_64-w64-mingw32 or mingw32/i686-w64-mingw32 because that part >> > has >> > not changed since the previous build. >> > >> >> >> >> I've happily used your builds for awhile now as my reference MinGW-w64 >> >> toolchain. Perhaps in the future when you guys see similar issues that >> >> impact well known libraries, a patch MinGW-w64 release can be quickly >> >> tagged >> >> as a way of helping downstream integrators release updates in a non >> >> ad-hoc >> >> manner. >> > >> > >> > I understand, and this happens regularly, just not always. Stable tags >> > can't >> > be updated each time a specific fix has landed. For every project in the >> > world it takes more than one fix to release a new version. I will build >> > an >> > update package or provide a new build as soon as possible after this >> > happens. >> > >> > Please use a toolchain that works for you. And update minor versions >> > only >> > when you need to. >> > >> > Ruben >> > >> >> FWIW, I just tagged and released v1.0.7 and v2.0.7 mingw-w64 headers and >> crt. > > > I had a feeling this would happen :P > > I am uploading updated mingw-w64 v2.0.7 update packages "update" on > Sourceforge: > sourceforge.net/projects/mingw-w64/files/Toolchains targetting > Win64/Personal Builds/rubenvb/update/ > sourceforge.net/projects/mingw-w64/files/Toolchains targetting > Win32/Personal Builds/rubenvb/update/ > > Just extract and overwrite. > > Enjoy, > > Ruben > Both v2.0.7 downloads at http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/update/ appear to be 64bit not 32bit as they have the `mingw64/x86_64-w64-mingw32` subdir. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libuv build fail with 32bit rubenvb 4.7.1
> 2012/9/24 Ozkan Sezer > > > On Mon, Sep 24, 2012 at 10:30 AM, Ruben Van Boxem > > wrote: > > > 2012/9/24 Jon > > >> > > >> > > fyi...the following libuv build fail still exists in > > >> > > `i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z` > > >> > > > > >> > > > >> > Yes, that's to be expected. There was no new tagged MinGW-w64 release. > > >> > The > > >> > previous easy fix still applies. > > >> > > > >> > Ruben > > >> > > >> Yes, using tagged vs. non-tagged is an interesting call. > > > > > > > > > THat's what a "release" version usually implies. This is a choice I make > > to > > > keep things clear. I'm also thinking about using gdb/binutils release > > > versions, even if it would only lead to more consistency. > > > > > >> > > >> But I also don't like wasting brain cells remembering lists-o-easy-fixes > > >> per toolchain, or your toolchain currently being the odd man out with > > code > > >> like that in a library such as libuv. > > >> > > >> > > >> mingw-builds 4.7.2: PASS > > >> tdm 4.7.1: PASS > > >> mingw 4.6.2: PASS > > >> rubenvb 4.7.2: FAIL > > >> > > > > > > All these use either the SVN v2.x or trunk MinGW-w64. I chose not to. > > > Neither will any Linux distro providing MinGW-w64. Although those might > > > backport patches if they really want to. I am not forcing you to abandon > > > your previously working/fixed toolchain. You can even just copy over all > > of > > > mingw64/x86_64-w64-mingw32 or mingw32/i686-w64-mingw32 because that part > > has > > > not changed since the previous build. > > > > > >> > > >> I've happily used your builds for awhile now as my reference MinGW-w64 > > >> toolchain. Perhaps in the future when you guys see similar issues that > > >> impact well known libraries, a patch MinGW-w64 release can be quickly > > tagged > > >> as a way of helping downstream integrators release updates in a non > > ad-hoc > > >> manner. > > > > > > > > > I understand, and this happens regularly, just not always. Stable tags > > can't > > > be updated each time a specific fix has landed. For every project in the > > > world it takes more than one fix to release a new version. I will build > > an > > > update package or provide a new build as soon as possible after this > > > happens. > > > > > > Please use a toolchain that works for you. And update minor versions only > > > when you need to. > > > > > > Ruben > > > > > > > FWIW, I just tagged and released v1.0.7 and v2.0.7 mingw-w64 headers and > > crt. > > > > I had a feeling this would happen :P > > I am uploading updated mingw-w64 v2.0.7 update packages "update" on > Sourceforge: > sourceforge.net/projects/mingw-w64/files/Toolchains targetting > Win64/Personal Builds/rubenvb/update/ > sourceforge.net/projects/mingw-w64/files/Toolchains targetting > Win32/Personal Builds/rubenvb/update/ > > Just extract and overwrite. > > Enjoy, Fabulous. I'm off to confirm my automated toolchain integration scripts can take advantage of this between-release-update awesomeness :) It doesn't get said as often as it should, but a huge THANK YOU to those of you who donate their time and energy to make these toolchains (rubenvb, mingw-builds, tdm, mingw) possible, work well, and add so much value. Selecting tags/commits/versions that work well together is no small task. Without your continued efforts, downstream toolchain integration like the following wouldn't be so easy: https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-36 https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/tdm_mingw.rb#L3-44 https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingwbuilds.rb#L3-36 I am grateful. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libuv build fail with 32bit rubenvb 4.7.1
> > fyi...the following libuv build fail still exists in
> > `i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z`
> >
>
> Yes, that's to be expected. There was no new tagged MinGW-w64 release. The
> previous easy fix still applies.
>
> Ruben
Yes, using tagged vs. non-tagged is an interesting call.
But I also don't like wasting brain cells remembering lists-o-easy-fixes per
toolchain, or your toolchain currently being the odd man out with code like
that in a library such as libuv.
mingw-builds 4.7.2: PASS
tdm 4.7.1: PASS
mingw 4.6.2: PASS
rubenvb 4.7.2: FAIL
I've happily used your builds for awhile now as my reference MinGW-w64
toolchain. Perhaps in the future when you guys see similar issues that impact
well known libraries, a patch MinGW-w64 release can be quickly tagged as a way
of helping downstream integrators release updates in a non ad-hoc manner.
Jon
>
> >
> >
> > > On 9/11/12, Jon wrote:
> > > > In an custom msys wrapped
> > > > `i686-w64-mingw32-gcc-4.7.1-2-release-win32_rubenvb.7z` toolchain I
> > get the
> > > > following build fail with libuv that doesn't occur when I use a
> > mingw.org
> > > > based 4.6.2 toolchain.
> > > >
> > > > C:\Users\Jon\Documents\CDev\libuv-git>make
> > > > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89
> > -D_WIN32_WINNT=0x0600 -c
> > > > src/win/async.c -o src/win/async.o
> > > > ...
> > > > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89
> > -D_WIN32_WINNT=0x0600 -c
> > > > src/win/udp.c -o src/win/udp.o
> > > > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89
> > -D_WIN32_WINNT=0x0600 -c
> > > > src/win/util.c
> > > > -o src/win/util.o
> > > > In file included from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
> > > > from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
> > > > from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:13,
> > > > from src/win/util.c:34:
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:988:3:
> > > > error: unknown type name 'IsolationState'
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:989:3:
> > > > error: unknown type name 'ProbationTime'
> > > > In file included from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:16:0,
> > > > from src/win/util.c:34:
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:182:3:
> > > > error: unknown type name 'NDIS_MEDIUM'
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:183:3:
> > > > error: unknown type name 'NDIS_PHYSICAL_MEDIUM'
> > > > make: *** [src/win/util.o] Error 1
> > > >
> > > >
> > > >
> > > > Using this simple snippet
> > > >
> > > > #define _WIN32_WINNT 0x0601
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > int main(int argc, char *argv[])
> > > > {
> > > > return 0;
> > > > }
> > > >
> > > > I'm able to replicate the failure
> > > >
> > > > C:\Users\Jon\Documents\CDev\sandbox>gcc --version
> > > > gcc (rubenvb-4.7.1-2-release) 4.7.1
> > > > ...
> > > > C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o iphlpapi.exe
> > > > iphlpapi_test.c -lws2_32
> > > > In file included from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
> > > > from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
> > > > from
> > > >
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/
Re: [Mingw-w64-public] libuv build fail with 32bit rubenvb 4.7.1
fyi...the following libuv build fail still exists in
`i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z`
> On 9/11/12, Jon wrote:
> > In an custom msys wrapped
> > `i686-w64-mingw32-gcc-4.7.1-2-release-win32_rubenvb.7z` toolchain I get the
> > following build fail with libuv that doesn't occur when I use a mingw.org
> > based 4.6.2 toolchain.
> >
> > C:\Users\Jon\Documents\CDev\libuv-git>make
> > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
> > src/win/async.c -o src/win/async.o
> > ...
> > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
> > src/win/udp.c -o src/win/udp.o
> > gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
> > src/win/util.c
> > -o src/win/util.o
> > In file included from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
> > from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
> > from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:13,
> > from src/win/util.c:34:
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:988:3:
> > error: unknown type name 'IsolationState'
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:989:3:
> > error: unknown type name 'ProbationTime'
> > In file included from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:16:0,
> > from src/win/util.c:34:
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:182:3:
> > error: unknown type name 'NDIS_MEDIUM'
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:183:3:
> > error: unknown type name 'NDIS_PHYSICAL_MEDIUM'
> > make: *** [src/win/util.o] Error 1
> >
> >
> >
> > Using this simple snippet
> >
> > #define _WIN32_WINNT 0x0601
> >
> > #include
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > return 0;
> > }
> >
> > I'm able to replicate the failure
> >
> > C:\Users\Jon\Documents\CDev\sandbox>gcc --version
> > gcc (rubenvb-4.7.1-2-release) 4.7.1
> > ...
> > C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o iphlpapi.exe
> > iphlpapi_test.c -lws2_32
> > In file included from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
> > from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
> > from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:13,
> > from iphlpapi_test.c:5:
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:988:3:
> > error: unknown type name 'IsolationState'
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:989:3:
> > error: unknown type name 'ProbationTime'
> > In file included from
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:16:0,
> > from iphlpapi_test.c:5:
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:182:3:
> > error: unknown type name 'NDIS_MEDIUM'
> > c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:183:3:
> > error: unknown type name 'NDIS_PHYSICAL_MEDIUM'
> >
> >
> > What have I forgotten to do?
> >
> > Jon
> >
>
> Should be fixed by adding missing includes to headers.
> Just pushed rev. 5386 for this:
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revision&revision=5385
>
> --
> O.S.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] libuv build fail with 32bit rubenvb 4.7.1
In an custom msys wrapped
`i686-w64-mingw32-gcc-4.7.1-2-release-win32_rubenvb.7z` toolchain I get the
following build fail with libuv that doesn't occur when I use a mingw.org based
4.6.2 toolchain.
C:\Users\Jon\Documents\CDev\libuv-git>make
gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
src/win/async.c -o src/win/async.o
...
gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
src/win/udp.c -o src/win/udp.o
gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0600 -c
src/win/util.c
-o src/win/util.o
In file included from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:13,
from src/win/util.c:34:
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:988:3:
error: unknown type name 'IsolationState'
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:989:3:
error: unknown type name 'ProbationTime'
In file included from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:16:0,
from src/win/util.c:34:
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:182:3:
error: unknown type name 'NDIS_MEDIUM'
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:183:3:
error: unknown type name 'NDIS_PHYSICAL_MEDIUM'
make: *** [src/win/util.o] Error 1
Using this simple snippet
#define _WIN32_WINNT 0x0601
#include
#include
#include
int main(int argc, char *argv[])
{
return 0;
}
I'm able to replicate the failure
C:\Users\Jon\Documents\CDev\sandbox>gcc --version
gcc (rubenvb-4.7.1-2-release) 4.7.1
...
C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -o iphlpapi.exe iphlpapi_test.c
-lws2_32
In file included from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/mprapi.h:10:0,
from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iprtrmib.h:9,
from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:13,
from iphlpapi_test.c:5:
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:988:3:
error: unknown type name 'IsolationState'
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/ras.h:989:3:
error: unknown type name 'ProbationTime'
In file included from
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/iphlpapi.h:16:0,
from iphlpapi_test.c:5:
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:182:3:
error: unknown type name 'NDIS_MEDIUM'
c:\devkit-4.7.1\mingw\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/netioapi.h:183:3:
error: unknown type name 'NDIS_PHYSICAL_MEDIUM'
What have I forgotten to do?
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Rubenvb GCC 4.7.1 release builds
On Sun, Jun 17, 2012 at 12:58 PM, niXman wrote: > 2012/6/17 K. Frank: >> Okay, thanks for the info. I'll probably wait for a std::thread-enabled >> 4.7.1 release before I consider upgrading. (As I mentioned, I'm not >> facing any particular issue.) > > In my builds std_concurrency is enabled: > https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/ This also means one must have libwinpthreads-1.dll on PATH when using mingwbuilds for C or C++ apps, correct? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] msys ./configure gives error 77, "compiler doesn't generate exe's"
>> configure:1340: checking for gcc
>> configure:1356: found /c/Program Files/OpenAxiom/bin/gcc
You're begging for failures when you install to a PATH with spaces. For example:
C:\Users\Jon\Documents\CDev\sandbox>echo %PATH%
C:\"spacey path\mingw-rvb\bin";...
C:\Users\Jon\Documents\CDev\sandbox>type helloworld.c
#include
int main(int argc, char *argv[]) { printf("Hello World!\n"); return 0; }
C:\Users\Jon\Documents\CDev\sandbox>gcc --version
gcc (rubenvb-4.6.3) 4.6.3
...
C:\Users\Jon\Documents\CDev\sandbox>gcc -Wall -O3 -o hw.exe helloworld.c
gcc: error: CreateProcess: No such file or directory
Jon
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Can not get C++ "Hello World" running
> On Sun, Jun 3, 2012 at 12:59 PM, Thomas Natschläger > wrote: >> Hello! >> >> I'm a new to using MinGW64. I just tried to get a C++ style "Hello World" >> running but can not get it run. I'm running Windows 7 Home Premium 64bit on >> a Pentium(R) Dual Core CPU T4500@2.3GHz. >> >> I did the following: >> >> 1) Installed mingw-w64-bin_i686-mingw_20111220.zip (from >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Wi >> n64/Automated%20Builds/) under C:\MingGW64 which seems to work (see output >> of the command "C:\MinGW64\bin\x86_64-w64-mingw32-g++ -v --version" below) As you're running the toolchain on Windows, I highly recommend you try one of the "personal" builds. For one, look at the date of the automated download: 20111220 I've had very good experiences with the `rubenvb` builds (he's currently got GCC 4.6.3 and 4.7.0 release builds) and the `mingwbuilds` from http://sourceforge.net/projects/mingwbuilds/files/ I find both the usability and the size-on-disk to be superior to the current automated `*-bin_i686-mingw_*.zip` builds. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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 MSYS version questions.
> > Then what is the point of the MinGW-w64 version of the MSYS > > package? Only changes to /etc or something more complex? > > This package originated from before mingw-get. I like the unzip+use > > philosophy for development tools, as I move stuff around a lot. So I > > manually downloaded all MSYS packages and stuffed them together. Nothing > > more :). > That's it? i'm guilty. i wrongly thought that this MinGW-w64 > version of MSYS was patched to allow the new toolchain to > be ran from it. This is good news for me! As part of another project, I aggregate the mingw.org MSYS packages with mingw-w64 builds...we call it the oh so clever...wait for it...DevKit. It's got other goodies and things that make Ruby on Windows users happy, but it's also a standalone development toolchain. Currently we allow building of a 4.6.3 flavor based upon Ruben's build, and a 4.7.1 edge build based on the niXman's mingwbuilds project. MSYS artifacts: https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-68 mingw-w64 builds: https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb In fact, I just updated and smoke tested the 4.7.1 mingwbuilds flavor https://github.com/oneclick/rubyinstaller/commit/a7e8db081c627c872d95ffb7b3d6fec213419f55 Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] gmtime_s usage
In C, I'm trying to portably implement gmtime_r (I'm aware of the gmtime_r
macro and comments in time.h) using gmtime_s and this snippet appears to work
fine. What's a cleaner or more robust solution?
#include
#include
#include
#if defined(__MINGW64_VERSION_MAJOR)
/* XXX why isn't this in sec_api/time_s.h? */
# if defined(_USE_32BIT_TIME_T)
# define gmtime_s _gmtime32_s
# else
# define gmtime_s _gmtime64_s
# endif
#elif defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR)
# define BUILDING_WITH_MINGW32
# define gmtime_r(tp, tm) (gmtime((tp)))
# define localtime_r(tp, tm) (localtime((tp)))
#endif
#if defined(_MSC_VER) || defined(__MINGW64_VERSION_MAJOR)
# define gmtime_r(tp, tm) ((gmtime_s((tm), (tp)) == 0) ? (tm) : NULL)
# define localtime_r(tp, tm) ((localtime_s((tm), (tp)) == 0) ? (tm) : NULL)
#endif
int
main(int argc, char *argv[])
{
time_t rawtime;
struct tm utc_tm, local_tm, tmp_tm, *my_utc_tm, *my_local_tm;
char buffer[1024] = "";
time(&rawtime);
my_utc_tm = gmtime_r(&rawtime, &utc_tm);
#ifdef BUILDING_WITH_MINGW32
/* save the *utc_tm so it doesn't get clobbered */
memcpy(&tmp_tm, my_utc_tm, sizeof(struct tm));
my_utc_tm = &tmp_tm;
#endif
my_local_tm = localtime_r(&rawtime, &local_tm);
if (strftime(buffer, sizeof(buffer),
"UTC: %A, %B %d, %Y %H:%M", my_utc_tm))
puts(buffer);
if (strftime(buffer, sizeof(buffer),
"Local: %A, %B %d, %Y %H:%M %z", my_local_tm))
puts(buffer);
return 0;
}
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New automated build for mingw?
> On 3/22/2012 2:01 PM, Jon wrote: > >> Would it be possible to generate a new automated build for mingw? If > >> I remember correctly the mingw build-bots were down? > > > > Perhaps it's time to rethink the current automated build strategy with an > > eye on dramatic simplification. Something that's less onerous, less > > complex, and more in line with the current project resourcing realities. > > > First, I apologize for not being around enough to fix the buildbot > issues; I never managed to get the bus factor high enough before > effectively disappearing for personal reasons. > > The only real reason to use buildbot for releases of any sort that I > know of was simply to use the slaves. It is quite possible to manually > roll a build identical to the buildbot using the makefile - after all, > buildbot just grabs the copy from (IIRC) svn head anyway. > > Of course, there is no reason to continue using the makefiles if there > are better alternatives; it was chosen to be able to 1) let buildbot > specify a target, and 2) locally build up to a target, and possibly > retry. To be honest, it's a bit ugly - there just didn't seem to be > less-bad alternatives at the time. > > The builds (binaries) themselves were uploaded more as an afterthought - > we already build them, and it might be useful for developer testing. > The (obsolete) plan was to one day let buildbot handle releases (svn > tag) as well; there are bits in the buildbot setup left to try to handle > this, though I suspect it's broken. > > In general: I strongly agree that the current situation isn't very good, > and wish you luck on whatever you can to fix it - I will try to answer > questions, though I suspect my response time might not be awesome. Keep > buildbot or not, just do better than I did ;) Thanks for the background as it's helpful on many levels. Please don't take my discussion as anything other than trying to investigate options. It's tough to sustain an OSS project over time, and no one wants to feel that scratching their OSS itch has morphed into a support jail sentence, or creosote bush to real life. That's a recipe for burn out and project stagnation. Based upon the replies so far, for me, the issue is closed. Any of my future efforts will focus on (a) submitting pull requests for Ruben's review, and/or (b) submit patches to the existing makefile's based upon my current post-processing of the mingw binary downloads to correct for what I consider usage problems. Jon -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
