Menu
▾
▴
Re: [Fink-devel] [Fink-users] problem with emboss upgrade
|
From: Alexander H. <ale...@gm...> - 2010-01-18 15:28:48
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> There is a new version of emboss out, and I am working on packaging
> that. I kept the patch in that Dan added a while ago (see his post
> below), but now get the following error:
>
> /bin/sh ../../libtool --tag=CC --mode=link gcc -O2 -I/usr/X11/
> include -L/usr/X11/lib -I/usr/X11/include -I/System/Library/
> Frameworks/JavaVM.framework/Versions/1.5.0/Home -DHAVE_JAVA -I/System/
> Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/include -
> DNO_AUTH -version-info 6:2:0 -L/sw/lib -o libajaxg.la -rpath /sw/
> lib/EMBOSS ajgraph.lo ajhist.lo libajax.la ../plplot/libeplplot.la -
> lm -lgd -lpng -lz -lm
> libtool: link: cannot find the library `libajax.la' or unhandled
> argument `libajax.la'
> make[2]: *** [libajaxg.la] Error 1
> make[1]: *** [all-recursive] Error 1
>
> I wonder if thtis has to do with the recently introduced version of
> dpkg that removes .la files from /sw ? If so, has the patch become
> moot, and can I remove it? It builds fine without the patch, but that
> was also the case before the patch was created.
>
The dpkg update doesn't remove the .la files; it edits them. Do you
> I do get tons of these lines, but they have always been there, and
> it's only a warning:
>
> libtool: install: warning: `../nucleus/libnucleus.la' has not been
> installed in `/sw/lib/EMBOSS'
>
>
> Finally, I get this during validation:
>
> Error: package contains the shared library
> /sw/lib/EMBOSS/libacd.6.dylib
> but the corresponding install_name and compatibility_version
> %p/lib/EMBOSS/libacd.6.dylib 7.0.0
> are not listed in the Shlibs field. See the packaging manual.
> Error: package contains the shared library
> /sw/lib/EMBOSS/libeexpat.1.dylib
> but the corresponding install_name and compatibility_version
> %p/lib/EMBOSS/libeexpat.1.dylib 3.0.0
> are not listed in the Shlibs field. See the packaging manual.
> Error: package contains the shared library
> /sw/lib/EMBOSS/libensembl.6.dylib
> but the corresponding install_name and compatibility_version
> %p/lib/EMBOSS/libensembl.6.dylib 7.0.0
> are not listed in the Shlibs field. See the packaging manual.
> Error: package contains the shared library
> /sw/lib/EMBOSS/libepcre.7.dylib
> but the corresponding install_name and compatibility_version
> %p/lib/EMBOSS/libepcre.7.dylib 8.0.0
> are not listed in the Shlibs field. See the packaging manual.
> Error: package contains the shared library
> /sw/lib/EMBOSS/libezlib.1.dylib
> but the corresponding install_name and compatibility_version
> %p/lib/EMBOSS/libezlib.1.dylib 3.0.0
> are not listed in the Shlibs field. See the packaging manual.
>
> These are new for this version of emboss. Would these all need their
> own splitoff field, just like libeplplot?
>
That's up to you. If upstream changes one library install_name but not
others then having separate splitoffs is convenient, but it's not
mandatory--the shlibs can be just one package containing multiple libraries.
>
> Thanks,
>
> - Koen.
>
>
>
>
> On Dec 6, 2009, at 12:45 PM, Daniel Macks wrote:
>
>> On Sun, Dec 06, 2009 at 10:41:15AM -0500, Koen van der Drift wrote:
>>> Moving this to fink-devel.
>>>
>>> I saw that Dan fixed this issue in cvs - thanks!
>>>
>>> So if I understand correctly, the problem was that I used %N-plplot6-
>>> shlibs instead of %N-plplot3-shlibs, is that correct?
>>
>> Right. The essence of the policy is that there must be a 1:1 mapping
>> of Shlibs filename entries and the Package name that contains them. If
>> that filename changes (for example, nucleus.5.dylib ->
>> nucleus.6.dylib) then the packagename must change
>> (emboss-nucleus5-shlibs -> emboss-nucleus6-shlibs). During the emboss
>> upgrade from version 5.x to 6.x, libeplplot.3.dylib kept its same
>> filename, but the packagename was changed emboss-plplot5-shlibs ->
>> emboss-plplot6-shlibs, which means those packages fight over who
>> supplies the file and other packages cannot specify a reliable Depends
>> entry if they need that file. Collision of runtime files among
>> multiple packages is bad.
>>
>> So the package-names of a shared library really have nothing to do
>> with the upstream source version, but only to do with the specific
>> library *file* they contain. For convenience, it's become a
>> best-practice to name the -shlibs package (and its matching -dev) to
>> contain the same versioning as the that library file. So (once I was
>> in "make it clean mode, given we already have some breakage" mode) I
>> used emboss-plplot3-shlibs as the one new consistent place for
>> libplplot.3.dylib, just like the libnucleus filename number matches
>> for *its* package, etc.
>>
>> This is the change we had discussed and I finally did in the early
>> days of emboss, leading to the DescPort note:
>>
>> dmacks overhauled splitoff layout so that lib versions can float
>> against each other
>>
>>> But I am a bit unsure about the changes that were made in the patch
>>> file, what are those for?
>>
>> The .patch change is the other DescPort note, a change that got lost
>> in some release since I had implemented it:
>>
>> dmacks added explicit linking to libs that supply symbols used by
>> the shared libraries here. This prevents things that link against
>> the shared libraries from having to know to pass additional flags
>> when the linker requires all symbols be defined.
>>
>> It's an upstream bug that "probably" has no user-visible effect. But
>> if it does, the whole fink support team will spend days trying to sort
>> it out and passing the blame all around. In essence, libeplplot uses
>> libgd but does not use -lgd when being compiled and does not publish
>> this information ("need to use libgd when you use libeplplot") in a
>> useable way. That means any other package that ever wants to use
>> libeplplot must somehow magically know to load libgd first, or else
>> suffer a compile-time or run-time error. So I added -lgd. Same for a
>> few other of these "missing links".
>>
>> dan
>>
>> --
>> Daniel Macks
>> dm...@ne...
>> http://www.netspace.org/~dmacks
>>
>>
>>
- --
Alexander Hansen
Fink User Liaison
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktUfiIACgkQB8UpO3rKjQ/UfACeKh26g9jk8e9IAN9qg0RXKd/T
hrgAn0aKee1f2vmm7+duzAUEnGnVOzWR
=saQu
-----END PGP SIGNATURE-----
|