On 06/04/2011 02:42 AM, Maciej Bliziński wrote: > 2011/6/3 John Ellson <ell...@opencsw.org>: >> I should expand on this: >> >>> Libtool built and linked them in the build tree, they only become >>> unavailable when installing them into DESTDIR, which is not the final >>> install location, during the "make install" step for constructing the >>> packages. >> "make install" uses "libtool install" which relinks the targets using the >> target install location -L paths. This is what produces the >> .libs/libfoobar.so.1.2.3T files. These T files that are renamed and >> packaged in DESTDIR, but of course the library depdencies (shown by ldd) are >> broken until all of the packages in the package-set are installed. > How are they broken?
If you use ldd on them, before the entire package-set is installed, they will show "not found" on the dependent libraries from the same-package set that are not installed yet. Not really "broken" I suppose. The libs are fine once ther are all installed. >> And this all breaks if an old libfoobar.so is already installed, since >> libtool will pick that up, incorrectly, when linking the T file. >> Solution to that is to uninstall the -devel package of the old release. >> Which is what we did today for graphviz. >> >> (The -devel package contains libfoobar.so and libfoobar.so.0 softlinks. >> The real, old libfoobar.0.1.2.so is OK, apparently because libtool knows >> that its not the version it wants.) > Alright, so this is an explanation why new binaries link to old > libraries. However, in this example, we're discussing a new binary > linking to a new library. > > I'm looking at the graphvizperl metadata: > > http://buildfarm.opencsw.org/pkgdb/srv4/79aaeb691e603c6f7d6f804fd62f82c0/ > > Here's an relevant excerpt: > > 'binaries': ['opt/csw/lib/graphviz/perl/libgv_perl.so'], > 'binaries_dump_info': [{'RPATH set': True, > 'RUNPATH RPATH the same': True, > 'RUNPATH set': True, > 'base_name': 'libgv_perl.so', > 'needed sonames': ('libm.so.1', > 'libpthread.so.1', > 'libgvc.so.6', > 'libxdot.so.4', > 'libpathplan.so.4', > 'libexpat.so.1', > 'libsocket.so.1', > 'libnsl.so.1', > 'libz.so.1', > 'libgraph.so.5', > 'libcdt.so.5', > 'libltdl.so.7', > 'libdl.so.1', > 'libperl.so', > 'libc.so.1', > 'libstdc++.so.6', > 'libgcc_s.so.1'), > 'path': 'opt/csw/lib/graphviz/perl/libgv_perl.so', > 'runpath': ('/opt/csw/gcc4/lib', > '/opt/csw/lib/$ISALIST', > '/opt/csw/lib', > '/opt/csw/lib'), > 'soname': 'libgv_perl.so'}], > > The binary /opt/csw/lib/graphviz/perl/libgv_perl.so needs libcdt.so.5, > so the CSWgraphvizperl package should declare a dependency on > CSWlibcdt5, isn't that so? Well, yes, I guess. I see there isn't an explicit dependency in the Makefile. But apparently GAR knows that there is one because the pkgcheck wanted me to add the "missing-dependency" override. Ah!, but you're saying I'm interpreting the cause of "missing" incorrectly.... I'm sure you're right ... I'll add the explicit RUNTIME_DEP_PKGS.. Thanks. > Maciej > _______________________________________________ > devel mailing list > devel@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/devel
