Обсуждение: Link requirements creep
I was displeased to discover just now that in a standard RPM build of PG 8.3, psql and the other basic client programs pull in libxml2 and libxslt; this creates a package dependency that should not be there by any stretch of the imagination. The reason of course is that configure puts -lxml2 -lxslt into LIBS and psql's Makefile unquestioningly links with that list. Back in the days of static linking, this didn't hurt because unreferenced libraries didn't get pulled into the executable. But it seems that at least with Linux' linker, you get a reference to every shared library mentioned in the link command. One possible answer is to put these two libraries into a special make variable, comparable to the way that libossp-uuid is being handled, and use that variable only where wanted. However this seems to be a band-aid solution; we'll inevitably have the same kind of problem again in future. Another approach we could take is to allow configure to dump everything into LIBS, and institute a policy that no executable includes LIBS verbatim. Instead every link command must do something like libpq already does:$(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lgss -lssl -lsocket -lnsl-lresolv -lintl, $(LIBS)) to explicitly list the libraries this executable might need. This seems a lot more fail-safe, but it'd probably take awhile to get the filter lists right; and this doesn't seem like a route to a readily back-patchable solution. Thoughts, better ideas? regards, tom lane
On 5/18/08, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I was displeased to discover just now that in a standard RPM build of > PG 8.3, psql and the other basic client programs pull in libxml2 and > libxslt; this creates a package dependency that should not be there > by any stretch of the imagination. > Thoughts, better ideas? 1. Use -Wl,--as-needed as linker flag. Portability unknown... Can be autoconfed. 2. Lets have few top-level library dependencies as make variables: LIBPQ_LDFLAGS (LIBPQ_LIBS?) LIBPQ_CFLAGS Same for READLINE, LIBXML2, etc Maybe also BACKEND_* Then each component can pick groups as it needs. Basically the default autoconf style of putting all into LIBS work well only when you have single program to build. As in Postgres build-tree we have lots of modules that want different selection of libraries to link to, this style does not fit. -- marko
"Marko Kreen" <markokr@gmail.com> writes: > On 5/18/08, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I was displeased to discover just now that in a standard RPM build of >> PG 8.3, psql and the other basic client programs pull in libxml2 and >> libxslt; this creates a package dependency that should not be there >> by any stretch of the imagination. >> Thoughts, better ideas? > 1. Use -Wl,--as-needed as linker flag. Portability unknown... > Can be autoconfed. This might actually be the best solution. OS X has a similar disease but some trolling of the ld man page suggests that -dead_strip_dylibs might work there. Taking this path would amount to assuming that all linkers we care about either have an equivalent switch or don't link unrequired libraries in the first place. I'll do some experimenting... regards, tom lane
Tom Lane wrote: > >> 1. Use -Wl,--as-needed as linker flag. Portability unknown... >> Can be autoconfed. >> > > This might actually be the best solution. OS X has a similar disease > but some trolling of the ld man page suggests that -dead_strip_dylibs > might work there. Taking this path would amount to assuming that all > linkers we care about either have an equivalent switch or don't link > unrequired libraries in the first place. > > > Didn't we run into problems with this before? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: >>> 1. Use -Wl,--as-needed as linker flag. Portability unknown... > Didn't we run into problems with this before? Hm, yeah, thanks for reminding me to check the archives. We tried to do exactly this three years ago, and it crashed and burned. See http://archives.postgresql.org/pgsql-hackers/2005-10/msg01364.php The followup discussion to that was along the lines of "it's too late for 8.1, but we should try it for 8.2". Seems to have slipped through the cracks though. I've been testing a new patch and do not see the problem on Fedora 8, so at least that platform's readline seems to be fixed. I find the hack Martijn proposes in the above message to be pretty ugly, so what I'm inclined to do is leave that out for now and see what failures we get. The availability of the buildfarm makes experimenting with this kind of thing a lot safer ... regards, tom lane
On Sat, 17 May 2008, Tom Lane wrote: > I was displeased to discover just now that in a standard RPM build of > PG 8.3, psql and the other basic client programs pull in libxml2 and > libxslt; this creates a package dependency that should not be there > by any stretch of the imagination. When we noticed this recently, my digging suggested you'll be hard pressed to have a RedHat system now without those two installed. The libxslt RPM provides necessary components for KDE, GNOME, and Sun's Java RPM. libxml2 is far more intertwined even than that. These dependencies are unpleasant technically, but I don't think the introduce any real functional creep. It would be difficult to even strip a system down to the point where these packages weren't available. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith <gsmith@gregsmith.com> writes: > On Sat, 17 May 2008, Tom Lane wrote: >> I was displeased to discover just now that in a standard RPM build of >> PG 8.3, psql and the other basic client programs pull in libxml2 and >> libxslt; this creates a package dependency that should not be there >> by any stretch of the imagination. > When we noticed this recently, my digging suggested you'll be hard pressed > to have a RedHat system now without those two installed. Indeed, I've not heard any squawks from the field yet. It's still wrong though ... regards, tom lane
Tom Lane wrote: > I've been testing a new patch and do not see the problem on Fedora 8, > so at least that platform's readline seems to be fixed. I find > the hack Martijn proposes in the above message to be pretty ugly, > so what I'm inclined to do is leave that out for now and see what > failures we get. The availability of the buildfarm makes experimenting > with this kind of thing a lot safer ... > > > It broke my FC6 box :-( The box is due to be upgraded when I return from pgcon, but we have a few oldish boxes on the buildfarm. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> I've been testing a new patch and do not see the problem on Fedora 8, >> so at least that platform's readline seems to be fixed. > It broke my FC6 box :-( Yeah, I saw. I'm inclined to wait a day to get a handle on the scope of the problem before trying to choose an appropriate fix. regards, tom lane
On 18/05 00.59, Tom Lane wrote: > Greg Smith <gsmith@gregsmith.com> writes: > > On Sat, 17 May 2008, Tom Lane wrote: > >> I was displeased to discover just now that in a standard RPM build of > >> PG 8.3, psql and the other basic client programs pull in libxml2 and > >> libxslt; this creates a package dependency that should not be there > >> by any stretch of the imagination. > > > When we noticed this recently, my digging suggested you'll be hard pressed > > to have a RedHat system now without those two installed. > > Indeed, I've not heard any squawks from the field yet. It's still > wrong though ... I agree it's wrong, but I don't this is likely to be any problem in practice on Solaris either. -- Bjorn Munch PostgreSQL Release Engineering Database Group, Sun Microsystems
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Greg Smith <gsmith@gregsmith.com> writes: > > When we noticed this recently, my digging suggested you'll be hard pressed > > to have a RedHat system now without those two installed. > > Indeed, I've not heard any squawks from the field yet. It's still > wrong though ... Unsuprisingly, half the world in Debian also depends on libxml2, but I agree 110% w/ Tom- it's wrong, and I feel it really ought to be fixed regardless. It's entirely likely that there will come a time when it's a less used library getting pulled in, too. I also personally hate useless clutter in dependencies as it can cause package management headaches.. After poking around a bit I did find a box that only pulled in libxml2 for subversion, and we've been talking about moving to a different SCM (which don't appear to depend on libxml2), so it might eventually only be pulled in by psql for us. Not a show-stopper, but it's also not completely out of the question that it'll get pulled in unnecessairly. Thanks, Stephen
I wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> It broke my FC6 box :-( > Yeah, I saw. I'm inclined to wait a day to get a handle on the scope > of the problem before trying to choose an appropriate fix. So the returns are in, and buildfarm says: this is only broken on Red Hat-based systems. How embarrassing :-( It's evidently fixed in Fedora 7 and up, which means that only EOL'd Fedora distributions are affected, but since RHEL 5 is affected I'm still on the hook to fix it. What I'm inclined to do is move the test for -Wl,--as-needed down till after we've determined the readline dependent-libraries situation, and then enable it only if we can still link readline with it on. So a system with broken readline won't get the benefit. But the available evidence says that there are too few such systems to justify a more complicated solution. Comments? regards, tom lane
Tom Lane wrote: > I wrote: > >> Andrew Dunstan <andrew@dunslane.net> writes: >> >>> It broke my FC6 box :-( >>> > > >> Yeah, I saw. I'm inclined to wait a day to get a handle on the scope >> of the problem before trying to choose an appropriate fix. >> > > So the returns are in, and buildfarm says: this is only broken on > Red Hat-based systems. How embarrassing :-( > > It's evidently fixed in Fedora 7 and up, which means that only EOL'd > Fedora distributions are affected, but since RHEL 5 is affected I'm > still on the hook to fix it. > > What I'm inclined to do is move the test for -Wl,--as-needed down till > after we've determined the readline dependent-libraries situation, and > then enable it only if we can still link readline with it on. So a > system with broken readline won't get the benefit. But the available > evidence says that there are too few such systems to justify a more > complicated solution. > > > Works for me. I don't think we need anything heroic either. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> What I'm inclined to do is move the test for -Wl,--as-needed down till >> after we've determined the readline dependent-libraries situation, and >> then enable it only if we can still link readline with it on. > Works for me. I don't think we need anything heroic either. Applied, we'll see what happens ... regards, tom lane