eed to patch the rule so that the LN_S is called so that it'd
> resolve
> correctly in both cases. I guess the easy option is to go back to the
> original
> recipe and update the comment to indicate that we do it to placate Msys2.
> Here it is with the old comment:
>
> -# The
x27;d resolve correctly in both cases. I guess the easy option is to go
back to the original recipe and update the comment to indicate that we
do it to placate Msys2. Here it is with the old comment:
-# The point of the prereqdir incantation in some of the rules below is to
-# force the symlink
> > I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing me
> grief.
> > This seems to work okay buildi
On 2024-Apr-04, Regina Obe wrote:
> I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing
> me grief.
>
d the change
> > ../include/storage/lwlocklist.h to
> > $(top_builddir)/src/include/storage/lwlocklist.h
>
> I assume you meant that instead of $(topdir)
>
> But nah that made no difference. Your change was already in my patched
> version so isn't causing any issues.
> Hi Regina,
>
> On 2024-Mar-27, Regina Obe wrote:
>
> > The error is
> >
> > rm -f '../../src/include/storage/lwlocknames.h'
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > '../../src/include/storage/lwlocknames.h'
> > cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such
>
> Hi Regina,
>
> On 2024-Mar-27, Regina Obe wrote:
>
> > The error is
> >
> > rm -f '../../src/include/storage/lwlocknames.h'
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > '../../src/include/storage/lwlocknames.h'
> > cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such
>
Hi Regina,
On 2024-Mar-27, Regina Obe wrote:
> The error is
>
> rm -f '../../src/include/storage/lwlocknames.h'
> cp -pR ../../backend/storage/lmgr/lwlocknames.h
> '../../src/include/storage/lwlocknames.h'
> cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such file or
> directory
I've been having trouble compiling PG 17 using msys2 / mingw64 (sorry my
meson setup is a bit broken at moment, so couldn't test that.).
Both my msys2 envs (Rev2, Built by MSYS2 project) 13.2.0 and my older
setup (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
Have the
On 2023-05-17 We 17:55, Andres Freund wrote:
Hi,
On May 17, 2023 2:51:41 PM PDT, Andrew Dunstan wrote:
On 2023-05-16 Tu 17:52, Andres Freund wrote:
I suppose the alternative would be to change the way the buildfarm calls
pg_ctl stop. Do you have a concrete suggestion for that?
The easiest f
Hi,
On May 17, 2023 2:51:41 PM PDT, Andrew Dunstan wrote:
>
>On 2023-05-16 Tu 17:52, Andres Freund wrote:
>>
>>> I suppose the alternative would be to change the way the buildfarm calls
>>> pg_ctl stop. Do you have a concrete suggestion for that?
>> The easiest fix is to redirect stdin to /dev/
On 2023-05-16 Tu 17:52, Andres Freund wrote:
I suppose the alternative would be to change the way the buildfarm calls
pg_ctl stop. Do you have a concrete suggestion for that?
The easiest fix is to redirect stdin to /dev/null (or some file, if that's
easier to do portably) - that should fix th
tion, after having previously started a shell, which left a
program running (thus still referencing the same console device).
> This piece of code has worked happily for years. It's only a recent
> installation or update of msys2 that's made the problem appear.
Yea, it does look like a
ependent on a wrapper cmd or such.
I don't know where this all leaves us. It's still more than odd that the
start works fine and the stop doesn't.
This piece of code has worked happily for years. It's only a recent
installation or update of msys2 that's made the pr
Hi,
On 2023-05-15 15:30:28 -0700, Andres Freund wrote:
> As soon as either the pg_ctl for the start, or the whole bash invocation, has
> stdin redirected, the problem vanishes.
For a moment I thought this could be related to InheritStdHandles() - but no,
it doesn't make a difference.
There's loa
Hi,
On 2023-05-15 13:13:26 -0700, Andres Freund wrote:
> It wouldn't really - the echo $? inside the system() would report the
> error. Which it doesn't - note the "0" in the second output.
Ah. Interesting. Part of the issue is perl (or msys?) swalling some error
details.
I could see more detail
Hi,
On 2023-05-15 16:01:39 -0400, Andrew Dunstan wrote:
> On 2023-05-15 Mo 15:38, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> > > If you want to play I can arrange access.
> > Andrew did - thanks!
> >
> >
> > A first observeration is that making th
On 2023-05-15 Mo 15:38, Andres Freund wrote:
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
If you want to play I can arrange access.
Andrew did - thanks!
A first observeration is that making the shell command slightly more
complicated, by echoing $? after pg_ctl, prevents the erro
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> If you want to play I can arrange access.
Andrew did - thanks!
A first observeration is that making the shell command slightly more
complicated, by echoing $? after pg_ctl, prevents the error:
/usr/bin/perl -e 'system(qq{"bin/pg_ctl" -D
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> On 2023-05-04 Th 19:54, Andres Freund wrote:
> > Hm. I can't reproduce this in my test win10 VM, unfortunately. What OS / OS
> > version is the host? Any chance to get systeminfo.exe output or something
> > like
> > that?
>
>
> Its a Win
meson:
Here's a simple illustration of the problem. If I do the identical test with
a non-meson build there is no problem:
This happens 100% reproducible?
For a sufficiently modern installation of msys2 (20230318 version) this is
reproducible on autoconf builds as well.
For now it's o
meson:
> > >
> > > Here's a simple illustration of the problem. If I do the identical test
> > > with
> > > a non-meson build there is no problem:
> > This happens 100% reproducible?
>
> For a sufficiently modern installation of msys2 (20230318 ver
support for meson:
Here's a simple illustration of the problem. If I do the identical test with
a non-meson build there is no problem:
This happens 100% reproducible?
For a sufficiently modern installation of msys2 (20230318 version) this is
reproducible on autoconf builds as well.
Oh. Seems
f the problem. If I do the identical test with
a non-meson build there is no problem:
This happens 100% reproducible?
For a sufficiently modern installation of msys2 (20230318 version)
this is reproducible on autoconf builds as well.
For now it's off my list of meson blockers. I will pursue
; > > buildfarm support for meson:
> > >
> > > Here's a simple illustration of the problem. If I do the identical test
> > > with
> > > a non-meson build there is no problem:
> > This happens 100% reproducible?
> For a sufficiently modern installation
meson build there is no problem:
This happens 100% reproducible?
For a sufficiently modern installation of msys2 (20230318 version) this
is reproducible on autoconf builds as well.
For now it's off my list of meson blockers. I will pursue the issue when
I have time, but for now th
Hi,
On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> Still running into this, and I am rather stumped. This is a blocker for
> buildfarm support for meson:
>
> Here's a simple illustration of the problem. If I do the identical test with
> a non-meson build there is no problem:
This happens
On 2023-04-26 We 11:30, Tom Lane wrote:
Andrew Dunstan writes:
If I redirect the output to a file (which is what the buildfarm client
actually does), it seems like it completes successfully, but I still get
a non-zero exit:
pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/H
Andrew Dunstan writes:
> If I redirect the output to a file (which is what the buildfarm client
> actually does), it seems like it completes successfully, but I still get
> a non-zero exit:
> pgrunner@EC2AMAZ-GCB871B UCRT64 ~/bf
> $ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-4
On 2023-04-26 We 10:58, Tom Lane wrote:
I wrote:
Looking at the pg_ctl source code, the only way I can explain that
printout is that do_stop called wait_for_postmaster_stop which,
after one or more loops, exited via one of its exit() calls.
Ah, a little too hasty there: it's get_pgpid() that h
I wrote:
> Looking at the pg_ctl source code, the only way I can explain that
> printout is that do_stop called wait_for_postmaster_stop which,
> after one or more loops, exited via one of its exit() calls.
Ah, a little too hasty there: it's get_pgpid() that has to be
reaching an exit().
Andrew Dunstan writes:
>> For some reason which makes no sense to me the buildfarm animal fails
>> at the first Stop-Db step. The DB is actually stopped, but pg_ctl
>> returns a non-zero status. The thing that's really odd is that meson
>> isn't at all involved in this step. But it's happened e
On 2023-03-27 Mo 13:18, Andres Freund wrote:
Hi,
On 2023-03-26 21:13:41 -0400, Andrew Dunstan wrote:
On Mar 26, 2023, at 5:28 PM, Andres Freund wrote:
On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
First: I am *not* arguing we shouldn't repair building against strawberry perl
with mingw.
Hi,
On 2023-03-26 21:13:41 -0400, Andrew Dunstan wrote:
> > On Mar 26, 2023, at 5:28 PM, Andres Freund wrote:
> >> On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
> >> First: I am *not* arguing we shouldn't repair building against strawberry
> >> perl
> >> with mingw.
> >
> > Hm - can you de
> On Mar 26, 2023, at 5:28 PM, Andres Freund wrote:
>
> Hi,
>
>> On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
>> First: I am *not* arguing we shouldn't repair building against strawberry
>> perl
>> with mingw.
>
> Hm - can you describe the failure more - I just tried, and it worked t
Hi,
On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
> First: I am *not* arguing we shouldn't repair building against strawberry perl
> with mingw.
Hm - can you describe the failure more - I just tried, and it worked to build
against strawberry perl on mingw, without any issues. All I did was s
t; > it will happily build with autoconf.
> > I did not try to build with strawberry perl using mingw - it doesn't seem
> > like
> > a very interesting thing, given that mingw has a much more reasonable perl
> > than strawberry - but with the mingw perl it works well.
t with the mingw perl it works well.
Strawberry is a recommended perl installation for Windows
(<https://www.perl.org/get.html>) and is widely used AFAICT.
In general my approach has been to build as independently as possible
from msys2 infrastructure, in particular a) not to rely on it at
Hi,
On 2023-03-25 08:46:42 -0400, Andrew Dunstan wrote:
> config/perl.m4 contains this:
>
>
>AC_MSG_CHECKING(for flags to link embedded Perl)
>if test "$PORTNAME" = "win32" ; then
> perl_lib=`basename $perl_archlibexp/CORE/perl[[5-9]]*.lib .lib`
> if test -e "$perl_archlibe
Hi,
config/perl.m4 contains this:
AC_MSG_CHECKING(for flags to link embedded Perl)
if test "$PORTNAME" = "win32" ; then
perl_lib=`basename $perl_archlibexp/CORE/perl[[5-9]]*.lib .lib`
if test -e "$perl_archlibexp/CORE/$perl_lib.lib"; then
perl_embed_ldflags="-
On 7/28/21 9:31 AM, Andrew Dunstan wrote:
> While looking into issues with fairywren and pg_basebackup tests, I
> created a similar environment but with more modern Windows / msys2.
> Before it even got to the test that failed on fairywren it failed the
> first TAP test for a variet
While looking into issues with fairywren and pg_basebackup tests, I
created a similar environment but with more modern Windows / msys2.
Before it even got to the test that failed on fairywren it failed the
first TAP test for a variety of reasons, all connected to
TestLib::perl2host.
First, this
On 2019-12-31 11:56, Peter Eisentraut wrote:
On 2019-12-04 11:32, Guram Duka wrote:
Master branch got error in configure stage and then compiling like 12.1
branch.
checking how to link an embedded Python application... configure:
error: could not find shared library for Python
Yo
On 2019-12-04 11:32, Guram Duka wrote:
Master branch got error in configure stage and then compiling like 12.1
branch.
checking how to link an embedded Python application... configure:
error: could not find shared library for Python
You might have to rebuild your Python installation
On 2019-12-12 22:11, Peter Eisentraut wrote:
You can also build natively on MSYS2, using the existing Cygwin support.
Except that it won't work because configure doesn't recognize the
config.guess output. Attached are a couple of small patches to fix that
up. The first patch fixes
There were a number of recent threads about building PostgreSQL on
MSYS2. This has been confusing on occasion; see for example [0]. MSYS2
is actually a derivative of Cygwin. What most people are actually doing
is using MSYS2 has the host environment for doing a kind of
cross-compilation to
ils. Use --without-python to disable building
> PL/Python.
>
> I registered the patch.
>
ср, 4 дек. 2019 г. в 11:05, Michael Paquier :
> On Wed, Dec 04, 2019 at 10:46:39AM +0300, Guram Duka wrote:
> > I made a patch fixing build and install problems under MSYS2, includi
On Wed, Dec 04, 2019 at 10:46:39AM +0300, Guram Duka wrote:
> I made a patch fixing build and install problems under MSYS2, including
> llvmjit.
>
> I have tested this in my environment and it works, of course need more
> extensive testing.
> Attached is a patch that fixes it.
Hi hackers.
I made a patch fixing build and install problems under MSYS2, including
llvmjit.
I have tested this in my environment and it works, of course need more
extensive testing.
Attached is a patch that fixes it. Tag REL_12_1.
--
Best regards.
Guram Duka.
postgresql-12.1-msys2-v1.patch
Thank you for your comments.
1. The #if ... defined(__ cplusplus) is necessary for the successful
compilation of C++ llvmjit code that uses C headers.
2. #if defined(HAVE_GSS_API_H) && !defined(GSS_DLLIMP) is necessary for the
successful link libgss.a provided by MSYS2.
3. Remember that
On Mon, Nov 11, 2019 at 10:56:51AM -0500, Tom Lane wrote:
> This seems like it probably breaks a lot of other cases along the way.
> Why have you made all these #if tests dependent on defined(__cplusplus)?
> That's surely not specific to MSYS2. (I'm a bit bemused by the i
=?UTF-8?B?0JPRg9GA0LDQvCDQlNGD0LrQsA==?= writes:
> I made a patch fixing build and install problems under MSYS2, including
> llvmjit.
This seems like it probably breaks a lot of other cases along the way.
Why have you made all these #if tests dependent on defined(__cplusplus)?
That's
Hi hackers.
I made a patch fixing build and install problems under MSYS2, including
llvmjit.
I have tested this in my environment and it works, of course need more
extensive testing.
Attached is a patch that fixes it. Tag REL_11_5. Easy to adapt for other
versions.
--
Best regards.
Guram Duka
We rely on pexports to extract exported symbols from DLL files (e.g. for
linking in PLs) when building with mingw. However, this program isn't
present in msys2. Instead the approved way is apparently to call
"gendef" from the appropriate toolset (e.g. /mingw64/bin). I have worked
On 9/9/19 4:48 AM, Peter Eisentraut wrote:
> On 2019-09-09 00:06, Andrew Dunstan wrote:
>> Diagnosing this took quite a lot of time and detective work. For some
>> reason I don't quite understand, when calling the Windows command
>> processor in a modern msys2/WindowsSe
On 2019-09-09 00:06, Andrew Dunstan wrote:
> Diagnosing this took quite a lot of time and detective work. For some
> reason I don't quite understand, when calling the Windows command
> processor in a modern msys2/WindowsServer2019 installation, you need to
> double the slash, t
Diagnosing this took quite a lot of time and detective work. For some
reason I don't quite understand, when calling the Windows command
processor in a modern msys2/WindowsServer2019 installation, you need to
double the slash, thus:
cmd //c foo.bat
Some Internet postings at least se
Disclaimer: I might have done things in not the best way - I'll happily
accept correction.
Here is some information about building on msys2, the rewrite of msys,
plus a proposal for a couple of tiny changes to support it.
The simplest way to install msys2 is via the chocolatey pa
/R-3.5._/postgres/build
$ make install
ref
Issues while building PG in MS Windows, using MSYS2 and MinGW-w64
https://www.postgresql-archive.org/Issues-while-building-PG-in-MS-Windows-using-MSYS2-and-MinGW-w64-td6018897.html
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
st=x86_64-w64-mingw32 --prefix=$PWD
--enable-debug --disable-rpath --enable-depend --without-zlib
$ make
All of PostgreSQL successfully made.
Ready to install.
AnonymousUser@ANONYMOUST MINGW64 /w/R-3.5._/postgres/build
$ make install
ref
Issues while building PG in MS Windows, using MSYS2 and Mi
On Fri, May 4, 2018 at 2:30 PM, Robert Haas wrote:
> On Thu, May 3, 2018 at 5:25 PM, Andrew Dunstan
> wrote:
>> I've been getting an Msys2 environment working, and will soon document
>> how to build with this environment. There are several nice things
>> about it,
On Thu, May 3, 2018 at 5:25 PM, Andrew Dunstan
wrote:
> I've been getting an Msys2 environment working, and will soon document
> how to build with this environment. There are several nice things
> about it, including a modern version of perl and proper support for
> the mi
I've been getting an Msys2 environment working, and will soon document
how to build with this environment. There are several nice things
about it, including a modern version of perl and proper support for
the mingw-w64 compilers.
So far the only thing I have found that needs to be changed f
Hello, insaf.k.
You wrote:
ik> Hello,
ik> I am trying to build PG from source, in MS Windows using MSYS2
ik> and MinGW-w64. I've tried to build PG 10.0 as wells as 10.3.
Just checked. All compiled in a sane way. I suppose you have some
environmental problems.
This is my step
"insaf.k" wrote:
I am trying to build PG from source, in MS Windows using MSYS2 and
MinGW-w64. I've tried to build PG 10.0 as wells as 10.3.
I've done configuring like this
./configure --prefix="/d/pg10/"
And when I do "make" or "make world&qu
If you have time, can you check CMake version?
https://github.com/stalkerg/postgres_cmake
During Mingw installation you can choose a version, it can be more MSVC
like or more Unix, probably Postgres have a problem with one of mingw type.
So I unpacked the source tarball within the shell itself(u
-ready compiler
> wouldn't handle that.
>
>
I haven't looked deeply at this thread, but it's worth pointing out that
MSYS2 is not the same thing as MSYS, and I at least have no experience
of building with it.
Now Msys hasn't been updated fo
"insaf.k" writes:
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Wendif-labels -Wmissing-format-attribute -Wformat-security
> -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -std=c11
> -I../../src/port -DFRONTEND -I../../src/include -I./src/includ
Hi Tom Lane,
Thanks for the help.
I had extracted PG using WinZip outside of MSYS2, and it was causing many of
the errors, may be due to some errors in file attributes. So I unpacked the
source tarball within the shell itself(using gunzip and tar), and I could fix
many errors.
Now
Hello,
as a complement:
I used MSYS2 and MinGW-w64 to build version 11devel
from https://www.postgresql.org/ftp/snapshot/dev/
on my win 7 64 bit desktop.
What I remember is that I found good advices in
https://www.postgresql.org/docs/current/static/installation-platform-notes.html#INSTALLATION
"insaf.k" writes:
> I am trying to build PG from source, in MS Windows using MSYS2 and MinGW-w64.
> I've tried to build PG 10.0 as wells as 10.3.
> I've done configuring like this
> ./configure --prefix="/d/pg10/"
> And when I do "make&quo
Hello,
I am trying to build PG from source, in MS Windows using MSYS2 and MinGW-w64.
I've tried to build PG 10.0 as wells as 10.3.
I've done configuring like this
./configure --prefix="/d/pg10/"
And when I do "make" or "make world", I
72 matches
Mail list logo
