Re: [Msys2-users] Fix for wx-config / cmake cxxflags parsing issue

Ray Donnelly writes: > On Thu, Aug 14, 2014 at 6:45 PM, Wayne Stambaugh > wrote: >> On 8/14/2014 1:13 PM, Alexey Pavlov wrote: >>> >>> 14 авг. 2014 г., в 21:04, Richard Shaw написал(а): >>> I found the issue... No idea what it's not a problem on other platforms. diff -Naur

Re: [Msys2-users] Fix for wx-config / cmake cxxflags parsing issue

Richard Shaw writes: > Bug submitted: > > http://www.cmake.org/Bug/view.php?id=15087 Thank you Richard for the bug report and the patch. Alexey, can we wait a week or two for a response from the CMake wxWidgets module maintainer before incorporating the patch?

Re: [Msys2-users] Fix for wx-config / cmake cxxflags parsing issue

Richard, Richard Shaw writes: >> Alexey, can we wait a week or two for a response from the CMake >> wxWidgets module maintainer before incorporating the patch? > > > I've got it fixed locally for myself so I don't really care but why wait > that long? The patch is fairly straight forward. The on

Re: [Msys2-users] Fix for wx-config / cmake cxxflags parsing issue

Renato Silva writes: > 2014-08-14 22:48 GMT-03:00 Óscar Fuentes : > >> IMHO MSYS2 should limit itself to patches required by the specific needs >> of this environment (and perhaps some MinGW-w64 patches.) Broadening the >> scope is a recipe for maintainer burn-out.

Re: [Msys2-users] Problem upgrading even after running autorebase

Alexey Pavlov writes: > The best will be build static versions of programs but… for example, > msys ell can’t be build as static easily. How serious is this error? Can it cause packages on an inconsistent state after an upgrade? Or is it harmless? --

Re: [Msys2-users] Problem upgrading even after running autorebase

Alexpux writes: >>> The best will be build static versions of programs but… for example, >>> msys ell can’t be build as static easily. >> >> How serious is this error? Can it cause packages on an inconsistent >> state after an upgrade? Or is it harmless? > > When fork errors is happen all files

Re: [Msys2-users] Problem upgrading even after running autorebase

Ray Donnelly writes: > We have dash.exe in MSYS2 and it *only* links to msys-2.0.dll and to > nothing else. We should use that for our post-install runs since > msys-2.0.dll is never rebased anyway. Honest question: are post-install scripts supposed to be so simple that what dash alone offers is

Re: [Msys2-users] Problem upgrading even after running autorebase

Richard Shaw writes: [Sending to the ml now] > What about setting up a minimal chroot just for running pacman? > > Or is windows unable to have multiple copied of the "same" dll in > memory? You can have multiple running processes, each using either an "old" or a "new" dll. See http://msdn.mic

Re: [Msys2-users] Problem upgrading even after running autorebase

Alexpux writes: > 03 сент. 2014 г., в 18:04, Óscar Fuentes написал(а): > >> Ray Donnelly >> writes: >> >>> We have dash.exe in MSYS2 and it *only* links to msys-2.0.dll and to >>> nothing else. We should use that for our post-install runs sinc

Re: [Msys2-users] Problem upgrading even after running autorebase

Ray Donnelly A more radical suggestion is to *never* update anything in msys-base > or that the post-installs need via pacman and instead release an > updated installer that's non-destructive to the MSYS2 installation > when we need to update those components. This is radical only on the sense th

[Msys2-users] Clang has assertions on and can't locate system includes

