| 1 |
On Friday 24 March 2006 12:33, tvali wrote: |
| 2 |
> |
| 3 |
> I meant headers as .h or .hpp files, which contain function headers. |
| 4 |
> They're needed, but they are in many cases, included in pack which |
| 5 |
> uses them, even if that means putting some .h's into all libs. |
| 6 |
|
| 7 |
Headers are in the linux/unix world normally not included with the |
| 8 |
packages that use them, but provided by the packages that the libraries |
| 9 |
come from. |
| 10 |
> |
| 11 |
> Cant understand it. Do the *headers* change so much through versions? |
| 12 |
> Is there no backward-compability in so many cases? |
| 13 |
|
| 14 |
Headers only provide information to the compiler on what libraries look |
| 15 |
like. Once two packages (A lib) and (B another lib that uses A) are |
| 16 |
compiled, the headers are irrellevant. The only exception is if one wants |
| 17 |
to compile an application/library C that depends on B. In that case it |
| 18 |
needs the headers of the library provided by package B. IFF those headers |
| 19 |
depend on the headers of package A, package C indirectly depends on them |
| 20 |
too, and they must be available. Otherwise (if B does not "expose" A), |
| 21 |
package C can compile without package A headers being present. |
| 22 |
|
| 23 |
Compatibility only lives in libraries. In unix, libraries have "sonames" |
| 24 |
that distinguish libraries with different interfaces. While different |
| 25 |
sonames are not compatible (but can coexist), libraries with the same |
| 26 |
soname are normally backward compatible. That means that you can replace |
| 27 |
a library X with a library Y with the same soname and a higher version. |
| 28 |
One can not necesarilly however replace it with a library Z with a lower |
| 29 |
version. That would be called forward compatibility which is normally not |
| 30 |
guaranteed (It may work, it may not work, or it may seem to work until |
| 31 |
you put all your mission critical data in it and destroy the other |
| 32 |
copies). |
| 33 |
|
| 34 |
Paul |
| 35 |
|
| 36 |
ps. |
| 37 |
|
| 38 |
> Theory is when you know something, but it doesn't work. Practice is |
| 39 |
> when something works, but you don't know why. Programmers combine |
| 40 |
> theory and practice: Nothing works and they don't know why. |
| 41 |
|
| 42 |
Practice without theory is when something seems to work. Until you change |
| 43 |
the environment, after which things fail spectecularly. |
| 44 |
|
| 45 |
-- |
| 46 |
Paul de Vrieze |
| 47 |
Gentoo Developer |
| 48 |
Mail: pauldv@g.o |
| 49 |
Homepage: http://www.devrieze.net |
Archives