Re: USE_LIBXSLT in MSVC builds

BTW, it looks like the MSVC build scripts don't bother to make sure that
USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
reference to that symbol in the Windows-specific files. This is now
necessary to avoid disabling the xslt functionality in contrib/xml2.
I'm not too sure what to poke there, any help?

regards, tom lane

Tom Lane wrote:
> BTW, it looks like the MSVC build scripts don't bother to make sure that
> USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
> reference to that symbol in the Windows-specific files. This is now
> necessary to avoid disabling the xslt functionality in contrib/xml2.
> I'm not too sure what to poke there, any help?
>
>

I have committed a fix for this.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> BTW, it looks like the MSVC build scripts don't bother to make sure that
>> USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
>> reference to that symbol in the Windows-specific files. This is now
>> necessary to avoid disabling the xslt functionality in contrib/xml2.
>> I'm not too sure what to poke there, any help?

> I have committed a fix for this.

Thanks, but please backpatch --- all active branches need this.

Also, mastodon is still failing the xml2 test, not sure why. Looks to
be a build problem, but why is (for instance) baiji unaffected?

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Tom Lane wrote:
>>
>>> BTW, it looks like the MSVC build scripts don't bother to make sure that
>>> USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
>>> reference to that symbol in the Windows-specific files. This is now
>>> necessary to avoid disabling the xslt functionality in contrib/xml2.
>>> I'm not too sure what to poke there, any help?
>>>
>
>
>> I have committed a fix for this.
>>
>
> Thanks, but please backpatch --- all active branches need this.
>

OK, I have gone back as far as 8.2, which is where the MSVC build system
started. I'm keeping my fingers crossed slightly about the 8.2 fix. 8.3
and 8.4 should be fine. We don't have buildfarm coverage for 8.2, as the
MSVC build system wasn't mature enough at that stage.

> Also, mastodon is still failing the xml2 test, not sure why. Looks to
> be a build problem, but why is (for instance) baiji unaffected?
>
>

Baiji built before I put in the patch, so it didn't have USE_LIBXSLT
enabled.

Looks like we have a bit more work to do ;-(

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Also, mastodon is still failing the xml2 test, not sure why. Looks to
>> be a build problem, but why is (for instance) baiji unaffected?

> Baiji built before I put in the patch, so it didn't have USE_LIBXSLT
> enabled.

But mastodon is failing entirely, which isn't explained by having or
omitting USE_LIBXSLT. AFAICS that would just result in suppressing
the xslt functionality, which the regression test wouldn't complain
about now that we have a variant expected file that allows it.

> Looks like we have a bit more work to do ;-(

Yeah. I guess what this indicates is that contrib/xml2 never worked
at all in some/all Windows configurations? Do we know of anyone
having used it successfully?

regards, tom lane

BTW, now that I look at red_bat's failure, it seems that the MSVC build
scripts try to run the contrib/xml2 test even when xml2 hasn't been
built for lack of libxml. This doesn't explain mastodon's problem
but maybe a second look is needed at all the conditionals around that.

regards, tom lane

Tom Lane wrote:
> BTW, now that I look at red_bat's failure, it seems that the MSVC build
> scripts try to run the contrib/xml2 test even when xml2 hasn't been
> built for lack of libxml. This doesn't explain mastodon's problem
> but maybe a second look is needed at all the conditionals around that.
>
>
>

Well, the trouble is to some extent that the MSVC build system tries to
be a bit more maximal than the stardard build system.

I'm going to make a patch to fix that immediate problem, and test it
very quickly on red_bat. Maybe Magnus and I need to have another go
round on the general logic, however.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> BTW, now that I look at red_bat's failure, it seems that the MSVC build
>> scripts try to run the contrib/xml2 test even when xml2 hasn't been
>> built for lack of libxml. This doesn't explain mastodon's problem
>> but maybe a second look is needed at all the conditionals around that.
>>
>>
>>
>
> Well, the trouble is to some extent that the MSVC build system tries
> to be a bit more maximal than the stardard build system.
>
> I'm going to make a patch to fix that immediate problem, and test it
> very quickly on red_bat. Maybe Magnus and I need to have another go
> round on the general logic, however.
>
>

OK, I have made patches that get red_bat working both with and without
XML and with XML+XSLT configured. It has now gone green again, so I'm
fairly sure the patches I have applied are right.

Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
dll?

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
> dll?

Curious indeed, because it passed yesterday, *after* I had made all
those changes in contrib/xml2 itself. The only deltas since then are
your MSVC script additions. Now presumably, the XSLT support was
commented out in yesterday's run for lack of USE_LIBXSLT, and the "pass"
was against the variant output file that allowed for that to fail.
So I think you're right that there's something wrong with the link
to libxslt, but how come no sign of trouble in the build log? Does
Windows have an equivalent of "rpath" that maybe we're forgetting to
add libxslt to?

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
>> dll?
>>
>
> Curious indeed, because it passed yesterday, *after* I had made all
> those changes in contrib/xml2 itself. The only deltas since then are
> your MSVC script additions. Now presumably, the XSLT support was
> commented out in yesterday's run for lack of USE_LIBXSLT, and the "pass"
> was against the variant output file that allowed for that to fail.
> So I think you're right that there's something wrong with the link
> to libxslt, but how come no sign of trouble in the build log? Does
> Windows have an equivalent of "rpath" that maybe we're forgetting to
> add libxslt to?
>
>
>

There is something funny about the iconv setup (libxml requires iconv).
My paths on red_bat are a bit different from baiji's so it might not
expose the problem. I'm going to make the iconv setup work like the
other libraries, and hope it fixes baiji's problem.

cheers

andrew

2010/3/3 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>>
>>> Baiji is now failing, however. Perhaps it is not finding the XSLT lib or dll?
>>>
>>
>> Curious indeed, because it passed yesterday, *after* I had made all
>> those changes in contrib/xml2 itself.  The only deltas since then are
>> your MSVC script additions.  Now presumably, the XSLT support was
>> commented out in yesterday's run for lack of USE_LIBXSLT, and the "pass"
>> was against the variant output file that allowed for that to fail.
>> So I think you're right that there's something wrong with the link
>> to libxslt, but how come no sign of trouble in the build log?  Does
>> Windows have an equivalent of "rpath" that maybe we're forgetting to
>> add libxslt to?
>>
>>
>>
>
> There is something funny about the iconv setup (libxml requires iconv). My paths on red_bat are a bit different from baiji's so it might not expose the problem. I'm going to make the iconv setup work like the other libraries, and hope it fixes baiji's problem.

Yeah, there are some weird cross dependencies along that. The MSVC
build system really expects you to have libxml+libxslt+iconv all
installed to really get any of them to work. I originally had them all
work the same, but that didn't work, so I just put that in place -
blame being lazy for that. It may well be that it works now due to
other changes around the build system, but originally that hack was
required to make it build at all with XML. But it's good news if it's
not needed anymore and they can all work the same :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander wrote:
> 2010/3/3 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>> Tom Lane wrote:
>>
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>>
>>>> Baiji is now failing, however. Perhaps it is not finding the XSLT lib or dll?
>>>>
>>>>
>>> Curious indeed, because it passed yesterday, *after* I had made all
>>> those changes in contrib/xml2 itself. The only deltas since then are
>>> your MSVC script additions. Now presumably, the XSLT support was
>>> commented out in yesterday's run for lack of USE_LIBXSLT, and the "pass"
>>> was against the variant output file that allowed for that to fail.
>>> So I think you're right that there's something wrong with the link
>>> to libxslt, but how come no sign of trouble in the build log? Does
>>> Windows have an equivalent of "rpath" that maybe we're forgetting to
>>> add libxslt to?
>>>
>>>
>>>
>>>
>> There is something funny about the iconv setup (libxml requires iconv). My paths on red_bat are a bit different from baiji's so it might not expose the problem. I'm going to make the iconv setup work like the other libraries, and hope it fixes baiji's problem.
>>
>
> Yeah, there are some weird cross dependencies along that. The MSVC
> build system really expects you to have libxml+libxslt+iconv all
> installed to really get any of them to work. I originally had them all
> work the same, but that didn't work, so I just put that in place -
> blame being lazy for that. It may well be that it works now due to
> other changes around the build system, but originally that hack was
> required to make it build at all with XML. But it's good news if it's
> not needed anymore and they can all work the same :-)
>
>

It's not working on mastodon, and presumably will fail again on baiji.

I notice that mastodon does not appear to have the presumed location of
the iconv and xslt DLLs in the PATH it sets. That would be a plausible
explanation of the problem ;-) On red_bat these are all in the same bin
directory, but I suspect on baiji and mastodon they are not. I think
these might need to have c:\pgBuild\{libxslt,iconv}\bin added to the
PATH in the buildfarm.conf file, right after where
c:\pgBuild\libxml2\bin is added. (That could also explain why it is
failing at run time rather than at build time).

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> It's not working on mastodon, and presumably will fail again on baiji.