Any reason why LLVM/Clang was built with assertions ON? (as confirmed bu `llvm-config --cxxflags' which lists -D_DEBUG) clang++ runs slower than g++ here while compiling a complex C++ project. A few months ago I built clang myself and it was quite faster than g++. Also, clang/clang++ doesn't know

Re: [Msys2-users] installing 32 bit toolchain

Stephen Leake writes: > I'm trying to build Emacs in msys2. > > I have built monotone, so I'm somewhat familiar with the general > process. > > However, I built monotone using the 64 bit toolchain. Emacs doesn't > support 64 bit (yet?), so I need a 32 bit toolchain. Emacs from bzr (or from the g

Re: [Msys2-users] Clang has assertions on and can't locate system includes

Alexpux writes: > 05 сент. 2014 г., в 20:32, Óscar Fuentes написал(а): > >> Any reason why LLVM/Clang was built with assertions ON? (as confirmed bu >> `llvm-config --cxxflags' which lists -D_DEBUG) >> > Today I uploaded new builds without assertions. Clang n

Re: [Msys2-users] Clang has assertions on and can't locate system includes

Alexey Pavlov writes: >> Now clang++ fails with Boost. Previously I was able to build this >> >> // File foo.cpp >> #include >> >> >> with this command: >> >> clang++ -c -DBOOST_USE_WINDOWS_H -Ic:/apps/msys32/mingw32/include foo.cpp >> >> But now fails with conflicting declarations. Because

Re: [Msys2-users] Possible MSYS2 regression.

Wayne Stambaugh writes: > I am having issues again with CMake path parsing. Using the CMake > file() command this does not work: > > file( READ /mingw64/include/wx-3.0/wx/version.h _var) > > but this does: > > file( READ c:/msys64/mingw64/include/wx-3.0/wx/version.h _var) > > I'm running CMake w

Re: [Msys2-users] Emacs

Hello Alexander, Alexander Shukaev writes: > Hey everyone, > > I've finished preparing Emacs as a package for MSYS2. It will come in 2 > variants: > >1. mingw-w64-emacs; >2. mingw-w64-emacs-git. > > The first one will fetch latest release tag, while the second one will > fetch HEAD. Ple

Re: [Msys2-users] Emacs

Óscar Fuentes writes: >> I've finished preparing Emacs as a package for MSYS2. It will come in 2 >> variants: >> >>1. mingw-w64-emacs; >>2. mingw-w64-emacs-git. >> >> The first one will fetch latest release tag, while the second one will &

[Msys2-users] Status of MinGW-Git package

Last night I tried the MinGW-Git package and it worked for the type of tasks one does on daily basis (log, add, commit, pull...) No problem was observed. What's missing for that package to become officially released? --

Re: [Msys2-users] Status of MinGW-Git package

Ray Donnelly writes: > On Wed, Oct 15, 2014 at 2:04 PM, Óscar Fuentes wrote: >> Last night I tried the MinGW-Git package and it worked for the type of >> tasks one does on daily basis (log, add, commit, pull...) No problem was >> observed. >> >> What

[Msys2-users] Name conventions for debug versions of libraries

I'm trying to fix a crash with a package that depends on Tcl/Tk dlls. After changing the PKGBUILDs for requiring debug builds of those dlls, their names contain suffixes to mark them as debug versions (libtcl86g.dll, etc.) This is quite inconvenient as the rest of the packages expect to link to lib

[Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

A package I'm preparing for submission creates a dll depending on libgcc_s_dw2-1.dll. When this dll is used and the host application exits, a crash happens. This is a known problem with libgcc_s_dw2-1.dll. The fix is to pass -static-libgcc to the link command. This is usually done with CC="gcc -s

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Renato Silva writes: > In my case I get libgcc_s_dw2-1.dll as dependency because I use LibSSP from > GCC 4.9.0 which is linked to it, see this bug report > . > > How exactly did you get this as dependency? I have no idea. Other cases were rel

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Alexey Pavlov writes: >> So what's the right method to force the build to use -static-libgcc when >> it links a dll? (LDFLAGS doesn't work) >> > In PKGBUILD before configure: > LDFLAGS+=« -static-libgcc» > doesn’t work? No. Apparently LDFLAGS is ignored when creating a dll: LDFLAGS+=" -stat

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Alexey Pavlov writes: So what's the right method to force the build to use -static-libgcc when it links a dll? (LDFLAGS doesn't work) >>> In PKGBUILD before configure: >>> LDFLAGS+=« -static-libgcc» >>> doesn’t work? >> >> No. Apparently LDFLAGS is ignored when creating a dll: >

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Ray Donnelly writes: > Top posting because I'm replying to all the stuff written in this thread: > > Óscar worried that doing: >CC="gcc -static-libgcc" configure ... > > .. would override users' versions of CC, well you can do tests with > bash to get around that: > > if [ -z "$CC" ]; then >

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Ray Donnelly writes: > Thanks, you also had changes to tcl/tk to allow the debug/!strip > options to behave, care to make a pull request for that? The build fails because one target that tries to link to the tcl library fails because it can not find it. So I'm reluctant to incorporate into MSYS2

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Renato Silva writes: > Is your application using libssp by any chance? No. The problem is about dlls that are loaded on demand and depend on libgcc_s_dw2-1. If the executable that loads libgcc does not depend on libgcc_s_dw2-1 itself, a crash happens when the application terminates. This is what

