čt 14. 10. 2021 v 19:24 odesílatel Andres Freund napsal:
>
> Hi,
>
> On 2021-10-14 10:29:42 -0300, Alvaro Herrera wrote:
> > On 2021-Oct-14, Josef Šimánek wrote:
> >
> > > I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate
> > > package. Anyway it behaves differently with autocon
čt 14. 10. 2021 v 15:32 odesílatel Dagfinn Ilmari Mannsåker
napsal:
>
> Josef Šimánek writes:
>
> > čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker
> > napsal:
> >>
> >> Josef Šimánek writes:
> >>
> >> > The only problem I do have currently is auto-detection of perl. I'm
> >> > gett
I wrote:
> Ok great, it builds now! :-) Now something's off with dynamic loading.
There are libraries in ./tmp_install/usr/local/lib/ but apparently initdb
doesn't know to look for them there:
>
> $ cat /Users/john/pgdev/meson/build/testrun/main/pg_regress/log/initdb.log
> dyld: Library not loaded
Hi,
On 2021-10-13 23:58:12 +0200, Josef Šimánek wrote:
> st 13. 10. 2021 v 1:54 odesílatel Andres Freund napsal:
> > This *very* likely is related to building in a source tree that also
> > contains
> > a "non-meson" build "in place". The problem is that the meson build picks up
> > the pg_confi
Hi,
On 2021-10-14 10:29:42 -0300, Alvaro Herrera wrote:
> On 2021-Oct-14, Josef Šimánek wrote:
>
> > I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate
> > package. Anyway it behaves differently with autoconf tools and the
> > meson build system. Is perl disabled by default in th
Josef Šimánek writes:
> čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker
> napsal:
>>
>> Josef Šimánek writes:
>>
>> > The only problem I do have currently is auto-detection of perl. I'm
>> > getting error related to missing "Opcode.pm". PERL is autodetected and
>> > enabled (https:/
On 2021-Oct-14, Josef Šimánek wrote:
> I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate
> package. Anyway it behaves differently with autoconf tools and the
> meson build system. Is perl disabled by default in the current build
> system?
Yes, you have to use --with-perl in ord
čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker
napsal:
>
> Josef Šimánek writes:
>
> > The only problem I do have currently is auto-detection of perl. I'm
> > getting error related to missing "Opcode.pm". PERL is autodetected and
> > enabled (https://pastebin.com/xfRRrDcU).
>
> Your
Josef Šimánek writes:
> The only problem I do have currently is auto-detection of perl. I'm
> getting error related to missing "Opcode.pm". PERL is autodetected and
> enabled (https://pastebin.com/xfRRrDcU).
Your Perl (not PERL) installation seems to be incomplete. Opcode.pm is a
core module, an
On Thu, Oct 14, 2021 at 4:51 AM John Naylor
wrote:
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/LDAP.framework/Headers/ldap.h:1:10:
> error: #include nested too deeply
> #include
> ^
I vaguely recall that PostgreSQL should build OK against Apple's cop
On 10/13/21 5:46 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
>> If you prep a patch I'll test it.
> Well, right now I'm wondering if the better fix is to just remove the whole
> win32 block. I don't know how far back, but afaict it's not needed. Seems to
st 13. 10. 2021 v 1:54 odesílatel Andres Freund napsal:
>
> Hi,
>
> On 2021-10-13 01:19:27 +0200, Josef Šimánek wrote:
> > I tried to clean and start from scratch, but I'm getting different
> > error probably related to wrongly configured JIT (LLVM wasn't found
> > during meson setup). I'll debug
Hi,
On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
> If you prep a patch I'll test it.
Well, right now I'm wondering if the better fix is to just remove the whole
win32 block. I don't know how far back, but afaict it's not needed. Seems to
have been needed for narwhal at some point, accordin
On 10/13/21 1:26 PM, Andres Freund wrote:
>
>> pexports will be in the resulting path, and the build will use the
>> native compiler.
> I don't see pexports anywhere in the msys installation. I can see it available
> on sourceforge, and I see a few others asking where to get it from in the
> cont
On Wed, Oct 13, 2021 at 1:42 PM Andres Freund wrote:
> I pushed the fix for that.
Ok great, it builds now! :-) Now something's off with dynamic loading.
There are libraries in ./tmp_install/usr/local/lib/ but apparently initdb
doesn't know to look for them there:
$ cat /Users/john/pgdev/meson/bu
Hi,
On 2021-10-13 13:19:36 -0400, John Naylor wrote:
> On Wed, Oct 13, 2021 at 12:37 PM Andres Freund wrote:
>
> > For the autoconf build CI currently does something similar via
> > LIBS="/usr/local/lib:$LIBS"
> > INCLUDES="/usr/local/include:$INCLUDES"
> > ...
> > LIBS="
Hi,
On 2021-10-13 08:55:38 -0400, Andrew Dunstan wrote:
> On 10/12/21 9:03 PM, Andres Freund wrote:
> > I managed to get this working. At first it failed because I don't have
> > pexports - it's not available inside msys as far as I could tell. And seems
> > to
> > be unmaintained. But replacing
On Wed, Oct 13, 2021 at 12:37 PM Andres Freund wrote:
> For the autoconf build CI currently does something similar via
> LIBS="/usr/local/lib:$LIBS"
> INCLUDES="/usr/local/include:$INCLUDES"
> ...
> LIBS="/usr/local/opt/openldap/lib:$LIBS"
> INCLUDES="/usr/local/op
Hi,
On 2021-10-13 11:51:03 -0400, John Naylor wrote:
> On Tue, Oct 12, 2021 at 4:59 PM Andres Freund wrote:
>
> > On 2021-10-12 15:55:22 -0400, John Naylor wrote:
> > > (I couldn't get a build working but I'll leave that aside for now).
> >
> > If you want to do that separately, I'll try to fix
On Tue, Oct 12, 2021 at 4:59 PM Andres Freund wrote:
> On 2021-10-12 15:55:22 -0400, John Naylor wrote:
> > (I couldn't get a build working but I'll leave that aside for now).
>
> If you want to do that separately, I'll try to fix it.
Okay, I pulled the latest commits and tried again:
[51/950]
On 10/12/21 9:03 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 13:42:56 -0700, Andres Freund wrote:
>> On 2021-10-12 16:02:14 -0400, Andrew Dunstan wrote:
>>> You do that by putting a path to it at the start of the PATH. The wrinkle in
>>> this is that you need prove to point to one that under
> On 12 Oct 2021, at 21:01, Andres Freund wrote:
> One thing that is nice with meson's testrunner is that it can parse the output
> of tap tests and recognizes the number of completed / failed subtests. I
> wonder whether we could make pg_regress' output tap compliant without the
> output quality
Hi,
On 2021-10-12 13:42:56 -0700, Andres Freund wrote:
> On 2021-10-12 16:02:14 -0400, Andrew Dunstan wrote:
> > You do that by putting a path to it at the start of the PATH. The wrinkle in
> > this is that you need prove to point to one that understands virtual
> > paths. So you do something like
Hi,
On 2021-10-13 01:19:27 +0200, Josef Šimánek wrote:
> I tried to clean and start from scratch, but I'm getting different
> error probably related to wrongly configured JIT (LLVM wasn't found
> during meson setup). I'll debug on my side to provide more info.
../src/backend/jit/jit.c:91:73: erro
út 12. 10. 2021 v 19:17 odesílatel Andres Freund napsal:
>
> Hi,
>
> On 2021-10-12 17:21:50 +0200, Josef Šimánek wrote:
> > > # build (uses automatically as many cores as available)
> > > ninja
> >
> > I'm getting errors at this step. You can find my output at
> > https://pastebin.com/Ar5VqfFG. Se
Hi,
On 2021-10-12 15:55:22 -0400, John Naylor wrote:
> On Tue, Oct 12, 2021 at 4:37 AM Andres Freund wrote:
> The build code looks pretty approachable for someone with no prior
> exposure, and feels pretty nice when running it
That's part of what attracted me...
> (I couldn't get a build worki
Hi,
On 2021-10-12 16:02:14 -0400, Andrew Dunstan wrote:
> You need to build against a native perl, like Strawberry or ActiveState.
> (I have had mixed success with Strawberry)
Do you understand why that is needed?
> You do that by putting a path to it at the start of the PATH. The wrinkle in
>
On 10/12/21 3:29 PM, Andres Freund wrote:
>
> Does that recipe get you to a build where ./configure --with-perl succeeds?
>
> I see this here:
>
> checking for Perl archlibexp... /usr/lib/perl5/core_perl
> checking for Perl privlibexp... /usr/share/perl5/core_perl
> checking for Perl useshrplib..
On Tue, Oct 12, 2021 at 4:37 AM Andres Freund wrote:
[Meson prototype]
The build code looks pretty approachable for someone with no prior
exposure, and feels pretty nice when running it (I couldn't get a build
working but I'll leave that aside for now).
> As far as I can tell the only OS that p
Hi,
On 2021-10-12 14:37:04 -0400, Andrew Dunstan wrote:
> On 10/12/21 2:09 PM, Andres Freund wrote:
> >> Hm. Yea, the perl thing is my fault - you should be able to get past it
> >> with
> >> -Dperl=disabled, and I'll take a look at fixing the perl detection. (*)
> > This is a weird one. I don't
On 10/12/21 2:37 PM, Andrew Dunstan wrote:
> On 10/12/21 2:09 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-10-12 09:59:26 -0700, Andres Freund wrote:
>>> On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
It hung because it expected the compiler to be 'ccache cc'. Hanging in
such a ca
Hi,
On 2021-10-12 09:15:41 -0700, Andres Freund wrote:
> > For example, at the time, gcc on macOS was not supported. Meson thought, if
> > you are on macOS, you are surely using the Apple compiler, and it supports
> > these options.
>
> I'm pretty sure this one now can just be overridden with CC=
On 10/12/21 2:23 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 14:11:39 -0400, Andrew Dunstan wrote:
>> On 10/12/21 12:59 PM, Andres Freund wrote:
>>> If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?
>> Here's the entire thing
>> Sanity check compiler command line: cc
On 10/12/21 2:09 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 09:59:26 -0700, Andres Freund wrote:
>> On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
>>> It hung because it expected the compiler to be 'ccache cc'. Hanging in
>>> such a case is kinda unforgivable. I remedied that by settin
Hi,
On 2021-10-12 14:11:39 -0400, Andrew Dunstan wrote:
> On 10/12/21 12:59 PM, Andres Freund wrote:
> > If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?
> Here's the entire thing
> Sanity check compiler command line: ccache cc sanitycheckc.c -o
> sanitycheckc.exe -D_FI
On 10/12/21 12:59 PM, Andres Freund wrote:
>
>
> If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?
Here's the entire thing
# cat
C:/tools/msys64/home/Administrator/postgresql/build/meson-logs/meson-log.txt
Build started at 2021-10-12T18:08:34.387568
Main binary: C:/
Hi,
On 2021-10-12 09:59:26 -0700, Andres Freund wrote:
> On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
> > It hung because it expected the compiler to be 'ccache cc'. Hanging in
> > such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
> > but it then errored out looking for
Hi,
On 2021-10-12 17:21:50 +0200, Josef Šimánek wrote:
> > # build (uses automatically as many cores as available)
> > ninja
>
> I'm getting errors at this step. You can find my output at
> https://pastebin.com/Ar5VqfFG. Setup went well without errors. Is that
> expected for now?
Thanks, that's
Hi,
On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
> It hung because it expected the compiler to be 'ccache cc'. Hanging in
> such a case is kinda unforgivable. I remedied that by setting 'CC=gcc'
> but it then errored out looking for perl libs. I think msys2 is going to
> be a bit difficult
Hi,
On 2021-10-12 15:30:57 +0200, Peter Eisentraut wrote:
> I played with $subject a few years ago and liked it. I think, like you
> said, meson is the best way forward. I support this project.
Cool.
> One problem I noticed back then was that some choices that we currently
> determine ourselv
On 10/12/21 11:28 AM, Andrew Dunstan wrote:
> On 10/12/21 4:37 AM, Andres Freund wrote:
>> # setup build directory
>> meson setup build --buildtype debug
> I took this for an outing on msys2 and it just seems to hang. If it's not
> hanging it's unbelievably slow.
>
>
It hung because it expected
Robert Haas writes:
> I think we're going to need some solution to this problem. We have too
> many people here with strong opinions about questions like this for me
> to feel good about the idea that we're going to collectively be OK
> with leaving these sorts of decisions up to some other projec
On 10/12/21 4:37 AM, Andres Freund wrote:
> # setup build directory
> meson setup build --buildtype debug
I took this for an outing on msys2 and it just seems to hang. If it's not
hanging it's unbelievably slow.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
.
út 12. 10. 2021 v 10:37 odesílatel Andres Freund napsal:
>
> Hi,
>
> For the last year or so I've on and off tinkered with $subject. I think
> it's in a state worth sharing now. First, let's look at a little
> comparison.
>
> My workstation:
>
> non-cached configure:
> current:11.80s
On 10/12/21 4:37 AM, Andres Freund wrote:
> git remote add andres g...@github.com:anarazel/postgres.git
ITYM:
git remote add andres git://github.com/anarazel/postgres.git
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Tue, Oct 12, 2021 at 9:31 AM Peter Eisentraut
wrote:
> One problem I noticed back then was that some choices that we currently
> determine ourselves in configure or the makefiles are hardcoded in
> meson. For example, at the time, gcc on macOS was not supported. Meson
> thought, if you are on
On 12.10.21 10:37, Andres Freund wrote:
For the last year or so I've on and off tinkered with $subject. I think
it's in a state worth sharing now. First, let's look at a little
comparison.
I played with $subject a few years ago and liked it. I think, like you
said, meson is the best way for
Hi,
On 2021-10-12 01:37:21 -0700, Andres Freund wrote:
> non-cached build (world-bin):
> current:40.46s
> ninja: 7.31s
Interestingly this is pretty close to the minimum achievable on my
machine from the buildsystem perspective.
A build with -fuse-ld=lld, which the above didn't
301 - 348 of 348 matches
Mail list logo