> I notice that mastodon does not appear to have the presumed location of
> the iconv and xslt DLLs in the PATH it sets. That would be a plausible
> explanation of the problem ;-)

Ah. If it's just misconfiguration of the buildfarm animals, that would
also explain the lack of complaints from the field about contrib/xml2
not working on Windows.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> It's not working on mastodon, and presumably will fail again on baiji.
>>
>
>
>> I notice that mastodon does not appear to have the presumed location of
>> the iconv and xslt DLLs in the PATH it sets. That would be a plausible
>> explanation of the problem ;-)
>>
>
> Ah. If it's just misconfiguration of the buildfarm animals, that would
> also explain the lack of complaints from the field about contrib/xml2
> not working on Windows.
>
Something completely different but a bit alike; today I chased a strange
initdb bug on a rarely used machine. It said something with fgets: some
file error (sorry, history is gone from shell) and then the message that
postgres could not be found in the same path as initdb. But all was
there, permissions etc ok.

In the end it turned out that the fgets error was near the real problem:
postgres was started with -V by initdb and the output read via a pipe.
(function was find_other_exec) But the postgres command failed with an
error that a shared library could not be loaded, however this error
message was not picked up by the pipe read command / error message by
initdb, which maked it hard to diagnose without getting to the debugger.

I don't know if the buildfarm machines fail on initdb, however I think
that maybe a better errormessage at that point in initdb could help
future users.

regards,
Yeb Havinga

On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> I think these
> might need to have c:\pgBuild\{libxslt,iconv}\bin added to the PATH in the
> buildfarm.conf file, right after where c:\pgBuild\libxml2\bin is added.

This is now done. Sorry for the delay.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do

Dave Page wrote:
> On Wed, Mar 3, 2010 at 12:18 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> I think these
>> might need to have c:\pgBuild\{libxslt,iconv}\bin added to the PATH in the
>> buildfarm.conf file, right after where c:\pgBuild\libxml2\bin is added.
>>
>
> This is now done. Sorry for the delay.
>
>

... and mastodon is now green, so that was in fact the problem. Yay!

cheers

andrew