Re: [Msys2-users] How to avoid depending on libgcc_s_dw2-1.dll

Ray Donnelly writes: [snip] > I am also wondering if we > shouldn't be renaming the tcl and tk dlls like we do (ditching the > version number and the g if it existed). tcl/tk change infrequently > enough that I think the packaging overhead of going with what upstream > does isn't much, and they

[Msys2-users] When are packages published?

Since a PKBUILD is merged into MINGW-packages, how much time passes until it is available as a binary package? I ask because several days ago contributed some packages. Since, the package database was updated with new contents, but those packages are not listed yet. -

Re: [Msys2-users] When are packages published?

Alexey Pavlov writes: > Usually I create binary packages during evening if no problems. > > But with your tcl/tk packages I think we have some problems. In other > case they will be in repo when I fix all issues. Building tktable I > see that created DLL is on /mingw*/lib/tktable*/ directory. Is

Re: [Msys2-users] Fwd: How to avoid depending on libgcc_s_dw2-1.dll

Ray Donnelly writes: > No, you are entirely incorrect and spreading misinformation I'm > afraid. For MinGW-w64 to operate correctly, the only type of PECOFF > that should ever be linked with -static-libgcc is an entirely static > executable. It's got nothing to do with philosophy or preference, i

Re: [Msys2-users] Fwd: How to avoid depending on libgcc_s_dw2-1.dll

Ray Donnelly writes: >> Apart from that, libgcc*.dll comes with some hefty licensing issues. >> > > It makes no difference if you link statically or dynamically to > libgcc, from https://www.gnu.org/licenses/gcc-exception-faq.html > > .. While combining libgcc with GCC-compiled object code is pro

Re: [Msys2-users] Uninstalling MSYS2

Alexey Pavlov writes: >> 5 нояб. 2014 г., в 20:55, Dangthrimble >> написал(а): >> >> I've reinstalled again to try and understand the correct installation >> procedure. When the shell opened I ran pacman -S bash pacman >> msys2-runtime, >> > First you need get latest package database after in

Re: [Msys2-users] Uninstalling MSYS2

Alexey Pavlov writes: >> No autorebase.bat needed? > > autorebase.bat need only for 32-bit MSYS2 Someone who reads the mailing list archives looking for a fix to the same problem doesn't necessarily run the same architecture as the OP. So it is worth mentioning "if you run the 32 bits version yo

[Msys2-users] Strange problem with the Emacs build

Building Emacs master with the mingw-w64-i686 toolset on Windows 8.1 64 bits with MSYS2 64 bits fails because it produces an invalid temacs.exe executable: $ src/temacs.exe bash: src/temacs.exe: cannot execute binary file: Exec format error On the same machine, building with the mingw-w64-x86_64

Re: [Msys2-users] Strange problem with the Emacs build

David Macek writes: > On 17. 11. 2014 19:35, Óscar Fuentes wrote: >> Building Emacs master > > What exactly do you mean by emacs master? It is the `master' branch of Emacs git repo: git://git.savannah.gnu.org/emacs.git > I can try building on W8x64 and W8.1x64 for you.

Re: [Msys2-users] Strange problem with the Emacs build

David Macek writes: >> image.o:image.c:(.data+0xc0): undefined reference to >> `init_imagemagick_functions' > > I assume this build error is addressed in one of MSYS2 patches, see > the build directory > . The build sho

Re: [Msys2-users] Strange problem with the Emacs build

