-----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
>> dma...@netspace.org
>> 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-----
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
