[Mingw-w64-public] msys2-mingw64 cmake gives undefined behaviour, can not find include header

Hi, Migrating a code to msys2 compilation (cmake inside msys ),mingw64 does not find an include file for unknwon reason. the file is located in a project defined as follow: cmake_minimum_required(VERSION 3.10) project(include_commun) add_library(include_commun INTERFACE)

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

Thanks for the replies with answers and information. I now know to not rely on the defaults. Kind regards Disclaimer: This mail transmission and any attached files are confidential and are intended for the addressee only. If you are not the person or organization to whom it is addressed,

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

It's the mingw-w64-i686-headers-git package where it's defined. Generally partial upgrades of MSYS2 are not supported but if you to be on your own keep in mind crt, headers or winpthreads always have to be in the same version. MSYS2 had to bump WINNT because some package require Windows 7 features

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

On 1/10/2019 5:00 AM, Tempelaar E. (Erik) wrote: I recently reconfigured a build environment for a mingw-built application but I ran into issues on Windows 10 caused by a #define _WIN32_WINNT in C:\msys64\mingw32\i686-w64-mingw32\include\_mingw.h In my installation it targets WINNT 0x0601

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

在 2019/1/10 18:00, Tempelaar E. (Erik) 写道: > I recently reconfigured a build environment for a mingw-built application but > I ran into issues > on Windows 10 caused by a #define _WIN32_WINNT in > C:\msys64\mingw32\i686-w64-mingw32\include\_mingw.h > > In my installation it targets WINNT 0x0601

[Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

I recently reconfigured a build environment for a mingw-built application but I ran into issues on Windows 10 caused by a #define _WIN32_WINNT in C:\msys64\mingw32\i686-w64-mingw32\include\_mingw.h In my installation it targets WINNT 0x0601 #ifndef _WIN32_WINNT #define _WIN32_WINNT 0x601

Re: [Mingw-w64-public] [Msys2-users] type and size of MB_CUR_MAX on mingw64

在 2019/1/2 9:19, Óscar Fuentes 写道: > Valerio Messina via Msys2-users > writes: > >> #include >> MB_CUR_MAX while it must store a number between 1 and MB_LEN_MAX (that >> is almost always 16), it is of type 'size_t', so 4 Bytes on 32 bit >> systems, and 8 Bytes on 64 bit systems. This is valid

Re: [Mingw-w64-public] [Msys2-users] MinGW64 gfortran issue

Can you provide some details? I just downloaded MinGW-w64 (so without MSYS2) onto a laptop running Windows 10 and created a version of the veneral hello program with gofrtran. It ran without any difficulties. Regards, Arjen Op di 25 sep. 2018 om 08:48 schreef Liu Hao : > > 在 2018/9/24 23:37,

Re: [Mingw-w64-public] [Msys2-users] MinGW64 gfortran issue

Hi Bill, with the buildgf.bat batch file as you sent it I indeed got the error message that the 16-bits application it was trying to run was incompatible with the system. But then I examined the list of compile options and saw that you use "-c" as the first and "-oLOOPFIND.EXE" as the last. This

Re: [Mingw-w64-public] [Msys2-users] MinGW64 gfortran issue

I have attached a 7z file with one of the programs I am trying to convert. Old legacy Fortran stuff.Hope this helps. The file "Send.sample" should be renamed "Send.7z" before uncompressing. It contains fortran source, a batch file to compile and link, and a data file to run against the program.

Re: [Mingw-w64-public] [Msys2-users] MinGW64 gfortran issue

OK I give up. Every time I try to send something, your email system bounces it back. Bill From: Arjen Markus To: lh_mo...@126.com Cc: mingw-w64-public@lists.sourceforge.net; w.brand...@ameritech.net; msys2-us...@lists.sourceforge.net Sent: Tuesday, September 25, 2018 3:12 AM Subject:

Re: [Mingw-w64-public] [Msys2-users] MinGW64 gfortran issue

I have attached a 7z file with one of the programs I am trying to convert. Old legacy Fortran stuff.Hope this helps. Thanks for your help Bill From: Arjen Markus To: lh_mo...@126.com Cc: mingw-w64-public@lists.sourceforge.net; w.brand...@ameritech.net; msys2-us...@lists.sourceforge.net

Re: [Mingw-w64-public] MSYS2 dlltool finds no symbols in Oracle jvm.dll, is that to be expected?

Thanks! Indeed, using gendef works and I get a lot of exports from the dll! I also checked dlltool from mingw-w64 and it does not export anything, so gendef seems to be the way to go! Thanks again! On 19.08.2016 20:32, The Canadian Bacon wrote: > I'm not an msys2 dev but have you tried

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

I get the same failure here [1], smallest reproducible test case so far, unfortunately, seems to be cross compiling ffmpeg like ffmpeg's configure --arch=x86_64 --target-os=mingw32 --enable-librubberband --enable-gpl then it fails (no msys2 at play at all in this case). [1]

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

LRN, the author of the libitm patch of MSYS2 gcc package, suggested disabling it: [22:57:27] LRN, wasn't you the guy who wrote the enable-libitm patch for MSYS2 ? [22:57:36] s/wasn't/weren't/ [22:57:42] that is quite possible [22:58:02] possible ? :S [22:58:07] I don't remember [22:58:13]

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

I have compiled ffmpeg with LDFLAGS='-static-libgcc -static-libstdc++' and Stud_PE says ffmpeg.exe doesn't import anything from libitm, nor does it import anything from libstdc++, libgcc, libiconv, etc. I also asked it on #mingw-w64 on OFTC and people said it seemed mere undefined references

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

On 25 July 2016 at 12:18, lh mouse wrote: > I have compiled ffmpeg with LDFLAGS='-static-libgcc -static-libstdc++' and > Stud_PE says ffmpeg.exe doesn't import anything from libitm, nor does it > import > anything from libstdc++, libgcc, libiconv, etc. > > It doesn't, by

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

I have compiled ffmpeg with LDFLAGS='-static-libgcc -static-libstdc++' and Stud_PE says ffmpeg.exe doesn't import anything from libitm, nor does it import anything from libstdc++, libgcc, libiconv, etc. I also asked it on #mingw-w64 on OFTC and people said it seemed mere undefined references

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

Recompiling GCC with https://github.com/Alexpux/MINGW-packages/pull/1588/commits/ba282a67e971e045131291fd0f21ef786b82b1b1 seems to fix the issue for me. I don't know enough to be sure this doesn't break anything else. The alternative would be disabling the patch that enables libitm, but I assumed

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

It looks normal. I thought it could be caused by linking a 64-bit object file against a 32-bit library. Fortunately, it isn't the case. FWIW, two months ago I sent a pull request about the GCC relocation bug here: https://github.com/Alexpux/MINGW-packages/pull/1444 A few days ago on IRC, alexey

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

Additionally, someone else also got these same errors with a self-compiled GCC 6[1], so it's maybe not specific to MSYS2-compiled GCC but something involving GCC 6 and mingw-w64. [1] https://github.com/lachs0r/mingw-w64-cmake/commit/ac8e62c493d5ebebe61e59d1db39bfb1c08e7888

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

On 2016-07-24 16:14, lh mouse wrote: > Try this command and reply with its output: > > objdump -f > "C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a" > | grep "cow-stdexcept.o" > $ objdump -f

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

Try this command and reply with its output: objdump -f "C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a" | grep "cow-stdexcept.o" -- Best regards, lh_mouse 2016-07-24

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

-Original Message- From: sisyph...@optusnet.com.au Sent: Friday, July 15, 2016 10:31 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo > .deps/exceptions.Tpo -c -o exceptions.lo exceptions.c > Xexceptions.Tpo

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

-Original Message- From: Vincent Torri Sent: Friday, July 15, 2016 8:41 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo > isn't it in the texinfo package ? Indeed it is - thank you. Having installed texinfo, the bu

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

isn't it in the texinfo package ? Vincent Torri On Fri, Jul 15, 2016 at 11:31 AM, wrote: > Hi, > > Using dongsheng's gmp-6.1.1 (win32 threads, seh) build. > > I'm trying to build mpfr (svn revision 10613) in the msys2 shell and getting > hammered early on in the

[Mingw-w64-public] [MSYS2] How do I install makefinfo

Hi, Using dongsheng's gmp-6.1.1 (win32 threads, seh) build. I'm trying to build mpfr (svn revision 10613) in the msys2 shell and getting hammered early on in the 'make' stage with: ### make[1]: Entering directory 'C:/_64/comp/mpfr-10613/doc' restore=: &&

Re: [Mingw-w64-public] [Msys2-users] Where can I get an up-to-data patch list for building a native GCC on Windows?

Great job. Thanks a lot! -- Best regards, lh_mouse 2016-04-15 - 发件人：Alexpux <alex...@gmail.com> 发送日期：2016-04-15 01:33 收件人：lh_mouse 抄送：mingw-w64-public,Msys2 主题：Re: [Msys2-users] [Min

Re: [Mingw-w64-public] [Msys2-users] Where can I get an up-to-data patch list for building a native GCC on Windows?

ds, > lh_mouse > 2016-04-15 > > - > 发件人："lh_mouse"<lh_mo...@126.com> > 发送日期：2016-04-15 01:04 > 收件人：mingw-w64-public,Msys2 > 抄送： > 主题：[Mingw-w64-public] Where can I get an up-to-data patch list for > building a native GCC on

Re: [Mingw-w64-public] msys2

5 мая 2015 г., в 16:27, Baruch Burstein bmburst...@gmail.com написал(а): Is this list also the unofficial/official msys2 list, or is there a separate one for that? MSYS2 have separate mailing list: https://sourceforge.net/p/msys2/mailman/

[Mingw-w64-public] msys2

Is this list also the unofficial/official msys2 list, or is there a separate one for that? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- One dashboard for servers and applications across Physical-Virtual-Cloud

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

mingw-w64-public@lists.sourceforge.net Sent: Wednesday, December 10, 2014 12:09 AM Subject: Re: [Mingw-w64-public] MSYS2 is violating the GPL again 2014-12-08 19:32 GMT+01:00 Jim Michaels jmich...@yahoo.com: is this msys2 something that applies to mingw-w64? should I be using this instead

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

(computer repair info, programming) -- *From:* Alexpux alex...@gmail.com *To:* mingw-w64-public@lists.sourceforge.net *Sent:* Monday, December 8, 2014 3:01 AM *Subject:* Re: [Mingw-w64-public] MSYS2 is violating the GPL again 8 дек. 2014 г., в 13:48, Corinna

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On Dec 8 20:27, Alexpux wrote: 8 дек. 2014 г., в 17:50, Corinna Vinschen написал(а): On Dec 8 15:12, Alexpux wrote: 8 дек. 2014 г., в 14:27, Corinna Vinschen написал(а): On Dec 8 14:01, Alexpux wrote: Will update sf.net http://sf.net/ repo today. Ok. Done. And this is

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

8 дек. 2014 г., в 13:48, Corinna Vinschen vinsc...@redhat.com написал(а): Hi, I just had a look on the MSYS2 pages at sourceforge. It turned out that the Cygwin sources provided on sourceforge,

[Mingw-w64-public] MSYS2 is violating the GPL again

Hi, I just had a look on the MSYS2 pages at sourceforge. It turned out that the Cygwin sources provided on sourceforge, http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources/msys2-runtime-2.0.15816.7257e97-1.src.tar.gz/download are very old, from 2014-02-02, while the latest binary

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On Dec 8 14:01, Alexpux wrote: Will update sf.net http://sf.net/ repo today. Ok. And this is only for Cygwin. The situation of the other upstream packages isn't better. About half of the binary packages are younger than 6 month, while the latest source archives have been updated

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

8 дек. 2014 г., в 14:27, Corinna Vinschen vinsc...@redhat.com написал(а): On Dec 8 14:01, Alexpux wrote: Will update sf.net http://sf.net/ repo today. Ok. Done. And this is only for Cygwin. The situation of the other upstream packages isn't better. About half of the binary

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

Hi Corinna, With fear of my life I stick my head in a hornet's nest, with some remarks: Archlinux solved this issue some years ago, and the bug report is cause for an interesting read with some pointers on how to solve this for the MSYS2 folks: https://bugs.archlinux.org/task/5355 Any GPLv3

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On 12/8/2014 20:17, Ruben Van Boxem wrote: Hi Corinna, With fear of my life I stick my head in a hornet's nest, with some remarks: Archlinux solved this issue some years ago, and the bug report is cause for an interesting read with some pointers on how to solve this for the MSYS2 folks:

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On Dec 8 15:12, Alexpux wrote: 8 дек. 2014 г., в 14:27, Corinna Vinschen vinsc...@redhat.com написал(а): On Dec 8 14:01, Alexpux wrote: Will update sf.net http://sf.net/ repo today. Ok. Done. And this is only for Cygwin. The situation of the other upstream packages

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On Dec 8 13:17, Ruben Van Boxem wrote: Hi Corinna, With fear of my life I stick my head in a hornet's nest, with some remarks: Archlinux solved this issue some years ago, and the bug report is cause for an interesting read with some pointers on how to solve this for the MSYS2 folks:

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

8 дек. 2014 г., в 17:50, Corinna Vinschen vinsc...@redhat.com написал(а): On Dec 8 15:12, Alexpux wrote: 8 дек. 2014 г., в 14:27, Corinna Vinschen vinsc...@redhat.com написал(а): On Dec 8 14:01, Alexpux wrote: Will update sf.net http://sf.net/ repo today. Ok. Done. And this

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

:#x2F;#x2F;RenewalComputerServices.com http:#x2F;#x2F;JesusnJim.com (computer repair info, programming) From: Alexpux alex...@gmail.com To: mingw-w64-public@lists.sourceforge.net Sent: Monday, December 8, 2014 3:01 AM Subject: Re: [Mingw-w64-public] MSYS2 is violating the GPL again 8

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

On 12/9/2014 02:32, Jim Michaels wrote: is this msys2 something that applies to mingw-w64? should I be using this instead of https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/ No, that is MSYS copied from mingw.org,

Re: [Mingw-w64-public] MSYS2 issues

. Don't underestimate MSYS2, it's quite brilliant in its relative simplicity ;-) Cheers, Ruben -- *From:* Baruch Burstein bmburst...@gmail.com *To:* mingw-w64-public@lists.sourceforge.net *Sent:* Tuesday, July 22, 2014 5:31 AM *Subject:* [Mingw-w64-public

[Mingw-w64-public] MSYS2 issues

Hi, I (think I) found a bug in msys2. Here is a simple demo case: main.c: int main() { return 42; } Makefile: CC = gcc CC2 = $(shell which $(CC)) out_1: clean main.c $(CC) main.c -o /home/username/out.exe out_2: clean main.c $(CC) /home/username/main.c -o out.exe out_3: clean main.c $(CC)

Re: [Mingw-w64-public] MSYS2 issues

No, you didn't find any bug in MSYS2. If you want MSYS2 path translation to happen then use an MSYS2 program, i.e. MSYS2 make, not mingw32-make. -- Want fast and easy access to all the code in your enterprise? Index and

Re: [Mingw-w64-public] MSYS2 issues

On Tue, Jul 22, 2014 at 3:36 PM, Ray Donnelly mingw.andr...@gmail.com wrote: No, you didn't find any bug in MSYS2. If you want MSYS2 path translation to happen then use an MSYS2 program, i.e. MSYS2 make, not mingw32-make. Oh, OK, sorry. I thought that any program run from within msys got

Re: [Mingw-w64-public] MSYS2 issues

Yes, the shell that is run is the bash shell for MSYS2 make and cmd.exe for mingw32-make, and there are some other differences about the handling of 'special' characters. By default you should use MSYS2 make, unless you have a compelling reason not to.

[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

Re: [Mingw-w64-public] [MSYS2 request] add manifest file to patch archive

On Wed, May 14, 2014 at 4:07 PM, Jon jon.for...@gmail.com 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

[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

Re: [Mingw-w64-public] MSYS2 use of MSYSTEM

23 нояб. 2013 г., в 13:56, Jon jon.for...@gmail.com написал(а): 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?

Re: [Mingw-w64-public] MSYS2 use of MSYSTEM

On Sat, Nov 23, 2013 at 12:55 PM, Alexpux alex...@gmail.com wrote: 23 нояб. 2013 г., в 13:56, Jon jon.for...@gmail.com написал(а): 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

Re: [Mingw-w64-public] MSYS2

Hi! I want to ANNOUNCE that I create two pacman repositories for MinGW-w64 toolchains for MSYS2: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ This toolchains builded with threads=posix no-multilib - dwarf and

Re: [Mingw-w64-public] MSYS2

2013/11/20 Alexey Pavlov alex...@gmail.com Hi! I want to ANNOUNCE that I create two pacman repositories for MinGW-w64 toolchains for MSYS2: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ This toolchains

Re: [Mingw-w64-public] MSYS2

2013/11/20 Alexey Pavlov alex...@gmail.com Hi! I want to ANNOUNCE that I create two pacman repositories for MinGW-w64 toolchains for MSYS2: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ This toolchains

Re: [Mingw-w64-public] MSYS2

2013/11/20 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/11/20 Alexey Pavlov alex...@gmail.com Hi! I want to ANNOUNCE that I create two pacman repositories for MinGW-w64 toolchains for MSYS2: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/

Re: [Mingw-w64-public] MSYS2 *_shell.bat files updated with pacman -Syu?

2013/11/21 Jon jon.for...@gmail.com: If yes, anytime a pacman upgrade has newer bat files, I'd like to see the newer bat's installed as *_shell.bat.pacnew rather than overwriting the existing bat's. This is important to me because I have multiple msys(2)/mingw-w64 based toolchains on my

[Mingw-w64-public] [MSYS2] yaourt, cmake emacs

Many thanks to Alexey for bringing us msys2 with pacman. Hence i'm interesting in when can we expect a yaourt, a cmake and a emacs (better similar to the cygwin's, use msys's base subsystem and windows gui). -- Shape the

Re: [Mingw-w64-public] [MSYS2] yaourt, cmake emacs

2013/11/19 张皛闶 inter1...@gmail.com Many thanks to Alexey for bringing us msys2 with pacman. Hence i'm interesting in when can we expect a yaourt, a cmake and a emacs (better similar to the cygwin's, use msys's base subsystem and windows gui). Cygwin use X11 subsystem for GUI. I don't want to

[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

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

2013/11/18 Jon jon.for...@gmail.com 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

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

2013/11/18 Alexey Pavlov alex...@gmail.com 2013/11/18 Jon jon.for...@gmail.com 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 =

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: 2013/11/18 Alexey Pavlov alex...@gmail.com 2013/11/18 Jon jon.for...@gmail.com Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an awful idea? [mingw] #Server =

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

2013/11/19 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/11/18 Alexey Pavlov alex...@gmail.com 2013/11/18 Jon jon.for...@gmail.com Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an awful idea? [mingw] #Server =

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2013/11/18 Alexey Pavlov alex...@gmail.com 2013/11/18 Jon jon.for...@gmail.com Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an awful idea?

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov alex...@gmail.com wrote: 2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2013/11/18 Alexey Pavlov alex...@gmail.com 2013/11/18 Jon jon.for...@gmail.com Reasons why

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov alex...@gmail.com wrote: 2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2013/11/18 Alexey Pavlov alex...@gmail.com

Re: [Mingw-w64-public] MSYS2 32bit with pacman mingw 64bit repo?

On Mon, Nov 18, 2013 at 4:06 PM, Alexey Pavlov alex...@gmail.com wrote: 2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov alex...@gmail.com wrote: 2013/11/19 Jon jon.for...@gmail.com On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem

Re: [Mingw-w64-public] MSYS2 mpfr upgrade via pacman error

17 нояб. 2013 г., в 22:06, Jon jon.for...@gmail.com написал(а): $ pacman -Syu :: Synchronizing package databases... msys 75.5 KiB 337K/s 00:00 [] 100% :: Starting full system upgrade... resolving dependencies... looking for

Re: [Mingw-w64-public] MSYS2 mpfr upgrade via pacman error

or comment in /etc/pacman.conf mingw repository 17 нояб. 2013 г., в 22:15, Alexpux alex...@gmail.com написал(а): 17 нояб. 2013 г., в 22:13, Jon jon.for...@gmail.com написал(а): On Sun, Nov 17, 2013 at 1:06 PM, Jon jon.for...@gmail.com wrote: $ pacman -Syu :: Synchronizing package

Re: [Mingw-w64-public] MSYS2 mpfr upgrade via pacman error

17 нояб. 2013 г., в 22:13, Jon jon.for...@gmail.com написал(а): On Sun, Nov 17, 2013 at 1:06 PM, Jon jon.for...@gmail.com wrote: $ pacman -Syu :: Synchronizing package databases... msys 75.5 KiB 337K/s 00:00 [] 100% :: Starting

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

Re: [Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

2013/11/13 Corinna Vinschen vinsc...@redhat.com On Nov 12 22:52, Óscar Fuentes wrote: Corinna Vinschen vinsc...@redhat.com writes: On Nov 12 13:59, Óscar Fuentes wrote: $ du -sh /lib/git-core 13M /lib/git-core Windows Explorer says that d:/msys32/lib/git-core uses 169

Re: [Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

On Tue, Nov 12, 2013, Corinna Vinschen wrote: On Nov 12 22:52, Óscar Fuentes wrote: Corinna Vinschen vinsc...@redhat.com writes: On Nov 12 13:59, Óscar Fuentes wrote: $ du -sh /lib/git-core 13M /lib/git-core Windows Explorer says that d:/msys32/lib/git-core uses 169

[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

Re: [Mingw-w64-public] MSYS2 correct HOME setup

14 нояб. 2013 г., в 0:31, Jon jon.for...@gmail.com написал(а): 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

Re: [Mingw-w64-public] MSYS2 correct HOME setup

On Wed, Nov 13, 2013 at 3:36 PM, Alexpux alex...@gmail.com wrote: 14 нояб. 2013 г., в 0:31, Jon jon.for...@gmail.com написал(а): 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

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

Re: [Mingw-w64-public] MSYS2 correct HOME setup

On Wed, Nov 13, 2013 at 3:53 PM, Alexpux alex...@gmail.com wrote: 14 нояб. 2013 г., в 0:48, Jon jon.for...@gmail.com написал(а): On Wed, Nov 13, 2013 at 3:36 PM, Alexpux alex...@gmail.com wrote: 14 нояб. 2013 г., в 0:31, Jon jon.for...@gmail.com написал(а): I'm an old cygwin user who

Re: [Mingw-w64-public] MSYS2 correct HOME setup

14 нояб. 2013 г., в 0:56, Jon jon.for...@gmail.com написал(а): 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 ~

Re: [Mingw-w64-public] MSYS2 correct HOME setup

I unify my windows home with my MSYS2 homes using mklink /D so that e.g. C:\msys32\home\ray is a symlink to C:\Users\ray .. I haven't run into any problems with this recently. msysgit didn't used to like cloning to a folder within a symlink folder, but MSYS2 git is fine with it. Of course you'd

Re: [Mingw-w64-public] MSYS2

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. You can find general info about packman here: https://wiki.archlinux.org/index.php/pacman I create experimental base msys2

Re: [Mingw-w64-public] MSYS2

12 нояб. 2013 г., в 16:06, Zach Thibeau zachthib...@zachthibeau.ca написал(а): Initial testing, failed to retrieve msys. Db from sourceforge.net : error setting certificate verify locations Did you restart MSYS after first start? On Nov 12, 2013 6:58 AM, Alexey Pavlov alex...@gmail.com

Re: [Mingw-w64-public] MSYS2

Heh, sorry for the multiple replies, it is working just missed the xz package to be installed On Nov 12, 2013 7:08 AM, Alexpux alex...@gmail.com wrote: 12 нояб. 2013 г., в 16:06, Zach Thibeau zachthib...@zachthibeau.ca написал(а): Initial testing, failed to retrieve msys. Db from

Re: [Mingw-w64-public] MSYS2

I did indeed, but I found the issue so right now issue fixed, just a bad extract is all On Nov 12, 2013 7:08 AM, Alexpux alex...@gmail.com wrote: 12 нояб. 2013 г., в 16:06, Zach Thibeau zachthib...@zachthibeau.ca написал(а): Initial testing, failed to retrieve msys. Db from sourceforge.net :

Re: [Mingw-w64-public] MSYS2

2013/11/12 Zach Thibeau zachthib...@zachthibeau.ca I assume makepkg isn't fully functional yet? In general it working. I create all packages using it. PKGBUILD scripts located here: https://github.com/Alexpux/MSYS2-packages Some peaces of it need to be rewriting that use readelf but it is

Re: [Mingw-w64-public] MSYS2

I already installed it, so its nothing really. On Nov 12, 2013 7:24 AM, Alexpux alex...@gmail.com wrote: 12 нояб. 2013 г., в 16:18, Zach Thibeau zachthib...@zachthibeau.ca написал(а): Heh, sorry for the multiple replies, it is working just missed the xz package to be installed pacman -S

Re: [Mingw-w64-public] MSYS2

12 нояб. 2013 г., в 16:36, Óscar Fuentes o...@wanadoo.es написал(а): Hello Alexey, Alexey Pavlov alex...@gmail.com 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

[Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

$ du -sh /lib/git-core 13M /lib/git-core Windows Explorer says that d:/msys32/lib/git-core uses 169 MB. Obviously `du' is wrong because that directory contains lots of executables, using 1.5 MB each. -- November

Re: [Mingw-w64-public] MSYS2

2013/11/12 Alexey Pavlov alex...@gmail.com 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. You can find general info about packman here:

Re: [Mingw-w64-public] MSYS2

2013/11/12 Ruben Van Boxem vanboxem.ru...@gmail.com 2013/11/12 Alexey Pavlov alex...@gmail.com 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. You can find general info

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:

Re: [Mingw-w64-public] MSYS2

Well we can use something like sf.net for now until something serious happens and there is a greater need On Nov 12, 2013 12:37 PM, Ray Donnelly mingw.andr...@gmail.com wrote: I wonder if we need some Arch-linux-a-like infrastructure for this ace-ness? Of course paying for that would be a

Re: [Mingw-w64-public] MSYS2

2013/11/12 Zach Thibeau zachthib...@zachthibeau.ca Well we can use something like sf.net for now until something serious happens and there is a greater need On Nov 12, 2013 12:37 PM, Ray Donnelly mingw.andr...@gmail.com wrote: I wonder if we need some Arch-linux-a-like infrastructure for

[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

Re: [Mingw-w64-public] MSYS2 BASE package selection

2013/11/12 Jon jon.for...@gmail.com 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.

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.

  1   2   3   >