Thread: 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@dunslane.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@dunslane.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@dunslane.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@dunslane.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@dunslane.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@dunslane.net>: > > > Tom Lane wrote: >> >> Andrew Dunstan <andrew@dunslane.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'sso it might not expose the problem. I'm going to make the iconv setup work like the other libraries, and hope it fixesbaiji'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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote:
> 2010/3/3 Andrew Dunstan <andrew@dunslane.net>:
>
>> Tom Lane wrote:
>>
>>> Andrew Dunstan <andrew@dunslane.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'sso it might not expose the problem. I'm going to make the iconv setup work like the other libraries, and hope it
fixesbaiji'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@dunslane.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@dunslane.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@dunslane.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@dunslane.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