Mail Archives: cygwin-apps/2002/04/26/20:18:54
> In the second solution I have told about, using the regular implibs and decide
> on a per case base
> if ordinal linking or not.
>
> I'm thinking about creating to areas, an internal and an external.
> New releases of kdelibs and perhaps kdebase for example are build together. So
> ordinal linking is not problem. -> internal area. Any other app may
> be linked by name -> external area.
If there are some rules, I think it is possible to manage this stuff.
1. Each KDE major release 2, 3 is to see as a single
release with a fixed ordinal linking schema.
This is archived by the kde-team, who said,
that the kdelibs api is fixed for each major release
except some enhancements, which are added.
2. kde packages are arranged into two groups, identified by
the linking schema (ordinal or named)
3. packages, which belongs to the ordinal group needs special
attention on basic libs updates.
4. packages, which belongs to the named group are less affected
by updated basic libs. Relinking is only need by a major release
change.
5. For each KDE major release the used ld release is fixed,
except of updates not affecting the bfd/ld binary layout.
Otherwise all packages of the ordinal group has to be relinked
and released.
6. The packages of the ordinal group (and some of the named group)
are maintained by the kde-cygwin team.
7. If an external one likes to maintain a package of the ordinal group
he is responsible to follow topic 5.
8. Currently the following package belongs to the ordinal group:
kdelibs, kdebase, kdevelop
9. basic library which should not be referenced ordinal, must not
have import libs with ordinals.
(This speeks against using ordinal in importlibs by default)
Ld rules:
1. By default ordinal linking is disabled
2. Add an ld option to enable ordinal linking.
As ordinal the hint number is used. (Could this have any unknown side effect
??)
ordinal = hint number + 1.
How should such an option be named ?
Any comments ?
Ralf
- Raw text -