You should try "makepkg -g" and paste/copy the results, for the lines that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
On Fri, Nov 23, 2018 at 10:51 AM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
> On 11/23/2018 9:06 AM, Liu Hao wrote:
> > 在 2018/11
The recipe from Liu Hao is correct for what it describes and now the
nomenclature
needs to be discussed so that you can explain what you need. You have
called something
"mingw-64" which is none of the options.
The MINGW group that MSYS2 uses employs the preamble, "mingw-w64" for the
native softwar
Hi all,
I am trying to read a link target. Its already established with a handle
and
deemed to be a link, and so the next step is to call
GetFinalPathNameByHandleW
In Window 7 using gcc 5.3:
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x0601
#include
...
#if _WIN32_WINNT >= 0x0600
Pre-built gcc versions are to be found here:
https://sourceforge.net/projects/mingw-w64/files/mingw-w64/
On Mon, Aug 20, 2018 at 5:31 AM Aditya . wrote:
> Hello,
>
> Hope you are doing well.
>
> Myself Aditya working on usb HCI drivers on windows 64bit machine.
>
> We use some of the APIs provid
On Thu, Mar 24, 2016 at 3:03 AM, Mario Emmenlauer
wrote:
>
> Hi Ruben,
>
> thanks for this very very good pointer!! I did not dare look behind
> the scenes of the MinnGW packages, but it turns out that was my
> mistake, they are indeed readable, and helpful! :-)
>
> One more question, if I may: i
You shouldn't have t make any part of the toolchain, they are there to be
installed from cygwin setup. The names go like "mingw64-x86_64-gcc-g++"
etc. (no mingw32 mentioned).
For usage instructions, there should be something on cygwin.org. It might
be as simple
as inserting /usr/x86_64-w64-ming
In my programming instead of "multibytetowide" conversion preparing for a
windows API inside #ifdef UNICODE blocks, I just call the ANSI mode of the
function with ascii c-strings
passed in, and let microsoft perform the A->W conversions. When does this
simpler approach break?
- Only use Win3
So I repeat the query, up the chain,
-- Forwarded message --
From: Alexey Pavlov
Date: Fri, Apr 3, 2015 at 12:20 AM
Subject: Re: [Msys2-users] Where has the time gone?
To: Greg Jung
Cc: "msys2-us...@lists.sourceforge.net"
> 3 апр. 2015 г., в 10:12, Greg Ju
My 2c, which is not authoritative but perhaps can throw a few more
topics into the mix.
First remember this: there are compiler-specific versions of
libstdc++, incompatible but nevertheless named the same, dependent
upon the exception method deployed by the compiler.
AFAIK the only way to force a
I'm only recently felt that I know enough to propose the following as
an opening statement, which I hope is politik:
" Mingw-w64 is an advancement of the original Mingw system (mingw.org)
created to support the GCC compiler on windows-based systems.
Programs compiled with Mingw rely on the mingw r
ul thanks for the help.
On Thu, Jan 15, 2015 at 12:23 AM, David Macek
wrote:
> On 15. 1. 2015 4:11, Greg Jung wrote:
> > Yes I've seen that, if my second post appeared, the symlinks created
> with cygwin are the ones giving me trouble. These links are invisible to
> C
n't find a
> FILE_ATTRIBUTE_REPARSE_POINT in its mask.
>
> Nevertheless, cygwin and msys2 "ls -la" commands show a symlink. They
> work like a symlink should.
> So the question becomes, "why do cygwin symlinks look different, and how
> can a user prog
sage to correct the lstat call )
On Wed, Jan 14, 2015 at 9:33 AM, Greg Jung wrote:
> Hi Folks,
> I've been trying to program a recognition of NTFS symbolic link files;
> What I;ve gleaned
> from MSDN procedures don't seem to work. Below are coded three methods
>
>
Hi Folks,
I've been trying to program a recognition of NTFS symbolic link files;
What I;ve gleaned
from MSDN procedures don't seem to work. Below are coded three methods
1) (untested) open file and call GetFileInformationByHandleEx. I can't get
winbase.h header definitions recognized
2) GetF
Hi John,
If you would indulge my questions, I am intrigued by the advice re:
"-fno-keep-inline-dllexport"
flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace? Also regarding
I've just started an MSYS2 installation, (msys64) and have taken the
pre-built tree from the win-builds project, which includes an
x86_64-w64-mingw32 compiler built with posix thread model, seh exceptions.
it is gcc version 4.8.2.
Missing in the compiler-specific directory is the omp.h header
aded msys2 now, though, and anticipate using it for 64-bit builds
once I'm more comfortable with it.
On Sat, Nov 1, 2014 at 6:57 PM, Ray Donnelly
wrote:
> I'm tired, corrections inline:
>
> On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly
> wrote:
> > On Sun, Nov 2, 2014
Hi guys,
I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory
under mingw and I compile using msys/1.0 shell, or CMAKE from msys using
"MSYS Makefiles".
I adopted this after installing from a recipe and found it worked more
often than not in situations where plain mingw/msys (ins
, 2014 at 10:23 PM, Yaron Keren wrote:
> Hi,
>
> These _functions are in same as Visual C++.
> Maybe filefn.cpp does not #include it?
>
> Yaron
>
>
> 2014-10-30 0:51 GMT+02:00 Greg Jung :
>
>> Hi all,
>> Just as a matter of example, I run into
Hi all,
Just as a matter of example, I run into the following error compiling
wxMSW-2.8.12 using mingw/msys- gcc-4.8.2 (sjlj, win32):
../src/common/filefn.cpp: In function 'bool wxMkdir(const wxString&, int)':
../src/common/filefn.cpp:1253:30: error: '_mkdir' was not declared in this
scope
20 matches
Mail list logo
