[gentoo-project] ABI deps and DEPEND labelling

[gentoo-project] ABI deps and DEPEND labelling

[Steve Long]

Posting to project as I think this stuff needs input from users as well as
devs. (Many users have a lot of experience with embedded dev and ABI
quirks.)
Flameeyes posted here about ABI deps:
http://blog.flameeyes.eu/articles/2008/08/18/same-abi-and-any-abi-dependencies
..which reminded me a lot of:
http://bugs.gentoo.org/show_bug.cgi?id=201499

Not really fussed about how it's resolved, so long as we get some sort of
correct link dependency information (which compile-against is not.) OFC
that probably means we'll never get correct LDEPENDs but such is life ;)

What do others reckon about resolving ABI stuff, especially for cross-dev
and multi-lib/testing?

Re: [gentoo-project] ABI deps and DEPEND labelling

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Tue, 19 Aug 2008 21:35:35 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Posting to project as I think this stuff needs input from users as
> well as devs. (Many users have a lot of experience with embedded dev
> and ABI quirks.)
> Flameeyes posted here about ABI deps:
> http://blog.flameeyes.eu/articles/2008/08/18/same-abi-and-any-abi-dependencies
> ..which reminded me a lot of:
> http://bugs.gentoo.org/show_bug.cgi?id=201499
> 
> Not really fussed about how it's resolved, so long as we get some
> sort of correct link dependency information (which compile-against is
> not.) OFC that probably means we'll never get correct LDEPENDs but
> such is life ;)
> 
> What do others reckon about resolving ABI stuff, especially for
> cross-dev and multi-lib/testing?

You might find http://kloeri.livejournal.com/6771.html useful too.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-project] Re: ABI deps and DEPEND labelling

[Steve Long]

Ciaran McCreesh wrote:

> On Tue, 19 Aug 2008 21:35:35 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Posting to project as I think this stuff needs input from users as
>> well as devs. (Many users have a lot of experience with embedded dev
>> and ABI quirks.)
>> Flameeyes posted here about ABI deps:
>>
http://blog.flameeyes.eu/articles/2008/08/18/same-abi-and-any-abi-dependencies
>> ..which reminded me a lot of:
>> http://bugs.gentoo.org/show_bug.cgi?id=201499
>> 
>> Not really fussed about how it's resolved, so long as we get some
>> sort of correct link dependency information (which compile-against is
>> not.) OFC that probably means we'll never get correct LDEPENDs but
>> such is life ;)
>> 
>> What do others reckon about resolving ABI stuff, especially for
>> cross-dev and multi-lib/testing?
> 
> You might find http://kloeri.livejournal.com/6771.html useful too.
> 
Actually I found it depressing; you'll be wanting credit for readelf next..

http://git.exherbo.org/?p=exherbo.git;a=tree;f=scratch/multilib was a more
useful link, from which I got this:

 * econf now looks in ${S} for a configure script, as well as . and 
   ${ECONF_SOURCE}.
 * extra variables: ABI_CLASSES="C python ruby", for example, and C_ABIS,
   python_ABIS, ruby_ABIS. Also C_ABI, python_ABI, ruby_ABI for primary ABI
in
   each class.
 * additional functions: switch_abi_env, get_abi_var, with_all_abis

I recommend Gentoo people look at the notes file in the above dir.

One thing that puzzles me is I never see .so versioning mentioned, eg
libc.so.5 vs .6 linking to latest providing specified ABI.

Re: [gentoo-project] Re: ABI deps and DEPEND labelling

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Thu, 21 Aug 2008 16:54:32 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > You might find http://kloeri.livejournal.com/6771.html useful too.
> > 
> Actually I found it depressing; you'll be wanting credit for readelf
> next..

I'm not quite sure how you got from Diego rejecting helpful comments
because they describe a solution thought out by the wrong people to
that...

> One thing that puzzles me is I never see .so versioning mentioned, eg
> libc.so.5 vs .6 linking to latest providing specified ABI.