David Macek writes: [snip] Thank you very much. I'll forward this information to the Emacs-dev mailing list. Now, it's strange that the build worked for Alexey. Thanks again. -- Download BIRT iHub F-Type - The Free E

Re: [Msys2-users] Strange problem with the Emacs build

David Macek writes: > On 19. 11. 2014 21:13, Óscar Fuentes wrote: >> Now, it's strange that the build worked for Alexey. > > I assume he used the PKGBUILD. Of course. As soon as I read the part about the wrong image-base I said "that'

Re: [Msys2-users] Moving msys2 folder

Ray Donnelly writes: > A multi-user setup? Sounds great! Why not setup your own curated > msys2/mingw{32,64} repositories on a local file server, then point > your users' MSYS2 installs at them instead of ours (in > /etc/pacman.conf) so that they can use MSYS2's pacman as normal? That > way you c

Re: [Msys2-users] Fwd: CMAKE execute_process doesn't preserve environment variables.

Wayne Stambaugh writes: > I have the same issue building KiCad. CMake does not appear to know how > to properly define the default search path for MinGW. It probably sees > MSYS defined and sets the default search path to /usr which is not what > you want unless you are actually building an msy

Re: [Msys2-users] Strange problem with the Emacs build

David Macek writes: [snip] > compatibility. The problem is that even on i686, the $canonical > triplet is "x86_64-pc-mingw32". I have not tried to find out why the > triplet is wrong. The PKGBUILD doesn't have this problem because it > always passes correct "--build=${MINGW_CHOST}" to configure.

Re: [Msys2-users] Starting an application on Windows

Bill Lee writes: > Perhaps this isn't the correct place to ask, but since my application is > developed under msys2, I will ask here to start. > > I am developing an application that uses ncurses for screen management. > The intent is to ultimately have a program that a Windows user can click

Re: [Msys2-users] Unrecognized archive format.

Wayne Stambaugh writes: [snip] > There are some very suspicious looking db files being downloaded. This happened to me some days ago. At the end, after applying the recipes mentioned in this thread several times, I waited some hours, repeated the fixes and it worked. -

Re: [Msys2-users] Need cmake in /usr/bin

Mirko Vukovic writes: > I opened msys2 console and did > pacman -S mingw64/mingw-w64-x86_64-cmakeq > > I thought that msys2 console is for package installation, and mingw64 gives > a > build environment for 64-bit applications. AFAIK cmake does not depend on the GCC toolchain, so you need to ins

Re: [Msys2-users] Need cmake in /usr/bin

Óscar Fuentes writes: > Mirko Vukovic > writes: > >> I opened msys2 console and did >> pacman -S mingw64/mingw-w64-x86_64-cmakeq >> >> I thought that msys2 console is for package installation, and mingw64 gives >> a >> build environment for 64-bit

Re: [Msys2-users] editrights?

Erik de Castro Lopo writes: > According to > > > http://sourceforge.net/p/msys2/activity/?page=0&limit=100#553cce89e88f3d41f6cb04e2 > > the editrights program was recently added to msys2, but > > pacman -Sy editrights > > can't find it. Clues? The mere presence of a PKGBUILD on the git

Re: [Msys2-users] can't build GNU Mdk

Ignacio Caamaño writes: > Trying to build GNU Mdk, gime me this error: > > --- > mix.c: In function 'mix_stat_dir': > mix.c:79:30: error: too many arguments to function 'mkdir' >

Re: [Msys2-users] python interpreter/ console window problems

Matthieu Vachon writes: [great explanation of the mintty/windows-native impedance problem] > Another things you can do (which I do some times to times), is to use > another terminal than `mintty` that has "native windows" features. ConEmu > should be one of them. You can also use the standard Wi

Re: [Msys2-users] gcc 5.2.0 issues?

Adrian Pop writes: > After I upgraded to gcc 5.2.0 I get some weird linking errors. > > Is it possible that the gcc 5.2.0 generates code that is > not linker compatible with libraries built with gcc 4.9.2? I experienced similar problems after building a project with 5.2 with object files generat

Re: [Msys2-users] What package does obstack.h live in ?

