On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On further review, if the initial configure was done without >> --with-libxml, xml2 is doomed anyway. > > True, but it's still possible to build a shlib that will then not work. > I just did, after manually supplying the right -I switch: > > make PROFILE=-I/usr/include/libxml2 > > Now admittedly a clueless person would be unlikely to know to do that, > but if his libxml installation were arranged so that no special -I > switch was needed (unlike the Fedora packaging), it'd be more likely > that this could happen. > >> This probably explains why no one's complained about this before, and >> I think the appropriate fix is to change just sepgsql. I would like >> to back-patch that (one-line) change into 9.1 as well, to eliminate >> this as a foot-gun for anyone who may be packaging that module for the >> first time. > > No objection to fixing or backpatching this, but I'm not seeing the > argument for treating this module differently from contrib/xml2. If you > believe that someone will try to manually build in contrib/sepgsql after > having failed to configure correctly, why do you not believe that for > xml2?
Because I screwed it up accidentally for sepgsql, and I can't screw it up for xml2 on purpose even after working fairly hard. Even after shoving in the necessary -I switch (through a slightly different mechanism than the one you just proposed), it still won't link, whether -lxml2 is on the command-line or not. That having been said, I don't mind changing them both symmetrically; I'm just convinced that there's any benefit. However, if you think that way is more future-proof or that I might be overlooking some scenario, fine! It won't hurt anything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers