owlnext might be an alternative to MFC, its based on borlands old OWL
and at some point they did have a mingw port though i seem to remember
the makefiles for it needed some updating. Seems someone is allready
looking into updating the makefiles so it might soon build with a mingw
based gcc
Sorry i think its pacman -S mingw-w64-i686-tools-git and
mingw-w64-x86_64-tools-git instead.
Forgot that Msys2 uses the latest avaliable api.
Den 12-12-2019 kl. 10:53 skrev Liu Hao:
在 2019/12/12 14:26, Il'dar Al'Miev 写道:
Dear All,
hello,
i installed Msys2 in my computer. now i need to use
pacman -S mingw-w64-i686-tools mingw-w64-x86_64-tools should give you
gendef.
Den 12-12-2019 kl. 10:53 skrev Liu Hao:
在 2019/12/12 14:26, Il'dar Al'Miev 写道:
Dear All,
hello,
i installed Msys2 in my computer. now i need to use "gendef"-command in my task. however,
the bash-environment
This is the Msys2 user list so you are allready here :-)
Alexy might be able to help, its still early here in europe so give it a
few hours.
Den 08-12-2019 kl. 07:10 skrev Amit Choudhary:
> Hi,
>
> I have downloaded mingw-w64 and MSYS2. I downloaded bash-5.0.tar.gz. I
> untarred and unzipped it
You might not have much luck building bash as a standalone executable
for windows since it relies on some posix functionality that windows
does not have, hence Msys2 Cygwin posix libraries are needed and
unfortunatly those only come as a dll. There was an old project called
downhill which emulated
Yup, i had the same problem. Had to add -Wl,--allow-multiple-definition
to linker flags to get around it, but i noticed afterwards that the flag
propagates down to everything i link to it, so not the best solution.
Den 26-06-2017 kl. 11:49 skrev Jan Niklas Hasse:
Hi,
after doing `pacman
Also problems with other packages after last update, perl modules locale
and ssleay no longer work because the dll name changed( old one was
versioned 3_22 new one uses 3_24), and these modules cannot be rebuilt
because perl seems to have problems locating its own library (loads of
undefined
Small patch for flexlink incomming, patches flexlink to run strip on all
binaries which in turn fixes building lablgtk.
Also pulls in some posix functionality.
diff -urN flexdll.old/Makefile flexdll/Makefile
--- flexdll.old/Makefile2015-01-22 14:01:06.0 +0100
+++
You might run into a problem using only the static libwinpthread on some
packages, i speak from experience since
im using a method similar to the suggested one. The problem is that some
shared libraries linked to the static libwinpthread.a library will throw
a multiple definition error if the
c11 by default and `restrict` is a key word there.
> Such behavior can be disabled by requesting `-std=gnu89` explicitly.
>
> --
> Best regards,
> lh_mouse
> 2016-10-29
>
> -----
around the bug by renaming restrict to something else ->
restrictAction.
Den 28-10-2016 kl. 22:46 skrev David Grayson:
What about using __restrict instead?
--David
On Fri, Oct 28, 2016 at 7:46 AM, ralph engels <ralpheng...@gmail.com
<mailto:ralpheng...@gmail.com>> wrote:
Not sure whats changed ? but after updating to gcc6 the restrict keyword
can no longer be used and throws an error.
Supplying -std=c99 to flags does not fix it either.
--
The Command Line: Reinvented for Modern
After a recuring error with the newest python2 package, i incorporated a
small fix.
The patch is attached to the message and replaces the patch with the
same name.
diff -urN Python-2.7.12.old/Lib/distutils/cygwinccompiler.py
Python-2.7.12/Lib/distutils/cygwinccompiler.py
---
:50, ralph engels wrote:
>> libcxx is still not building, and i fear my C++ fu is not strong enough
>> to fix the problems, but maybe someone there can help with that part.
> I would love to help out ;) W
not
initialized and bails out.
Also libcxx needs some work to build.
Den 10-10-2016 kl. 13:06 skrev Ray Donnelly:
> Will you make a Pull Request for this work Ralph?
>
> On Sun, Oct 9, 2016 at 10:32 PM, ralph engels <ralpheng...@gmail.com> wrote:
>> Yup that fixed it, thanks :).
>&g
a nogo though.
Den 09-10-2016 kl. 11:12 skrev Alexey Pavlov:
2016-10-08 20:20 GMT+03:00 ralph engels <ralpheng...@gmail.com
<mailto:ralpheng...@gmail.com>>:
After upgrading to gcc-6.2.0 i can no longer build boost it seems, im
still looking at the log because its rather large,
After upgrading to gcc-6.2.0 i can no longer build boost it seems, im
still looking at the log because its rather large, but it does not seem
to contain any usefull messages. Anyone else ran into this problem ? i
guess its related to gcc now defaulting to -std=c++14.
You probably have the TMP dir on your ssd, object files from compiling
will usually end up there so its not uncommon.
If you dont want continous writes to your ssd i suggest moving the TMP
dir to a mechanic harddisk. You can do that
by changing the TEMP and TMP variables to point to another
Aye i also have been getting that problem, i got around it by hand
setting paths in my build script so that the mingw32 directories came
first before the windows system directories. In most cases this works
but i have seen a few edge cases that prove that it is not allways
enough. In those
19 matches
Mail list logo