Aaron Gray writes: > I cannot seem to find which package obstack.h is in. pacman -Qo /path/to/file tells you the package that installed `file'. -- ___ Msys2-users mailing li

Re: [Msys2-users] Need help with a simple linking error.

Greg Jung writes: > My apologies to be posting such a basic problem here, I'm getting undefined > references: This type of errors are usually caused by wrong order of listed libraries on the command line. If library A contains references to library B, you need to list -lA before -lB on the comma

Re: [Msys2-users] "Bad address" error with -rpath option in gcc

Greg Jung writes: [snip] > Note in passing: Until I went to cmake 3.3.2, the normal RPATHCMD had a > second directory (a system library) tacked into it and also > gave problems. > > Obviously if I can manipulate cmake to provide /D instead of D: as the > answer that would solve my > issue, but i

Re: [Msys2-users] Pinning to Taskbar

"J.B. Langston" writes: [snip] You may be interested on the discussion of this PR for mintty: https://github.com/mintty/mintty/pull/471 -- ___ Msys2-users mailing list Msys2

Re: [Msys2-users] Missing libxml that's not missing?

Ray Donnelly writes: > This has nothing to do with LIB. It's the DLL loader on Windows, not build > time stuff. > > Use process hacker 2. Search for DLL handles straight after boot up. See > which processes loaded the zlib DLL. Find alternatives to that software, > maybe MSYS2 has some? Uninstall

Re: [Msys2-users] Missing libxml that's not missing?

Matt Breedlove writes: > DLLs load from the system32/wow64 directory first *regardless* of any > PATH variables. This was a prior problem I experienced with python > being built and there having been openssl dlls within my system > directories. It has nothing to do with the path variable. This

Re: [Msys2-users] Missing libxml that's not missing?

Ray Donnelly writes: > From MSDN: > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx > > "If a DLL with the same module name is already loaded in memory, the > system checks only for redirection and a manifest before resolving to > the loaded DLL, no matter which

Re: [Msys2-users] Missing libxml that's not missing?

Óscar Fuentes writes: > OTOH I'm 100% sure that placing a dll on the same directory where the > binaries that depend on it are installed protects your application from > the presence of identically named dlls on the system. This is documented > again and again, including the

Re: [Msys2-users] Missing libxml that's not missing?

Matt Breedlove writes: > It would be nice if they had something like SetDllDirectory or > AddDllDirectory to override this behavior for child processes to > prevent these name collisions or we at least a better way of reporting > when they occur rather than failing with some mysterious error. If

Re: [Msys2-users] GDB big problem

Fabrice Popineau writes: > gdb src/emacs.exe > break > run -Q > gdb breaks into the function > > and I cannot type anything in gdb anymore. > Commands take forever to be displayed / executed. > I have tried to run gdb from an MSYS2 mintty, > a MinGW64 mintty and a cmd terminal without > any bett

Re: [Msys2-users] System calls supported

Computer Jock writes: > Is there a list of the system calls supported by Msys2? Since MSYS2 is a Cygwin fork, you can use its documentation. Try here: https://www.cygwin.com/faq.html#faq.programming -- Attend Shape: A

Re: [Msys2-users] Announcement: msys2-runtime 2.5.1 -- last version to support XP/2003

David Macek writes: > Hello MSYS2 users. > > Following an announcement from Cygwin[1], the MSYS2 runtime will be > dropping support for Windows XP and Windows Server 2003 starting with > the next release. > > We advise anyone still needing to use Windows XP/2003 to stay on the > current release (

Re: [Msys2-users] Announcement: msys2-runtime 2.5.1 -- last version to support XP/2003

That seems to do the trick. Thank you. David Macek writes: > On 8. 9. 2016 20:06, Óscar Fuentes wrote: >> Is there a method for ignoring all updates to the msys2 collection, i.e. >> allow updates to mingw-w64-* but not for the msys2 packages? When >> `pacman -Su' o

[Msys2-users] Integrating info files into the `dir' index

There is a long-standing problem with the Emacs package: entries for its info files are not incorporated into the `dir' file in /mingw[32-64]/share/info, so they are not accesible from the index. See https://github.com/Alexpux/MINGW-packages/issues/631 I wonder what is special about Emacs? The in

