From: | Kartik Ohri <kartikohri13(at)gmail(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | pljava-dev(at)lists(dot)postgresql(dot)org |
Subject: | Re: PL/Java new build plugin |
Date: | 2020-07-15 03:30:09 |
Message-ID: | CAASLQ4P+zUuWvpXb9U_CDY384P=sSNP0ATYCb0nf1d=sbt5TjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
>
> Thanks! Looks like I have fixed that with a42c416. Turned out to be
> Windows line endings, and it means I gave you bad advice with regard to
> getPgConfigProperty [1] after all. Even though pg_config explicitly writes
> a single \n character on every platform, Windows (probably the C library
> really) still changes it to \r\n before it arrives on the pipe. So just
> removing one character won't always work. It has to be line.separator
> (that, or an explicit test for Windows). Sorry for leading you astray.
>
Thanks for informing this. I'll check the plugin with this fix to see if
this now works on Windows.
Now the only appveyor "errors" I'm seeing seem to be a result of appveyor
> thinking anything written to stderr is a problem. So running the installer
> jar to install the files produces a wall of red every time, because it
> prints the installed file names to stderr. And then on Java 9 there is
> still one JNI reference warning, but that's being treated as a failure.
>
> The first of those problems can surely be fixed with a 2>&1 on the
> command running the installer jar (or whatever the equivalent Windows
> syntax is for "merge your stderr into stdout").
>
> The second looks a little trickier, as you're probably checking for
> warning output from install_jar(...examples...), which really does
> indicate trouble, but the WARNING: JNI local refs: does not.
There is another error as well on PG 10
https://ci.appveyor.com/project/amCap1712/pljava/builds/34099990/job/bgpqdy5qjkik2ya9,
one of the tests fails. This has been the case since I first added this
configuration.
I don't understand what the PG=9 configuration even is. The PG version
> numbering change happened in 10, so "9" could mean any of seven different
> major versions, and I can't even see from the log which of those the
> run is trying to use. I think that could be the reason it's failing too,
> because it's trying to run "\Program Files\PostgreSQL\9\bin\pg_ctl" and
> there is no such thing with just "9" as the version.
>
I had suspected the same but didn't test it due to some reason I seem to
have forgotten but I will do that now.
From | Date | Subject | |
---|---|---|---|
Next Message | Kartik Ohri | 2020-07-15 03:49:43 | Re: Just one Travis Mac OS build failed |
Previous Message | Chapman Flack | 2020-07-14 23:11:13 | Just one Travis Mac OS build failed |