Unix already has mechanisms for dealing with that. All the package
manager needs to make use of that is := slot dependencies, which you
can find documented in PMS for kdebuild-1. But since I invented them,
I'm looking forward to see what reason you can cook up for disliking it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-project] Re: Re: ABI deps and DEPEND labelling

[Steve Long]

Ciaran McCreesh wrote:

> On Thu, 21 Aug 2008 16:54:32 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
 
>> One thing that puzzles me is I never see .so versioning mentioned, eg
>> libc.so.5 vs .6 linking to latest providing specified ABI.
> 
> Unix already has mechanisms for dealing with that.

Yes, that was my point.

> All the package 
> manager needs to make use of that is := slot dependencies, which you
> can find documented in PMS for kdebuild-1. But since I invented them,
> I'm looking forward to see what reason you can cook up for disliking it.
>
Fwiw I liked the := dep specification, just like I liked labelled deps. I
don't see those as 'inventions' ofc, since they merely duplicate what
others have been doing for years, but feel free to think of yourself as the
great innovator, toiling away in your lab, misunderstood by the unwashed
masses (one day they'll be sorry..) And you wonder that I considered your
prior post some sort of claim?

/me suddenly understands why so many Gentoo devs won't use gmane.

Re: [gentoo-project] ABI deps and DEPEND labelling

[David Leverton]

On Tuesday 19 August 2008 21:35:35 Steve Long wrote:
> Not really fussed about how it's resolved, so long as we get some sort of
> correct link dependency information (which compile-against is not.)

compile-against is designed mainly for packages that include each-other's 
headers, nothing to do with linking.  For example, some libX11 headers 
include xproto headers.  If a given package only contains a reference, say, 
<X11/Xlib.h>, and not anything from xproto, then it should only build-depend 
on libX11, but xproto still needs to be present at compile-time.  The only 
way to represent that currently is by making libX11 RDEPEND on xproto, 
meaning "libX11 is not fully-functional unless xproto is installed", but 
embedded people and the like would prefer something more fine-grained, 
effectively splitting the idea of "fully-functional" into "fully-functional 
at runtime" and "fully-functional at build-time".

What exactly do you mean by "link dependency information"?  How would you like 
the package manager treat a "link" dependency differently from any other 
build dependency?

[gentoo-project] Re: ABI deps and DEPEND labelling

[Steve Long]

David Leverton wrote:

> On Tuesday 19 August 2008 21:35:35 Steve Long wrote:
>> Not really fussed about how it's resolved, so long as we get some sort of
>> correct link dependency information (which compile-against is not.)
> 
> compile-against is designed mainly for packages that include each-other's
> headers, nothing to do with linking.  For example, some libX11 headers
> include xproto headers.  If a given package only contains a reference,
> say, <X11/Xlib.h>, and not anything from xproto, then it should only
> build-depend
> on libX11, but xproto still needs to be present at compile-time.  The only
> way to represent that currently is by making libX11 RDEPEND on xproto,
> meaning "libX11 is not fully-functional unless xproto is installed", but
> embedded people and the like would prefer something more fine-grained,
> effectively splitting the idea of "fully-functional" into
> "fully-functional at runtime" and "fully-functional at build-time".
>
Cool, that makes sense.
 
> What exactly do you mean by "link dependency information"?  How would you
> like the package manager treat a "link" dependency differently from any
> other build dependency?

I mean the dependency between the package in your example and libX11, or
between libX11 and xproto: what the programmer writes as a dependency in
the code. In certain cases the dependency does not actually matter (opaque
types) but it usually does, especially with C++. compile-against seems to
be derived from that information.

An ldepend would necessarily be a build-time depend. It would not
necessarily be a run-time depend (eg for plugins) although most pkgs
building from src with a USE flag pulling in the ldepend would rdepend on
the same pkg, if the flag is in effect at install time. OFC that's where
the soft dependencies (suggest, recommend) come into play.