Re: [Msys2-users] Fwd: emacs problems missing file msys-gobject-2.0-0.dll

Yongchao Ge writes: > Thanks for finding out that I'm missing glib2. In fact, I'm missing a lot > of dependent packages. > > Previously, I was just the following simple command to install emacs > > $pacman -S emacs > > which does not check the dependent packages. It does, but the list of depende

Re: [Msys2-users] emacs problems missing file msys-gobject-2.0-0.dll

Yongchao Ge writes: > $ pacman -Ss emacs > mingw32/mingw-w64-i686-emacs 25.1-1 > The extensible, customizable, self-documenting, real-time display editor > (mingw-w64) > mingw64/mingw-w64-x86_64-emacs 25.1-1 > The extensible, customizable, self-documenting, real-time display editor >

Re: [Msys2-users] Help with DLL dependencies

"Matthew A. Postiff" writes: > I'm stuck trying to figure out a crash that I think is related to a > missing DLL. One clue is that my application worked fine, but then some > upgrades in msys/mingw32 did something underneath my app that is > activating the crash. If the application, freshly comp

Re: [Msys2-users] Building a distributable DLL for msys2?

"Ian Puleston" writes: > After having fixed a bug in GTK 3's GtkComboBox, I now want to build a > patched version of libgtk-3-0.dll to use. But makepkg has generated a > makefile that builds the debug version which is over 31Mbytes where the > original distributable version in msys2 is 7.3Mbytes,

Re: [Msys2-users] tar + gzip problem

"Matthew A. Postiff" writes: > I have a Windows gtk program that I build in an msys2 environment, and > the program itself uses some msys2 utilities. I copy the ones I need > into the C:\program files\myprogram\bin with the idea that I don't have > to install all of msys2 to run the program. I

Re: [Msys2-users] AAARRGGGHHHH I've misplaced my headers........

Andrew Lowe writes: [snip] > Well I did and my headers are missing, which means the std lib as well. > I must have brain faded and not installed something. I've got clang > installed and I haven't installed gcc. Is there an easy way of getting > the standard headers and libs for clang t

Re: [Msys2-users] AAARRGGGHHHH I've misplaced my headers........

Andrew Lowe writes: [snip] > With respect to using clang, the reason I use it is that it's stable, > but more importantly the error reporting is vastly superior to gcc which > helps with teaching. It tells the students where the actual error is, > not like gcc which wildly flails around

Re: [Msys2-users] Problem using gcc in MSYS2 shell

Edward Diener writes: > When trying to compile a project in MSYS2 using mingw-64/gcc I get this > error: > > "Building shared library... > x86_64-w64-mingw32-gcc -x c-header -DHAVE_CONFIG_H -Wall -Wextra > -pedantic -pedantic-errors -Werror -Wwrite-strings -Wconversion > -Wsign-conversion -Wsu

Re: [Msys2-users] Problem using gcc in MSYS2 shell

Edward Diener writes: > This is my first time using MSYS2 and, as I understand it, I am running > a Linux-like shell. Within MSYS2 I use a shell command file which > invokes the traditional "configure/make/make install" sequence using the > mingw-64/gcc implementation installed from within MSY

Re: [Msys2-users] Problem using gcc in MSYS2 shell

Edward Diener writes: >> Please show the exact steps for replicating the problem, including the >> method you use to start the MSYS2 shell. > > I start the shell by double-clicking the program item "MSYS2 MinGW 64-bit". Good. > The library I am trying to build is mfcgthread from > https://gith

Re: [Msys2-users] Problem using gcc in MSYS2 shell

David Grayson writes: > No, the MSYS2 MinGW make packages do not supply a "make.exe". That would > cause lots of compatibility problems and break a lot of packages because of > the bugs and quirks in MinGW make. > > $ pacman -Ql mingw-w64-i686-make > mingw-w64-i686-make /mingw32/ > mingw-w64-i68

Re: [Msys2-users] cilkplus in gcc mingw64

