[csw-devel] SF.net SVN: gar:[14697] csw/mgar/pkg/graphviz/trunk/Makefile

[John Ellson]

On 06/04/2011 02:42 AM, Maciej Bliziński wrote:
> 2011/6/3 John Ellson <ellson at 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 at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/devel