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.
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?
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
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> 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
------------------------------------------------------------------------------
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