Luis Sánchez Sandoval writes: > It is known that gcc cygwin supports cilkplus for parallel programming > since versión 5.0. > > I did not find the headers for cilkplus in mingw64 but I did find a > library called MSYS-CILKRTS-5.dll in usr/bin directory > > To build an exe for a parallel program u

Re: [Msys2-users] recompiling msys2 packages

Don Raikes writes: > If I wanted to recompile a msys2 package (gdb) with special > configurations, where do I get the source code? > > I am interested in compiling gdb with python support. Looking at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gdb/PKGBUILD and https://git

Re: [Msys2-users] How to install freetds

"Igal @ Lucee.org" writes: > I see that freetds was added to MSYS2 -- > https://github.com/Alexpux/MINGW-packages/pull/2671/files -- but when > I try to run > >   pacman -S freetds > > I get an error target not found: freetds > > How can I install it? Try pacman -Ss freetds to list the packag

Re: [Msys2-users] New to this, looking for pacman advice

Jeremy Nicoll writes: > On Wed, 25 Oct 2017, at 23:45, David Grayson wrote: >> A conflict is an unusual event that is different from a routine >> upgrade to a new version of a package. > > OK (and thank-you for replying)... > >> It looks like you deleted the most important parts of the pacman >

Re: [Msys2-users] "strange" error 0xC000007B for HelloWorld.cpp

Georg Ströhlein writes: > I have successfully (??) set up MSYS2 x64 together with gcc x64 and > geany x64 on a Win7x64 PC. > > The exe files created from the source HelloWorld.cpp: > > #include > > > using namespace std; > > > int main() > > { > cout << "Hello World.\n"; > return 0; > > } > >

Re: [Msys2-users] About DLLs needed by Emacs (W64)

Fabrice Popineau writes: >>> Just out of curiosity, given the Emacs executable, is there a way to know >>> the MSYS2/MinGW64 DLLs it needs? On MSYS2 I tried: >>> >>> ldd Emacs/bin/emacs-27.0.50.exe >>> but it prints only Windows DLLs not all the others which come from >>> MSYS2/MinGW64... >>> >>

Re: [Msys2-users] Emacs 25.2 does not see its Info files

Mirko Vukovic writes: > Am I the only one with this problem (i.e, I have some kind of bug in my > setup) or is this how things are with Msys2's Emacs? This is a long-standing (and annoying) issue. See https://github.com/Alexpux/MINGW-packages/issues/631 ---

Re: [Msys2-users] link error with llvm 5.0

Dominique Fober writes: > I’m compiling a program using gcc 6 and I try to link with llvm 5.0 libraries. > Below is the detail of the installed packages. > gcc 6.4.0-1 > gcc-libs 6.4.0-1 > mingw-w64-x86_64-llvm 5.0.0-3 Any reason for using gcc/gcc-libs version 6.4? The binaries on the LLVM packa

Re: [Msys2-users] Please build a binary package of w3m on i686 arch platform.

Easior Lars writes: > Dear all in the list, > > I found that w3m for i686 is missing: > ,--- > | $ pacman -Ss w3m > | msys/w3m 0.5.3-2 (net-utils) > | w3m is a pager with WWW capability (net-utils) > `

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

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 on Linux. > > When using mingw it results of ty

Re: [Msys2-users] MSYS2: system call and shel variables

Vincent Torri writes: > I would like to know, programmatically, if the the directory created > when a tarball is decompressed exists or not. The tarball is in this > directory: > > D:/Documents/msys2/opt/ewpi_test/share/ewpi/packages/foobar > > So I want to execute with system() : > > cd D:/Docum

Re: [Msys2-users] MSYS2: system call and shel variables

Vincent Torri writes: > On Thu, Jan 10, 2019 at 11:43 PM Óscar Fuentes wrote: >> >> >> Are you using the MSYS2 toolchain or the Mingw-W64 toolchain? because >> `system' on the later uses the Windows shell (CMD.EXE or whatever). > > > $ gcc -v > Usin

Re: [Msys2-users] Mirrors

Gavin M2301 writes: > Hi all- > Anyone know where the mirrors are at? > Thnx. Roboloki In a MSYS2 shell: cd /etc/pacman.d ls You will see several mirrorlist.* files. ___ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sour

