Re: [gentoo-portage-dev] DB and binary dependency

[tvali]

On 24/03/06, Paul de Vrieze <pauldv@g.o> wrote:
> On Friday 24 March 2006 12:40, tvali wrote:
> >
> > Interface can be made somewhat automatically checkable.
> >
> > For example:
> > void a(int);
> > void b(int, int);
> > void b(int, char);
> >
> > Is compatible with:
> > void a(int);
> > void b(int, int);
> >
> Unfortunately, your wrong. This only makes sure that you have the right
> slots to put your squares, triangles and circles in. It does not say that
> b(int,int) from the first lib actually does the same thing as b(int,int)
> from the second library.

Sorry i thought about it for a moment, then left out later as broken
design cases didnt seems so important. Versioning of distinct
functions would be good, anyway not automatic.

> To make it worse, suppose that header file 1 defines the following macro:
> #define c(x,y) { int A = x; int B = y; if (A<B) { b(A,B); } else
> { b(B,A); }
>
> And header file 2 defines the following macro
> #define c(x,y) { int A = x; int B = y; if (A>B) { b(A,B); } else
> { b(B,A); }
>
> And the semantics of B are such that one is supposed to use c(x,y) to call
> b, and b1 accordingly expects the first argument to be smaller, and b2
> expects the second one to be smaller. On the source level, this macro
> makes it transparent. The libraries, although they may seem different,
> are incompatible. While they implement the same source interface, they do
> NOT implement the same binary interface. On a binary (read compiled)
> level, they can not be exchanged for eachother.
>
> While the above example is clearly broken design, this does happen enough
> in actual libraries in way more subtle ways. And that is disregarding the
> fact that the linux/elf ABI does not include argument lists in symbol
> linking. As such b(int,char) is indistinguishable from b(int,int). To
> overcome this C++ uses name mangling which creates names based on the
> signature.

Ok, assuming broken design it's harder. Anyway, how would binary deps
solve this? This seems to be humans work in all cases.

> > And this can be checked automatically - real header must have all
> > headings that interface describes. Microsoft has actually done good
> > work in C# on that topic -- first place where i saw something like
> > that after thinking about it myself :) This MS version is feature of a
> > language, of course, not a feature of compiler. Anyway, that might
> > give an idea.
>
> There is a reason that MS implements it on the language level, in C#. It
> is impossible to do while keeping the (admittedly extremely poor)
> semantics of C and C++. Unfortunately the linux ABI (Application Binary
> Interface) is based on C. As such one has to take C into account.

Thats true that C# has much more clearness in it's language about what is what.

Anyway, as .h files have become as well as standard, you may show in
code as well as in bin, which functions are needed.

Is there any advantage of bin dep over code dep is a question for me
..some here suggest that there is, i think that everything can be done
as well with code deps.

> > I'm actually sure that this all can be calculated up from sourcecode
> > and bindep would be after that a check if cpu didnt calculate
> > something wrong :P Another question, how difficult it is and is it
> > worth the time.
>
> Perhaps you should read up your knowledge of the C language. After you
> found that the C language is a mess, try C++, it makes things worse.
> After that's finished take a look at solving this problem for ALL
> languages.

I actually know c++, but dont know c. Anyway, what i mean is that if
you have .h files, you may make up automatic check if interfaces fit
each other. I have to think about if c++ is a mess :)

> Automatic source analysis for dependency calculation is a dead end. Even
> if you manage to find the proper interfaces (oops, the package had it's
> own gl.h instead of using the system one), you don't know anything about
> the semantics of those interfaces. Two things with the same name may very
> well have very different behaviours.

I think it should be solved with:
// system's header
#include <...>
// own header
#include "..."

But, yes, not in all cases.

Ok -- i agree that there are several problems, which have to be solved
before taking this topic up again and that they are possibly
unsolvable in many cases and possibly too much work in many others.

> Paul
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@g.o
> Homepage: http://www.devrieze.net
>
>
>


--
tvali

If I had eight hours to chop down a tree, I'd spend six sharpening my
axe. -Abraham Lincoln

http://www.kuro5hin.org/story/2005/1/28/32622/4244

-- 
gentoo-portage-dev@g.o mailing list