Re: [Msys2-users] 2 shells

Gavin M2301 writes: > Hi all - > I have msys2 msys for a shell and then msys2 mingw 64 bit? Do I just use > msys2 msys for pacman and the other shell for say compiling or linking? Is > there a cool FAQ? I already am reading about pacman. Thnx. Roboloki Try this on each shell: echo $PATH See th

Re: [Msys2-users] strange behavior in msys2 shell

Gavin M2301 writes: > I am using conemu console now. > > Postgresql works with that. For some reason my minty terminal did not. > > No worries. This is a known problem with mintty when running non-msys2 console applications. On the past there was a hack names winpty (IIRC) but it was removed.

Re: [Msys2-users] Newbie: What is the default text editor for MSYS2?

Jose Isaias Cabrera writes: > I am trying to add some proxies to my .bashrc file, and there is no > vi, vim, ed, ne editor to edit the file. The installer should at least > provide vi as a default. Thoughts? Thanks. If vim is not installed just execute pacman -S vim _

Re: [Msys2-users] Cairo update leads to breakage

sisyphus writes: > In msys2, I've just updated 32-bit Cairo (mingw32/mingw-w64-i686-cairo) to > version 1.16.0-1 but, after re-building the program, I'm getting a pop-up > with the following runtime error: > > "The procedure entry point __divmoddi4 could not be located in the dynamic > link libra

Re: [Msys2-users] Cairo update leads to breakage

sisyphus writes: > Thanks Oscar. > The attempted full update ended with: > > .. > util-linux-2.33.1-1... 1383.3 KiB 125K/s 00:11 [#] > 100% > (135/135) checking keys in keyring [#] > 100% > (135/135) checking package integrity

Re: [Msys2-users] Cairo update leads to breakage

sisyphus writes: > I removed the offending files, but the error still persists. (See attached > msys2_upgrade.txt) > I made sure that I opened a new shell following the removal of the files, > but it seems there's some cached information that these files are still > present. How can pacman compl

Re: [Msys2-users] mingw-w64-i686-crt-git: /mingw32/i686-w64-mingw32/ exists in filesystem

Valerio Messina via Msys2-users writes: > Any suggestion to recover the system? Unfortunately this problem happened to many users lately. If the files pacman complains about were small, simply deleting it and re-executing pacman would be enough, but as you seem to have many problematic files, in

Re: [Msys2-users] makepkg-mingw hangs at prepare()

"Weber, Holger" writes: > I did the same in msys2_shell.cmd but with the same effect. > Any other things I can do? PKGBUILD is, essentially, a shell script. Search for the function prepare() and insert "echos" before each command to trace the execution and locate the point that hangs. ___

Re: [Msys2-users] gendef Qt5WebEngine.dll

Toke Nielsen writes: > I suspect that I am getting this error because Qt5WebEngine.dll > depends on other QT dlls. I would like these dlls to be the dlls from > the MSYS QT instead of Windows QT. > > Do any of you know whether what I am trying to do is possible and have > any ideas about how to p

Re: [Msys2-users] updating qtwebkit

Toke Nielsen writes: > I just updated my MSYS2 environment, so I can use gcc 9.2 and qt 5.13.2. > > My application is using qtwebkit which was also upgraded, but > Qt5WebKit.dll apparently depends on some older dlls. Maybe this is relevant: https://github.com/msys2/MINGW-packages/issues/6020

Re: [Msys2-users] imagemagic does not work

Il'dar Al'Miev writes: > i installed Msys2, and ImageMagick (using, pacman -Ss imagemagick > etc.). however, when i type, for example, "magick", or "display > file1.jpg" in the command line of Msys2, then it says: "-bash: magick: > command is not found" etc. > > i would appreciate, if anybody exp

Re: [Msys2-users] VisualStudio MFC project

Valerio Messina via Msys2-users writes: > hi, > is there a simple method to write the Makefile for a VisualStudio MFC > project, to let me generate the binary from Linux or from MSYS2? > > The simple application is build of about 5 cpp files. Maybe this is relevant to you: https://social.msdn.m

  1   2   >