DE69621381T2

DE69621381T2 - Verfahren und Vorrichtung zur internen Versionsbildung von Objekten unter Verwendung einer Datei

Info

Publication number: DE69621381T2
Application number: DE69621381T
Authority: DE
Inventors: Rodrick I. Evans; Robert A. Gingell
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-07-06
Filing date: 1996-06-27
Publication date: 2003-05-15
Anticipated expiration: 2016-06-28
Also published as: EP0752647A1; JPH09152961A; US5805899A; EP0752647B1; DE69621381D1

Description

Diese Erfindung betrifft ein Verfahren und eine Vorrichtung zum Verknüpfen von Softwareprogrammen und insbesondere ein Verfahren und eine Vorrichtung zur Bereitstellung eines dynamischen Verknüpfungssystems, um Änderungen in aufeinanderfolgenden Versionen eines Softwareprogramms zu verwalten.
Die Softwareentwicklung ist ein laufender Prozeß. Eine erste Version einer Software kann zu dem Zeitpunkt, zu dem die Software geschrieben wird, für eine Aufgabe angemessen sein, kann jedoch, wenn die Zeit vergeht, eine Verbesserung erfordern und zusätzliche Merkmale werden hinzugefügt. Der Softwareentwicklungsprozeß ist besonders problematisch, wenn eine Softwareanwendung mit gemeinsam genutzten Objekten (auch "Bibliotheken" genannt) verknüpft. Wenn ein gemeinsam genutztes Objekt aktualisiert oder verändert wird, wird die Schnittstelle zum gemeinsam genutzten Objekt häufig ebenso aktualisiert oder verändert. Außerdem ist es häufig der Fall, daß, selbst wenn sich die Schnittstelle zu einem gemeinsam genutzten Objekt nicht ändert, ein gewisser Teil der vom gemeinsam genutzten Objekt durchgeführten Funktion sich ändert.
Einige herkömmlichen Systeme verknüpfen dynamisch Anwendungssoftwareprogramme zur Laufzeit mit gemeinsam genutzten Objekten. In solchen Systemen muß ein Anwendungssoftwareprogramm, das auf ein gemeinsam genutztes Objekt zugreift, jedesmal, wenn eine neue Version des gemeinsam genutzten Objekts veröffentlicht wird, sorgfältig geprüft werden. Das Anwendungssoftwareprogramm muß geprüft werden, um festzustellen, daß es keine Schnittstelle zum gemeinsam genutzten Objekt verwendet, die in der neuen Version des gemeinsam genutzten Objekts nicht mehr existiert. Das Anwendungssoftwareprogramm muß auch geprüft werden, um festzustellen, daß sich die Operation des gemeinsam genutzten Objekts nicht geändert hat (selbst wenn die Schnittstelle zum gemeinsam genutzten Objekt gleich bleibt).
Üblicherweise wird diese Prüfung häufig von einem Menschen durchgeführt. Durch falsch angepaßte Schnittstellen verursachte Fehler werden häufig nur während der Ausführung des Anwendungssoftwareprogramms entdeckt, wenn eine Schnittstellenfalschanpassung gefunden wird oder wenn ein gemeinsam genutztes Objekt nicht in der Weise funktioniert, in der es gewöhnlich funktionierte. Was erforderlich ist, ist eine Art und Weise zur Feststellung, welche Version eines gemeinsam genutzten Objekts ein spezielles Anwendungssoftwareprogramm "erwartet" zu verknüpfen, und eine Art und Weise zum Prüfen, ob die erwartete Version des gemeinsam genutzten Objekts während der dynamischen Verknüpfung zur Laufzeit vorhanden ist.
Üblicherweise wird der Dateiname des gemeinsam genutzten Objekts selbst für jede neue Version aktualisiert. Somit ist während der Verknüpfung nur eine neueste Version des gemeinsam genutzten Objekts vorhanden und die neueste Version weist einen vollständig anderen Dateinamen auf als eine ältere Version des Objekts. Es wäre erwünscht, die Umbenennung eines Objekts jedesmal, wenn eine neue Version des Objekts erzeugt wird, zu vermeiden.
Herkömmliche Systeme versuchen häufig, durch Veröffentlichen von Anwendungsprogrammen und gemeinsam genutzten Objekten (Bibliotheken) als "ganzes System" eine Versionsprüfung zu vermeiden, d. h. eine neue Anwendung wird mit allen ihren erforderlichen gemeinsam genutzten Objekten versandt, ungeachtet dessen, ob irgendeine Änderung zwischen Versionen der gemeinsam genutzten Objekte stattgefunden hat. Es wäre erwünscht, nur jene Teile des Systems verbessern zu können, die notwendig sind, um einer Änderung gerecht zu werden.
WO-A-94/25918 beschreibt ein Verfahren und eine Vorrichtung zum Vorsehen einer Versionsbildungsinformation in einem Softwareprogramm. In WO-A-94/25918 ist jedoch nicht offenbart, woher der Versionsname für den Versionsobjektcode stammt, wodurch kein Verfahren oder keine Einrichtung für eine Versionsverwaltung offenbart wird.
Die vorliegende Erfindung stellt ein Verfahren nach Anspruch 1 und eine Vorrichtung nach Anspruch 11 zum dynamischen Verknüpfen von Softwareprogrammen bereit. Die Erfindung stellt ein Versionsbildungssystem bereit, um Änderungen in aufeinanderfolgenden Versionen von Objekten, auf die von Anwendungssoftwareprogrammen zugegriffen wird, zu verfolgen. Die Erfindung prüft die vom Anwendungssoftwareprogramm verwendeten Schnittstellen, um auf Versionsobjekte zuzugreifen, und erkennt Versuche vom Anwendungssoftwareprogramm, auf eine ungültige Version des Versionsobjekts zuzugreifen. Die vorliegende Erfindung ermöglicht somit eine kontrollierte Entwicklung von Objekten, während zwischen Anwendungsprogrammen und Objekten eine Rückwärtskompatibilität aufrechterhalten wird.
Die Erfindung stellt ein Versionsbildungssystem bereit, das ermöglicht, daß Symbolschnittstellen und Implementierungsänderungen innerhalb eines Objekts gekennzeichnet werden. Zur Konstruktionszeit fügt ein Bindeeditor Daten zu einem Versionsobjekt hinzu, die alle verfügbaren Versionen des Objekts definieren (einen Versionsdefinitionsabschnitt und einen Versionssymbolabschnitt). Zur Konstruktionszeit fügt der Bindeeditor Daten zur Softwareanwendung hinzu, die die Versionsanforderungen der Anwendung definieren (einen Versionsabhängigkeitsabschnitt). Zur Laufzeit überprüft ein Läufzeit-Binderprogramm, daß die Anforderungen der Softwareanwendung der in den Objekten selbst gespeicherten Versionsdefinition entsprechen, d. h. daß das von der Softwareanwendung benötigte Versionsobjekt für das Laufzeit-Binderprogramm zur Verfügung steht.
Eine Version ist ein Name oder eine Bezeichnung, die in einem Objekt aufgezeichnet ist. Eine Version kann einem oder mehreren globalen Symbolen zugeordnet sein - in welchem Fall sie eine Symbolschnittstelle festlegt. Ansonsten kann eine Version einfach ein Hinweis auf eine Implementierungsänderung, d. h. auf eine Änderung, in der sich die Funktionalität eines Objekts ändert, aber keine neuen globalen Symbole definiert werden, sein. In diesem letzteren Fall wird die Version als "schwache" Version bezeichnet. Beim beschriebenen Ausführungsbeispiel der Erfindung werden die globalen Symbole und Versionsnamen, die jeder Version zugeordnet sind, in einer von einem Menschen erzeugten "Abbildungsdatei" festgelegt. Die Abbildungsdatei wird in den Bindeeditor zur Konstruktionszeit zusammen mit einem oder mehreren relativierbaren (kompilierten) Objekten eingegeben, um ein Versionsobjekt zu erzeugen. Standardgemäß wird zur Konstruktionszeit, wenn eine Anwendung mit einem Versionsobjekt, das eine Versionsbildungsinformation enthält, hinsichtlich der Verknüpfung aufbereitet wird, in der Anwendung eine Abhängigkeit zu jenen Versionen hergestellt, die die globalen Symbole enthalten, auf die von der Anwendung Bezug genommen wird. Außerdem wird eine "schwache" Abhängigkeit zu irgendwelchen schwachen Definitionen hergestellt.
Die vorliegende Erfindung ermöglicht die Vererbung von Versionsdefinitionen innerhalb eines Objekts. Versionen erben Versionen und somit können Symbolsätze kombiniert werden, um untereinander zusammenhängende Schnittstellendefinitionen zu erzeugen. Eine neue Version könnte beispielsweise alle der globalen Symbole einer älteren Version erben. Die vorliegende Erfindung kann die Sichtbarkeit der Versionen eines Objekts während einer Verknüpfungsaufbereitung kontrollieren, wobei sie tatsächlich jene Schnittstellen kontrolliert, die für das Anwendungsprogramm zur Verfügung stehen. Die vorliegende Erfindung kann auch das Anwendungssoftwareprogramm zwingen, daß es eine schwache Version eines Objekts erfordert.
Wie hierin beschrieben, ist die vorliegende Erfindung ein Verfahren zum Vorsehen einer Versionsbildungsinformation in einem Softwareprogramm mit den Schritten: Vorsehen eines ersten Objektcodes für ein erstes Softwareprogramm; Vorsehen einer Abbildungsdatei, die einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms zugeordnet ist; und Verknüpfen des ersten Objektcodes, so daß zum ersten Objektcode gemäß der Abbildungsdatei eine Information hinzugefügt wird, die den Versionsnamen der Version des ersten Softwareprogramms festlegt, um ein Versionsobjekt zu ergeben.
Wie hierin beschrieben, ist die vorliegende Erfindung eine Vorrichtung zum Vorsehen einer Versionsbildungsinformation in einem Softwareprogramm nach Anspruch 11.
Wie hierin beschrieben, ist die vorliegende Erfindung ein Computerprogrammprodukt nach Anspruch 17.
Verschiedene Vorteile der vorliegenden Erfindung werden genauer ersichtlich, wenn die folgenden ausführlichen Beschreibungen der Erfindung in Verbindung mit den zugehörigen Zeichnungen gelesen werden.
Die Erfindung wird nun mit Bezug auf die zugehörigen Zeichnungen beschrieben, in denen gilt:
Fig. 1 ist ein Blockdiagramm eines erfindungsgemäßen Computersystems.
Fig. 2(a), 2(b) und 2(c) sind Diagramme, die Eingaben und Ausgaben eines Bindeeditorprogramms von Fig. 1 zur Konstruktionszeit zeigen.
Fig. 2(d) ist ein Diagramm, das Eingaben und Ausgaben eines Laufzeit-Binderprogramms von Fig. 1 zur Laufzeit zeigt.
Fig. 3(a) und 3(b) sind Ablaufpläne, die Schritte zeigen, die vom Bindeeditor von Fig. 2(a) durchgeführt werden, um einen Versionsdefinitionsabschnitt und einen Versionssymbolabschnitt zu einem Objekt hinzuzufügen.
Fig. 4 zeigt ein Format einer Abbildungsdatei von Fig. 2(a).
Fig. 5 zeigt eine Ausgabe des Bindeeditors von Fig. 2(a), die in einem Versionsobjekt enthalten ist.
Fig. 6 zeigt ein Format eines Versionsdefinitionsabschnitts von Fig. 5.
Fig. 7 zeigt ein Format eines Versionssymbolabschnitts von Fig. 5.
Fig. 8 ist ein Ablaufplan, der die Schritte zeigt, die vom Bindeeditor von Fig. 2(b) oder 2(c) durchgeführt werden, um einen Versionsabhängigkeitsabschnitt zu einem dynamischen ausführbaren Anwendungsprogramm hinzuzufügen.
Fig. 9 zeigt ein Format einer Abbildungsdatei von Fig. 2(c).
Fig. 10 zeigt eine Ausgabe des Bindeeditors von Fig. 2(b), die in einem dynamischen ausführbaren Anwendungsprogramm enthalten ist.
Fig. 11 zeigt ein Format eines Versionsabhängigkeitsabschnitts von Fig. 5 und 10.
Fig. 12 zeigt ein Format eines Kopfabschnitts von Fig. 6, 7 und 11.
Fig. 13 ist eine Auflistung von Werten in der Kopfzeile von Fig. 12.
Fig. 14 ist eine Auflistung von Werten in der Kopfzeile von Fig. 12.
Fig. 15 ist ein Ablaufplan von Schritten, die vom Laufzeit- Binderprogramm von Fig. 2(d) durchgeführt werden, um zu überprüfen, daß die Versionsanforderungen eines Anwendungsprogramms den Versionen entsprechen, die in einem Objekt vorliegen, das mit dem Anwendungsprogramm verknüpft wird.
Fig. 16 ist ein Beispiel eines Versionsdefinitionsabschnitts, der vom Bindeeditor zu einem Objekt hinzugefügt wird.
Fig. 17 ist ein Beispiel eines Versionssymbolabschnitts, der vom Bindeeditor zu einem Objekt hinzugefügt wird.
Fig. 18 ist ein Beispiel eines Versionsabhängigkeitsabschnitts, der zu einem oder beiden eines Versionsobjekts oder eines dynamischen ausführbaren Anwendungsprogramm vom Bindeeditor hinzugefügt werden kann.

AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Die folgende Beschreibung gilt für die derzeit als beste betrachtete Art zur Ausführung der Erfindung. Diese Beschreibung wird für den Zweck der Erläuterung der allgemeinen Prinzipien der Erfindung durchgeführt und ist nicht in einer begrenzenden Hinsicht aufzufassen.

1. Allgemeine Erörterung

Fig. 1 ist ein Blockdiagramm eines Computersystems 100 gemäß der vorliegenden Erfindung. Das Computersystem 100 umfaßt eine CPU 102, einen Speicher 104 und Eingabe/Ausgabe-Leitungen 106. Es ist für einen gewöhnlichen Fachmann selbstverständlich, daß das Computersystem 100 auch zahlreiche Elemente umfassen kann, die der Deutlichkeit halber in der Figur nicht dargestellt sind, wie z. B. Plattenlaufwerke, Tastaturen, Anzeigevorrichtungen, Netzwerkverbindungen, einen zusätzlichen Speicher, zusätzliche CPUs usw.
Der Speicher 104 umfaßt eine Bibliothek (libc) (auch gemeinsam genutztes Objekt genannt) 114, einen Quellencode 110 und einen relativierbaren (kompilierten) Code 112 des gemeinsam genutzten Objekts 114. Der Speicher 104 umfaßt ferner einen Quellencode 116 für ein Anwendungssoftwareprogramm, einen relativierbaren (kompilierten) Code 118 für die Anwendung 116 und einen dynamischen ausführbaren (verknüpften) Code 120 für die Anwendung 116. Der Speicher 104 umfaßt ferner eine Betriebssystem-(Kern)Software 122, Abbildungsdateien 130 und 132, einen Bindeeditor 124 und ein Laufzeit- Binderprogramm 126. Jedes des gemeinsam genutzten Objekts 114 und des dynamischen ausführbaren Objekts 120 wird vom Bindeeditor 124 erzeugt. Jedes des gemeinsam genutzten Objekts 114 und des ausführbaren Objekts 120 weist ein ausführbares Verknüpfungsformat (ELF) ähnlich dem ELF, das in "System V Application Binary Interface", dritte Ausgabe, veröffentlicht von Prentice Hall, Inc., definiert ist, auf.
Bei der vorliegenden Erfindung wurde jedoch das ELF-Format der Objekte 114 und 120 erweitert, so daß es zusätzliche Daten umfaßt, wie nachstehend beschrieben. Das gemeinsam genutzte Objekt 114 weist ein in Fig. 5 gezeigtes Format auf. Das dynamische ausführbare Objekt 120 weist ein in Fig. 10 gezeigtes Format auf. Das gemeinsam genutzte Objekt 114 umfaßt eine Versionsbildungsinformation (einen Versionsdefinitionsabschnitt) für jede Version des gemeinsam genutzten Objekts und eine Liste von allgemeinen Symbolen für jede Version (einen Versionssymbolabschnitt), wie nachstehend erörtert. Das gemeinsam genutzte Objekt 114 kann auch eine Information hinsichtlich Versionsabhängigkeiten (einen Versionsabhängigkeitsabschnitt) enthalten. Das ausführbare Objekt 120 enthält eine Information hinsichtlich Versionsabhängigkeiten (einen Versionsabhängigkeitsabschnitt), wie nachstehend erörtert. Ein üblicher Fachmann versteht, daß der Speicher 104 auch eine zusätzliche Information enthält, wie z. B. Anwendungsprogramme, Betriebssysteme, Daten usw., die der Deutlichkeit halber in der Figur nicht dargestellt sind.
Ein bevorzugtes Ausführungsbeispiel der Erfindung läuft unter dem Betriebssystem Solaris, Version 2.5. Solaris ist eine eingetragene Handelsmarke von Sun Microsystems, Inc. Unix ist eine eingetragene Handelsmarke in den Vereinigten Staaten und anderen Ländern, die ausschließlich durch X/OPEN, Ltd., lizenziert wird.
Fig. 2(a) ist ein Diagramm, das eine Eingabe und Ausgabe des Bindeeditors 124 von Fig. 1 zeigt. Fig. 2(a) zeigt die Erzeugung eines gemeinsam genutzten Versionsobjekts. Obwohl die folgende Erörterung die Versionsbildung von gemeinsam genutzten Objekten behandelt, kann die vorliegende Erfindung auch verwendet werden, um die Versionsbildung in dynamischen ausführbaren Objekten und in relativierbaren Objekten zu implementieren. Somit können diese Arten von Objekten auch einen Versionsdefinitionsabschnitt und einen Versionssymbolabschnitt enthalten. Der Bindeeditor 124 empfängt eine Eingabe von der Abbildungsdatei 130 und vom relativierbaren Objektcode 112 für ein gemeinsam genutztes Objekt und erzeugt eine Ausgabe des gemeinsam genutzten Objekts 114. Die Abbildungsdatei 130 legt die globalen Symbole und einen Versionsnamen für jede Version des gemeinsam genutzten Objekts fest. Beim beschriebenen Ausführungsbeispiel weist die Abbildungsdatei 130 vorzugsweise das Format von Fig. 4 auf und wird von einem Menschen erzeugt. Bei anderen Ausführungsbeispielen kann die Abbildungsdatei 130 vom Kompilierungssystem erzeugt werden.
Fig. 2(b) zeigt eine zusätzliche Eingabe und Ausgabe des Bindeeditors 124 von Fig. 1. Fig. 2(b) zeigt die Verknüpfungsaufbereitung eines Anwendungsprogramms mit dem gemeinsam genutzten Versionsobjekt von Fig. 2(a). Der Bindeeditor 124 empfängt als Eingabe das gemeinsam genutzte Versionsobjekt 114 und das relativierbare Objekt 118. Der Bindeeditor 124 verarbeitet das relativierbare Objekt 118 und das gemeinsam genutzte Objekt 114, um das dynamische ausführbare Objekt 120 zu erzeugen. Wie in Fig. 2(c) gezeigt, kann auch eine Abbildungsdatei 132 in diesem Schritt verwendet werden, um anzugeben, welche Versionen des Objekts 114 bei dieser Verknüpfungsprozedur zugelassen sind. Die Abbildungsdatei 132 weist vorzugsweise das Format von Fig. 9 auf und wird von einem Menschen erzeugt.
Wie in Fig. 2(d) gezeigt, überprüft zur Laufzeit ein Laufzeit-Binderprogramm 126, daß alle Versionen des gemeinsam genutzten Objekts 114, die vom dynamischen ausführbaren 120 benötigt werden, vorhanden sind. Wenn ja, erzeugt das Laufzeit-Binderprogramm 126 eine Prozeßdatei 122 und führt diese aus, um das dynamische ausführbare 120 auszuführen. Somit konstruiert der Bindeeditor 124 gemeinsam genutzte Versionsobjekte aus den relativierbaren Objekten und stellt fest, welche Versionen des gemeinsam genutzten Objekts von einem Anwendungsprogramm benötigt werden. Das Laufzeit-Binderprogramm 126 bildet die Objekte in seinem Speicher ab und verknüpft sie miteinander. Somit stellt das Laufzeit-Binderprogramm 126 einfach Objekte zusammen, wie vom Bindeeditor 124 angewiesen. Das Laufzeit- Binderprogramm 126 führt eine Kontrolle durch, um sicherzustellen, daß die Version des gemeinsam genutzten Objekts 114, die für das dynamische ausführbare 120 erforderlich ist, vorliegt. Wenn die korrekte Version nicht vorhanden ist, erzeugt das Laufzeit-Binderprogramm 126 einen Fehler.
Die folgenden Absätze erörtern Arten von Änderungen, die zwischen verschiedenen Versionen des gemeinsam genutzten Objekts 114 durchgeführt werden können. Im allgemeinen können diese Änderungen in zwei Gruppen kategorisiert werden: kompatible Aktualisierungen und inkompatible Aktualisierungen. Kompatible Aktualisierungen sind additiv, d. h. alle vorher verfügbaren globalen Symbole in der Schnittstelle zum gemeinsam genutzten Objekt 114 bleiben intakt. Ein Beispiel einer kompatiblen Aktualisierung ist das Hinzufügen eines globalen Symbols. Da keine Symbole von vorherigen Versionen entfernt wurden, sollte die Anwendungssoftware, die mit vorherigen Versionen verbindet, immer noch korrekt arbeiten. Inkompatible Aktualisierungen ändern die existierende Schnittstelle zum gemeinsam genutzten Objekt 114 in einer solchen Weise, daß existierende Anwendungen, die die Schnittstelle verwenden, versagen können oder sich falsch verhalten können. Beispiele von inkompatiblen Aktualisierungen umfassen: die Entfernung eines Symbols, das Hinzufügen eines Arguments zu einer Funktion, die Entfernung eines Arguments von einer Funktion und eine Änderung der Größe oder des Inhalts eines Arguments für eine Funktion. Fehlerfixierungen für das gemeinsam genutzte Objekt 114 können mit einer existierenden Schnittstelle kompatibel oder inkompatibel sein. Eine kompatible Fehlerfixierung kann beispielsweise lediglich die interne Funktion des gemeinsam genutzten Objekts 114 ändern, während die vorher festgelegte Schnittstelle beibehalten wird. Eine inkompatible Fehlerfixierung kann die Änderung der Schnittstelle zum gemeinsam genutzten Objekt 114 erfordern.

2. Erzeugung einer Versionsbildungsinformation zur Konstruktionszeit

Die Vorangehenden Absätze sehen eine allgemeine Erörterung der zur Konstruktionszeit und zur Laufzeit durchgeführten Prozesse zum Implementieren einer Versionsbildung gemäß der vorliegenden Erfindung vor. Die folgenden Absätze erörtern, wie der Bindeeditor 124 eine Versionsbildungsinformation zu einem gemeinsam genutzten Objekt und zum Anwendungsprogramm hinzufügt.

a. Erzeugen einer Versionsdefinition für Versionsobjekte zur Konstruktionszeit

Bei einem bevorzugten Ausführungsbeispiel steuert der Bindeeditor 124 die Versionsbildung für gemeinsam genutzte Objekte gemäß einer Versionsrichtinformation in der Abbildungsdatei 130, wie nachstehend erörtert. Die Abbildungsdatei 130 wird vorzugsweise von einem Menschen erzeugt, könnte jedoch auch von einer Software wie z. B. einem Kompilierungssystem erzeugt werden.
Fig. 3(a) und 3(b) sind Ablaufpläne, die Schritte zeigen, die vom Bindeeditor 124 von Fig. 2(a) durchgeführt werden. Diese Schritte sind ein Teil der Schritte, die durchgeführt werden, um ein Versionsobjekt wie z. B. das gemeinsam genutzte Objekt 114, zu erzeugen. Ein üblicher Fachmann wird verstehen, daß die Schritte von Fig. 3(a) und 3(b) (sowie die Schritte von Fig. 8) von der CPU 102 von Fig. 1 durchgeführt werden, die Befehle des Bindeeditors 124 ausführt, die im Speicher 104 gespeichert sind, und Datenstrukturen verwendet, die z. B. im Speicher 104 gespeichert sind.
Wie in Schritt 302 dargestellt, werden die Schritte von Fig. 3(a) vorzugsweise eingeleitet, wenn der Bindeeditor 124 mit einer -G-Option auf einer Befehlsleitung aufgerufen wird. Die -G-Option gibt an, daß der Bindeeditor 124 ein gemeinsam genutztes Objekt (im Gegensatz zu einem dynamischen ausführbaren Objekt) erzeugen sollte. Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird der Bindeeditor 124 auch mit der -M-Option aufgerufen, die angibt, daß die Abbildungsdatei 130 als Quelle für "Versionsdefinitions-Betriebsanweisungen" verwendet werden sollte. Das Beispiel von Fig. 2(a) zeigt die Erzeugung eines gemeinsam genutzten Objekts, aber die vorliegende Erfindung kann auch verwendet werden, um relativierbare Versionsobjekte und dynamische ausführbare Versionsobjekte zu erzeugen.
Das folgende Beispiel umfaßt keine ausführliche Erläuterung von Unix-Befehlen, die in den Beispielen verwendet werden (cat, cc, pvs, ld). Unix-Befehle werden im Solaris- Bedienungshandbuch erörtert, welches von Sun Microsystems erhältlich ist. Die folgenden Absätze erörtern Beispiele eines Quellencodes 110 eines gemeinsam genutzten Objekts und einer Abbildungsdatei 130. Tabelle 1 zeigt den Quellencode 110 für vier Quellendateien ("foo.c", "data.c", "bar1,c" und "bar2.c"), die in der Programmiersprache C geschrieben sind. Die Quellendateien bilden gemeinsam ein gemeinsam genutztes Objekt. Die Abbildungsdatei von Tabelle 2 definiert globale Schnittstellen für verschiedene Versionen des gemeinsam genutzten Objekts. Diese Dateien werden kompiliert, um das relativierbare Objekt 112 von Fig. 1 zu bilden. Anschließend erzeugt der Bindeeditor 124 ein gemeinsam genutztes Versionsobjekt 114 gemäß der Abbildungsdatei 130, wie nachstehend beschrieben. TABELLE 1 (Quellencode für gemeinsam genutztes Objekt)

TABELLE 2 (Abbildungsdatei, die Versionen von gemeinsam genutztem Objekt definiert)

Fig. 4 zeigt ein Format einer Abbildungsdatei 130 unter Verwendung des Backus-Naur-Formats. Im Backus-Naur-Format geben eckige Klammern ("[" und "]") ein wahlfreies Element an. Somit ist beispielsweise in Fig. 4 "[Versionsname]" ein wahlfreies Element des Abbildungsdateiformats.
Das gemeinsam genutzte Objekt 114 sieht globale Symbole vor, mit denen andere Objekte, wie z. B. das dynamische ausführbare 120, zur Laufzeit verknüpfen können. Diese globalen Symbole sind in der Abbildungsdatei 130 festgelegt und beschreiben eine binäre Anwendungsschnittstelle (ABI) des gemeinsam genutzten Objekts 114. Während der Lebensdauer des gemeinsam genutzten Objekts 114 kann sich die Schnittstelle eines Objekts aufgrund des Hinzufügens oder des Löschens von globalen Symbolen ändern. Außerdem kann die Entwicklung des gemeinsam genutzten Objekts 114 interne Implementierungsänderungen am gemeinsam genutzten Objekt 114 beinhalten, die die globalen Symbole der Schnittstelle nicht beeinflussen.
Tabelle 2 zeigt ein Beispiel der Abbildungsdatei 130. In Tabelle 2 enthält die Abbildungsdatei 130 Versionsdefinitionen für die Versionen SUNW.1.1, SUNW.1.2, SUNW.1.2.1, SUNW.1.3a, SUNW.1.3b und SUNW.1.4 des gemeinsam genutzten Objekts 114. Die Versionsdefinitionen umfassen alle Versionen (und ihre globalen Symbole), die jemals für das gemeinsam genutzte Objekt 114 definiert wurden. In dem Beispiel ist SUNW.1.1 eine Version des gemeinsam genutzten Objekts 114, die in der Release X (Veröffentlichung X) enthalten ist; SUNW.1.2 ist eine Version des gemeinsam genutzten Objekts 114, die in der Release X+1 enthalten ist, die die globalen Symbole der Version SUNW.1.1 erbt.
SUNW.1.2.1 ist eine Version des gemeinsam genutzten Objekts 114, die in der Release X+2 enthalten ist, die die globalen Symbole der Version SUNW.1.2 erbt. Man beachte, daß SUNW.1.2.1 eine "schwache" Version ist, da sie keine neuen globalen Symbole enthält. Diese Version gibt eine Änderung der "Implementierung" im gemeinsam genutzten Objekt an. Die anderen Versionen geben Änderungen der "Schnittstelle" an. SUNW.1.2.1 stellt eine Version mit Änderungen an der Funktion des gemeinsam genutzten Objekts, aber nicht an seiner Schnittstelle dar.
SUNW.1.3a ist eine Version des gemeinsam genutzten Objekts 114, die in der Release X+3 enthalten ist, die die globalen Symbole der Version SUNW.1.2 erbt. SUNW.1.3b ist auch ein Teil der Release X+3 und erbt auch die globalen Symbole der Version SUNW.1.2. Die Version SUNW.1.3b definiert jedoch das globale Symbole "bar2" anstelle des globalen Symbols "bar1", das in der Version SUNW.1.3a definiert ist. Die Version SUNW.1.4 definiert eine globales Symbol "bar3" und erbt auch die globalen Symbole von sowohl SUNW.1.3a als auch SUNW.1.3b.
In dem Beispiel von Tabelle 2 ist das Symbol "foo1" das einzige globale Symbol, das in der allgemeinen Schnittstelle der Version SUNW.1.1 definiert ist. Die spezielle Betriebsanweisung "automatische Reduktion" ("*") bewirkt, daß die Reduktion aller anderen globalen Symbole des gemeinsam genutzten Objekts einen lokalen Gültigkeitsbereich aufweist, so daß sie kein Teil der Schnittstelle zum gemeinsam genutzten Objekt sind. Somit besteht die allgemeine Schnittstelle des gemeinsam genutzten Objekts 114 für die Version SUNW.1.1 aus der internen Versionsdefinition für diese Version, die dem globalen Symbol "foo1" zugeordnet ist.
Tabelle 3 zeigt Unix-Befehle, um die Quellencodedateien von Tabelle 1 zu kompilieren und zu verknüpfen. Die Objektcodedateien "foo.o", "data.o", "bar1.o" und "bar2.o" (nicht dargestellt) werden unter Verwendung der Abbildungsdatei 130 von Tabelle 2 dynamisch verknüpft, um ein gemeinsam genutztes Objekt 114 zu erzeugen, das "libfoo.so.1" genannt wird. (In diesem Beispiel ruft der cc-Kompilierer automatisch den ld(1) Bindeeditor 124 auf.) Die "-G"-Option auf der Befehlsleitung zeigt an, daß der Bindeeditor 124 ein gemeinsam genutztes Objekt und kein ausführbares Objekt erzeugen sollte. Der "ln"-Befehl erzeugt einen Namen einer "Kompilierungsumgebung", der für die "-1"-Option von ld(1) geeignet ist. Der Unix-Befehl "pvs" druckt die Versionsbildungsinformation für das vom Bindeeditor 124 erzeugte gemeinsam genutzte Objekt und die für jede Version verfügbaren globalen Symbole aus.
Wie in Tabelle 3 gezeigt, wird auch eine Definition einer "Basisversion" für das Objekt erzeugt. Diese Basisversion wird unter Verwendung des Namens des gemeinsam genutzten Objekts selbst (z. B. "libfoo.so.1") definiert und wird verwendet, um irgendwelche reservierten Symbole, die vom Bindeeditor 124 erzeugt werden, dem Objekt zuzuordnen. In dem Beispiel von Tabelle 3 wird beispielsweise eine Basisversionsdefinition für das gemeinsam genutzte Objekt libfool.so.1 erzeugt, die reservierte globale Symbole enthält, die vom Binderprogramm erzeugt werden (z. B. _etext, _edata, end, _DYNAMIC, _PROCEDURE_LINKAGE_TABLE_ und GLOBAL_OFFSET_TABLE).

TABELLE 3 (Erzeugen eines gemeinsam genutzten Versionsobjekts (zur Konstruktionszeit) und Anzeigen der Versionsinformation)

Wenn man zu Fig. 3(a) zurückkehrt, und wenn (in Schritt 304) ein Versionsname in der Abbildungsdatei 130 erscheint, erzeugt der Bindeeditor 124 mehrere Abschnitte innerhalb des gemeinsam genutzten Objekts 114, die sich spezifisch auf die Versionsbildung beziehen. Die speziellen Abschnitte sind in Fig. 5 gezeigt und umfassen einen Versionsdefinitionsabschnitt 506, einen Versionssymbolabschnitt 508 und einen wahlfreien Versionsabhängigkeitsabschnitt 510. Die folgenden Absätze erörtern die Erzeugung und Verwendung dieser Abschnitte.
Fig. 6 zeigt ein Format des Versionsdefinitionsabschnitts 506 des gemeinsam genutzten Versionsobjekts 114. Fig. 16 zeigt ein Beispiel eines Versionsdefinitionsabschnitts auf der Basis der Tabellen 1-3. Der Abschnitt umfaßt eine Abschnittskopfzeile 602 (siehe Fig. 12), eine Strukturversion 604, Kennzeichen 606, einen Versionsdefinitionsindex 610, einen Zählwert 612, einen Hash-Wert 614, einen Hilfswert 616, einen Zeiger 618 auf die nächste Versionsdefinition, den Namen der Version selbst 620 und Null oder mehr Namen von Versionen, Von denen die definierte Version die globalen Symbole 620, 622 erbt.
Jedes gemeinsam genutzte Objekt 114 umfaßt einen einzelnen Versionsdefinitionsabschnitt 506, der mehrere Versionsdefinitionen enthält. Jede Gruppe von Feldern 604- 622 wird "Versionsdefinition" genannt. Die folgenden Absätze erörtern den Inhalt einer Versionsdefinition. Die Abschnittskopfzeile 602 gibt die Anzahl von Versionen des gemeinsam genutzten Objekts an, die im Versionsdefinitionsabschnitt enthalten sind. Jeder Versionsdefinitionsabschnitt umfaßt eine Information für eine Basisversion, die globale Symbole definiert, die nicht explizit in der Abbildungsdatei definiert sind. Somit werden die Felder 604-622 (eine "Versionsdefinition") für eine Basisversion in Schritt 306 von Fig. 3(a) erzeugt. Das Feld 609 ("Basis"-Kennzeichen) wird in dieser Basisversionsdefinition gesetzt.
Wie in Schritt 308 gezeigt, wird vom Bindeeditor 124 für jede Version des gemeinsam genutzten Objekts 114, die in der Abbildungsdatei 130 definiert ist, eine Versionsdefintition (Felder 604-622) erzeugt. Für die Abbildungsdatei 130 von Tabelle 2 werden folglich sechs Versionsdefinitionen zusätzlich zur Basisversionsdefinition in Schritt 308 erzeugt. Die Schritte 310-316 von Fig. 3(b) werden für jede in den Schritten 306, 308 erzeugte Versionsdefinition durchgeführt. Wenn die Abbildungsdatei 130 keine globalen Symbole für eine Version definiert (siehe z. B. SUNW.1.2.1 von Tabelle 1), wird, wie in Schritt 310 gezeigt, das "schwache" Kennzeichen 608 für diese Versionsdefinition in Schritt 312 gesetzt (siehe Fig. 16).
Die Version 604 ist eine Versionsnummer der Struktur selbst. Der Versionsdefinitionsindex 610 weist einen unterschiedlichen (eindeutigen) Wert für jede für das gemeinsam genutzte Objekt 114 definierte Version auf und wird nachstehend in Verbindung mit Fig. 7 erörtert. Der Zählwert 612 bezieht sich auf die Anzahl von Instanzen von Paaren von Feldern 620 und 622 in dieser Version. Der Hash- Wert 614 ist ein Hash-Wert für den Namen der Version und verwendet eine herkömmliche ELF-Streuspeicherfunktion. Der Hilfswert 616 ist ein Index für das erste Feld 620 für diese Version. Die nächste Versionsdefinition 618 ist ein Index für das Feld 604 der nächsten Versionsdefinition im Versionsdefinitionsabschnitt.
Schritt 313 erzeugt einen Eintrag 620, 622 für den Namen der aktuellen Version und setzt AUX, um auf diesen Eintrag zu zeigen. Somit enthält das erste Feld 620 den Versionsnamen oder die Version selbst.
Die Vererbungsinformation besteht aus einem oder mehreren Versionsnamen, von denen die definierte Version andere Versionen erbt. Wenn in Schritt 314 von Fig. 3(b) die Abbildungsdatei 130 eine Vererbungsinformation enthält, wie in Fig. 4 und Tabelle 2 gezeigt. In Schritt 316 erzeugt der Bindeeditor 124 einen oder mehrere Einträge 620 und 622, um die Vererbungsinformation zu halten. Die Felder 620 und 622 existieren für jede Version, von der eine Version andere Versionen erbt. Das Feld 620 enthält den Namen der geerbten Versionsdefinition und das Feld 622 zeigt auf das nächste Feld 620 (oder Null).
In Schritt 318 von Fig. 3(a) erzeugt der Bindeeditor 124 einen Versionssymbolabschnitt für alle Symbole des Objekts, das hinsichtlich der Verknüpfung aufbereitet wird. Fig. 7 zeigt ein Format eines Versionssymbolabschnitts 508. Es ist wichtig zu beachten, daß die Einträge im Versionssymbolabschnitt 508 den Symbolen in der Symboltabelle für das Objekt (siehe Fig. 17) Eins zu Eins entsprechen. Symboltabellen sind gewöhnlichen Fachleuten vertraut und sind auch im Handbuch für die binäre Anwendungsschnittstelle des Systems V beschrieben und werden hierin nicht beschrieben. Das Format der Abschnittskopfzeile 702 wird in Verbindung mit Fig. 13 erörtert. Jeder Eintrag 704 im Versionssymbolabschnitt 508 ist ein Index der entsprechenden Version, für die das Symbol definiert wird. Wenn die Version SUNW.1.3b mit Bezug auf Tabelle 2 einen Index 610 von "6" (siehe Fig. 16) aufweist, dann enthält der Eintrag im Versionssymbolabschnitt entsprechend dem globalen Symbol "bar2" folglich einen Eintrag Von "6" (siehe Fig. 17). Wie in Fig. 7 angegeben, enthalten die Einträge für Symbole mit lokalem Gültigkeitsbereich einen Wert von "0". Einträge für Symbole in einer Basisversionsdefinition enthalten einen Eintrag von "1". Wie vorstehend erörtert, weisen nur Symbole, die explizit als globale Symbole definiert sind (z. B. Symbole für den Basisabschnitt, die Namen jeder Version, "foo1", "foo2", "bar1" und "bar2" und "bar3"), von Null verschiedene Einträge 704 im Versionssymbolabschnitt 508 auf.
Schritt 320 von Fig. 3(a) erzeugt einen Versionsabhängigkeitsabschnitt für das gemeinsam genutzte Objekt 114 (falls erforderlich). Das gemeinsam genutzte Objekt 114 kann sich beispielsweise auf andere Versionsobjekte beziehen. Die Erzeugung eines Versionsabhängigkeitsabschnitts wird nachstehend erörtert.

b. Erzeugung einer Versionsabhängigkeitsinformation zur Konstruktionszeit

Tabelle 4 zeigt ein Beispiel einer Quellenversion der Anwendungsprogrammsoftware 116 ("prog.c"). "Prog.c" nimmt auf zwei globale Symbole im gemeinsam genutzten Objekt 114 libfoo.so.1 Bezug, nämlich: "foo1" und "foo2". Diese Symbole sind als Teil der Schnittstellen SUNW.1.1 bzw. SUNW.1.2 definiert. In Tabelle 4 löst der Kompilierer cc zur Konstruktionszeit auch den ld Bindeeditor 124 aus. Zur Konstruktionszeit findet eine Verknüpfung zwischen "prog.c" und den Versionen SUNW.1.1, SUNW.1.2 und SUNW.1.2.1 statt, die die globalen Symbole "foo1" und "foo2" enthält. Die ersteren zwei Versionen stellen die Symbolverknüpfungen dar. Die letztere wird aufgrund ihrer schwachen Art aufgezeichnet. Da keine Versionssteuer-Betriebsanweisungen vom Kompilier/Verknüpfungs-Befehl festgelegt sind, prüft der Bindeeditor 124 alle vorhandenen Versionen des gemeinsam genutzten Objekts 114, wenn globale Symbole in prog.c aufgelöst werden.

TABELLE 4 (Quellencode für ein Anwendungsprogramm und Verknüpfung mit einem Objekt)

Fig. 8 zeigt Schritte, die vom Bindeeditor 124 zur Konstruktionszeit durchgeführt werden, um eine dynamische ausführbare ELF-Datei 120 aus dem relativierbaren Objekt 118 und dem gemeinsam genutzten Objekt 114 zu erzeugen. Das Format der dynamischen ausführbaren ELF-Datei 120 ist in Fig. 10 gezeigt. Das Format von Fig. 10 ist ähnlich zu jenem von Fig. 5, außer daß Fig. 10 einen Versionsabhängigkeitsabschnitt, aber keinen Versionsdefinitionsabschnitt oder Versionssymbolabschnitt enthält. Fig. 11 zeigt ein Format des Versionsabhängigkeitsabschnitts 510.
In Schritt 802 von Fig. 8 stellt der Bindeeditor 124 fest, ob das verknüpfte Objekt (z. B. prog) von anderen Objekten (z. B. libfool.so.1) abhängt, indem er auf unaufgelöste globale Symbole in prog gegen die Tabelle von globalen Symbolen der anderen verknüpften Objekte prüft. Wenn ja, stellt der Bindeeditor 124 in Schritt 804 fest, ob das erforderliche Objekt Versionen aufweist, d. h. ob das erforderliche Objekt einen Versionsdefinitionsabschnitt aufweist. Wenn der Bindeeditor 124 in Schritt 806 feststellt, daß nur bestimmte Versionen des erforderlichen Objekts für den Bindeeditor 124 sichtbar sind, geht die Steuerung zu Schritt 810 über. Ansonsten geht die Steuerung zu Schritt 808 über.
In Schritt 808 erzeugt der Bindeeditor 124 einen Versionsabhängigkeitsabschnitt im dynamischen ausführbaren 120 durch Betrachten aller verfügbaren Versionsdefinitionsabschnitte des gemeinsam genutzten Objekts 114, um festzustellen, welche dieser Versionen die globalen Symbole enthält, die für das relativierbare Objekt 118 erforderlich sind. Alternativ hat die Abbildungsdatei 132 nur bestimmte Versionen als für den Bindeeditor 124 sichtbar identifiziert. In Schritt 810 betrachtet der Bindeeditor 124 nur die sichtbaren Versionsdefinitionsabschnitte des gemeinsam genutzten Objekts 114, um festzustellen, welche dieser Versionen die globalen Symbole enthält, die für das relativierbare Objekt 118 erforderlich sind. Diese Bereitstellung ermöglicht, daß die Verknüpfung auf spezielle Versionen des gemeinsam genutzten Objekts 114 eingeschränkt wird.
Die im Versionsabhängigkeitsabschnitt von Fig. 10 aufgezeichneten Abhängigkeiten werden erzeugt, sobald ein Anwendungsprogramm auf ein globales Symbol in der Schnittstelle zu einem gemeinsam genutzten Objekt Bezug nimmt. Tabelle 4 zeigt ein Beispiel einer Quellenversion der Anwendungsprogrammsoftware 116 ("prog.c"). Das Anwendungsprogramm "prog.c" nimmt auf die globalen Symbole "foo1", das in der Version SUNW.1.1 definiert ist, und "foo2", das in der Version SUNW.1.2 definiert ist (siehe Tabelle 2), Bezug. Somit existiert eine Abhängigkeit zwischen prog.c und SUNW.1.2 (die von SUNW.1.1 erbt). Der Bindeeditor 124 erzeugt einen Versionsabhängigkeitsabschnitt im dynamischen ausführbaren 120 von prog, der angibt, daß sie von der Version SUNW.1.2 abhängt (siehe Fig. 18). Für jedes undefinierte globale Symbol im relativierbaren 118 erhält der Bindeeditor 124 die Information, die mittelt, wo (in welcher Version) sich das Symbol befindet, indem er den Versionsdefinitionsabschnitt und den Versionssymbolabschnitt aller gemeinsam genutzten Objekte betrachtet, die mit dem relativierbaren 118 verknüpft werden.
Fig. 11 zeigt ein Format für den Versionsabhängigkeitsabschnitt 510. Der Versionsabhängigkeitsabschnitt 510 enthält eine Abschnittskopfzeile 1102, wie in Verbindung mit Fig. 12 beschrieben, eine Strukturversion 1104, einen Zählwert 1106, einen Dateinamen 1108 und einen Hilfswert 1110, einen Wert der nächsten Version 1112 und eine Vielzahl von Instanzen von Feldern 1114-1122. Die Felder 1114-1122 enthalten einen Hash-Wert 1114, ein "schwaches" Kennzeichen 1116, ein unbenutztes Feld 1118, ein Namensfeld 1120 und ein Feld 1122 für den nächsten Namen.
Der Strukturversionswert 1104 steht nicht mit der Versionsbildung der vorliegenden Erfindung in Zusammenhang, wie Vorstehend in Verbindung mit Fig. 6 erörtert. Der Zählwert 1106 gibt eine Anzahl von Instanzen von Feldern 1114-1122 an. Der Dateiname 1108 ist ein Name einer Abhängigkeit eines gemeinsam genutzten Objekts. Der Hilfswert 1110 ist ein Index für das erste Feld 1114 für diese Version. Der Wert 1112 des Abschnitts der nächsten Versionsabhängigkeit ist ein Index für das Feld 1104 der nächsten Version (oder Null). Jede Instanz von Feldern 1114-1122 identifiziert eine Version, die für das erzeugte Objekt erforderlich ist. Eine Version ist erforderlich, wenn sie globale Symbole definiert, auf die vom Objekt Bezug genommen wird. Mindestens eine Instanz von Feldern 1114-1122 existiert immer.
Der Hash-Wert 1114 wird vom Namen der Version 1120 erzeugt und wird unter Verwendung einer herkömmlichen ELF- Streuspeicherfunktion erzeugt. Das "schwache" Kennzeichen 1116 gibt an, ob die Abhängigkeitsversion eine schwache Version ist, d. h. ob die Version keine globalen Symbole enthält. Das Feld 1118 muß nicht in allen Implementierungen der Erfindung vorkommen und ist nur für Orientierungszwecke enthalten. Eine erste Instanz des Namensfeldes 1120 enthält einen Namen der Version selbst (z. B. "SUNW.1.2"). Das Feld 1122 des nächsten Namens ist ein Zeiger auf einen nächsten Hash-Wert 1114.
Eine aktuelle Implementierung der Erfindung verwendet eine "Versionsreduktion", bei der nicht alle Vererbungen im Versionsabhängigkeitsabschnitt 510 aufgezeichnet werden. Schwache Versionen werden aufgezeichnet und erforderliche Versionen werden aufgezeichnet. Wenn diese Versionen globale Symbole von anderen Versionen erben, werden jedoch die anderen Versionen im allgemeinen nicht aufgezeichnet. Die Vererbung von einer ersten schwachen Version durch eine zweite schwache Version wird beispielsweise vorzugsweise reduziert, bevor sie in den Feldern 920, 922 aufgezeichnet wird. Ebenso wird die Vererbung von einer ersten nicht- schwachen Version durch eine zweite nicht-schwache Version vorzugsweise reduziert, bevor sie aufgezeichnet wird. Die Vererbung zwischen einer schwachen und einer nicht- schwachen Version wird nicht reduziert. Somit wird SUNW.1.2 in den Feldern 920, 922 aufgezeichnet, aber die Vererbung von SUNW.1.1 wird nicht aufgezeichnet. Außerdem wird eine Abhängigkeit von der schwachen Version SUNW.1.2.1 aufgezeichnet.
Fig. 12-14 zeigen verschiedene Aspekte der Abschnitte von Fig. 6, 7 und 11. Nicht alle Felder von Fig. 12-14 werden hierin beschrieben, da viele von diesen Feldern ein Teil des herkömmlichen ELF-Formats sind. Nur Felder, die für die vorliegende Erfindung relevant sind, werden erörtert. Fig. 12 zeigt ein Format einer Abschnittskopfzeile, das in den Abschnittskopfzeilen 602, 702 und 1102 verwendet wird. Ein Feld 1202 "sh_name" enthält einen Namen eines Abschnitts und ein Feld 1204 "sh_type" enthält einen Typen des Abschnitts. Die Werte 1202 sind für die vorliegende Erfindung besonders relevant. Fig. 13 zeigt Werte, die die verschiedenen Typwerte im Feld 1204 angeben. Die Werte 1302 sind für die vorliegende Erfindung besonders relevant. Das Abschnittskopfzeilenformat von Fig. 12 enthält auch ein Feld 1306 "sh_size", das eine Anzahl von Bytes im Abschnitt angibt, ein Feld 1308 "sh_link" und ein Feld 1310 "sh_info". Fig. 14 zeigt Beispielwerte für die Felder "sh_type", "sh_link" und "sh_info". Die Werte 1402 sind für die vorliegende Erfindung besonders relevant.
Die vorherigen Absätze erörtern die Erzeugung eines ELF- Objekts 114 zur Konstruktionszeit, welches einen Versionsdefinitionsabschnitt 506 und einen Versionssymbolabschnitt 508 enthält, und erörtern ferner die Erzeugung eines ELF-Objekts 120, das einen Versionsabhängigkeitsabschnitt 510 enthält. Es sollte selbstverständlich sein, daß die Abschnitte 506 und 508 nur in Objekten erzeugt werden, die Definitionen von globalen Symbolen enthalten, und der Abschnitt 510 nur in Objekten erzeugt wird, die von Objekten abhängen, die globale Symbole enthalten. Somit umfaßt ein gemeinsam genutztes Objekt mit globalen Schnittstellen die Abschnitte 506 und 508 und möglicherweise den Abschnitt 510. Ausführbare Anwendungsprogramme, die auf das gemeinsam genutzte Objekt Bezug nehmen, umfassen nur den Abschnitt 510.

TABELLE 5 (Verknüpfung unter Verwendung einer Abbildungsdatei, um festzulegen, mit welcher Version es "legal" ist, zu verknüpfen)

c. Einschränkung einer Anwendungskonstruktion zur Konstruktionszeit

Die vorherigen Absätze erörtern ein Beispiel der Versionsverknüpfung zwischen einer relativierbaren und allen verfügbaren Versionen des gemeinsam genutzten Objekts 114. Die Verknüpfung kann auch darauf eingeschränkt werden, zwischen einem Anwendungsprogramm und nur einer speziellen Version eines Objekts stattzufinden. Fig. 9 zeigt ein Format einer Dateisteuer-Betriebsanweisung in der Abbildungsdatei 132 von Fig. 2(c). Eine Dateisteuer- Betriebsanweisung dieses Formats wird verwendet, um ein dynamisches ausführbares Objekt gemäß einer speziellen Version eines anderen Objekts zu verknüpfen. Wenn der Bindeeditor mit der Abbildungsdatei 132, die eine Dateibetriebsanweisung des in Fig. 9 gezeigten Formats enthält, laufen gelassen wird, dann geschieht die Verknüpfung, wie in Fig. 2(c) und Tabelle 5 gezeigt, nur mit der festgelegten Version des Objekts. In Tabelle 5 enthält die Abbildungsdatei "libfoo.so - SUNW.1.1". Wie in Tabelle 4 gezeigt, nimmt die Anwendungssoftware "prog.c" auf die globalen Symbole "foo1" und "foo2" Bezug. Das Symbol "foo2" ist in der Version SUNW.1.2 definiert. Wenn prog.c (unter Verwendung des cc-Kompilierers und ld(1) Bindeeditors) mit einer -M-Option verknüpft wird, wird es nur mit der Version SUNW.1.1 verknüpft. Wie in Tabelle 5 gezeigt, identifiziert der Bindeeditor 124 somit "foo2", das in der Version SUNW.1.2 definiert ist, als undefiniertes Symbol.

d. Förderung einer schwachen Version zur Konstruktionszeit

Tabelle 6 zeigt ein Beispiel, in dem der Bindeeditor 124 dazu gebracht wird, eine schwache Version (SUNW.1.2.1) gegenüber einer starken Version zu "fördern". Aufgrund der "-u"-Option zeichnet der Befehlsleitungs-Bindeeditor 124 eine Abhängigkeit von "prog" von der Version SUNW.1.2.1 im Versionsabhängigkeitsabschnitt von "prog" auf. Ferner wird ein "schwaches" Kennzeichen 1116 für SUNW.1.2.1 im Versionsabhängigkeitsabschnitt von "prog" auf falsch gesetzt. In diesem Fall erbt die Version SUNW.1.2.1 die Version SUNW.1.2. Da alle der Abhängigkeiten von prog 5 "stark" sind, bedeutet folglich eine Versionsreduktion, daß nur SUNW.1.2.1 in prog aufgezeichnet wird und daß es als nicht-schwach aufgezeichnet wird. Die Förderung einer schwachen Version stellt sicher, daß das Laufzeit- Binderprogramm 126 überprüft, daß die ehemals schwache Version vorliegt, wenn "prog" ausgeführt wird.

TABELLE 6 (Förderung einer schwachen Version)

3. Überprüfung der Versionsbildungsinformation zur Laufzeit

Fig. 15 ist ein Ablaufplan 1500, der Schritte zeigt, die vom Laufzeit-Binderprogramm 126 (siehe Fig. 2(d)) durchgeführt werden, um sicherzustellen, daß alle erforderlichen Versionen von herangezogenen Objekten vorliegen, wenn ein dynamisches ausführbares Objekt 120 verknüpft und ausgeführt wird. Die Schritte von Fig. 15 werden vorzugsweise von der CPU 102 verkörpert, die Befehle ausführt, die in einem Speicher gespeichert sind. Die Schritte von Fig. 15 werden als Prüfung vor der Ausführung durchgeführt, um festzustellen, ob alle erforderlichen Abhängigkeiten vorhanden sind.
In Schritt 1502 stellt das Binderprogramm 126 fest, ob das dynamische ausführbare Objekt, das ausgeführt wird, einen Versionsabhängigkeitsabschnitt (siehe Fig. 11) enthält. Wenn nicht, wird keine Prüfung durchgeführt und die normale Ausführung fährt fort. Ansonsten stellt das Binderprogramm 126 in Schritt 1504 fest, ob mindestens eines der Objekte 114, die verkettet werden, einen Versionsdefinitionsabschnitt und einen Versionssymbolabschnitt enthält. Wenn nicht, wird keine weitere Prüfung durchgeführt und die normale Ausführung fährt fort. Ansonsten geht die Steuerung zu Schritt 1506 über.
In Schritt 1506 stellt das Laufzeit-Binderprogramm 126 fest, ob alle Versionsabhängigkeiten im aktuellen dynamischen ausführbaren Objekt verarbeitet wurden. Wenn ja, fährt die normale Ausführung fort, ansonsten geht die Steuerung zu Schritt 1508 über.
In Schritt 1508 stellt das Laufzeit-Binderprogramm 126 fest, ob zwischen einer erforderlichen Version (wie im Versionsabhängigkeitsabschnitt des dynamischen ausführbaren 120 definiert) und dem Versionsdefinitionsabschnitt des gemeinsam genutzten Objekts 114 eine Übereinstimmung existiert. In Fig. 16 und 18 sind beispielsweise die Version SUNW.1.2 und SUNW.1.2.1 im Versionsdefinitionsabschnitt des gemeinsam genutzten Objekts 114 definiert und sind als im Versionsabhängigkeitsabschnitt des dynamischen ausführbaren 120 erforderlich festgelegt.
Wenn in Schritt 1508 eine Übereinstimmung festgestellt wird, dann ist die erforderliche Version des Objekts 114 vorhanden und die Steuerung kehrt zu Schritt 1506 zurück. Ansonsten liegt die erforderliche Version nicht vor und es ist erforderlich, in Schritt 1510 festzustellen, ob die fehlende Version eine schwache oder eine nicht-schwache Version ist. Das Laufzeit-Binderprogramm 126 stellt fest, ob eine Version schwach ist, indem es das "schwache" Kennzeichen 1116 im Versionsabhängigkeitsabschnitt des dynamischen ausführbaren 120 prüft. (Man beachte, daß das Kennzeichen 1116 die "Förderung" einer Version von schwach gegenüber stark widerspiegeln kann.) Wenn das Laufzeit- Binderprogramm 126 in Schritt 1510 feststellt, daß die Version eine schwache Version ist, tritt kein Fehler auf und die Steuerung kehrt zu Schritt 1506 zurück. Ansonsten tritt ein zum Abbruch führender Fehler auf, da keine erforderliche, nicht-schwache Version vorhanden ist. Somit verursacht eine Abhängigkeit von einer fehlenden "schwachen" Version keinen Fehler, aber eine Abhängigkeit von einer fehlenden "nichtschwachen" Version.
Fig. 16 zeigt ein Beispiel eines Versionsdefinitionsabschnitts 1600. Fig. 17 zeigt ein Beispiel eines Versionssymbolabschnitts 1700 für das gemeinsam genutzte Objekt 114 (libfoo.so.1 der Tabellen 1- 3). Fig. 18 zeigt auch ein Beispiel eines Versionsabhängigkeitsabschnitts 1800 für die dynamische ausführbare Form des Anwendungsprogramms 120 ("prog" von Tabelle 4). (In diesem Beispiel weist das gemeinsam genutzte Objekt 14 keine Abhängigkeiten von anderen Objekten auf und weist somit keinen Versionsabhängigkeitsabschnitt auf.)
Fig. 16 enthält eine Basisversionsdefinition 1604 und sechs Versionsdefinitionen für jeweils die Versionen SUNW.1.1, SUNW.1.2, SUNW.1.2.1, SUNW.1.3a, SUNW.1.3b und SUNW.1.4. Das "Basis"-Kennzeichen der Basisversionsdefinition 1604 ist auf "Wahr" gesetzt. Das "schwache" Kennzeichen der Versionsdefinition für SUNW.1.2.1 ist auf "Wahr" gesetzt. Jede Versionsdefinition weist einen jeweiligen (eindeutigen) Versionsdefinitionsindex auf.
Die Versionsreduktion wird in der Versionsdefinitionstabelle angewendet. Die Anwendung "prog" nimmt auf die globalen Symbole foo1 (in SUNW.1.1) und foo2 (in SUNW.1.2) Bezug. Da SUNW.1.2 die globalen Symbole von SUNW.1.1 erbt, wendet der Bindeeditor 124 die Versionsreduktion an und ein Eintrag (für SUNW.1.2) wird im Versionsdefinitionsabschnitt durchgeführt. Die schwache Version SUNW.1.2.1 wird auch aufgezeichnet.
Fig. 17 zeigt einige der Symbole im Versionssymbolabschnitt 1700. Die globale Variable "foo1" ist beispielsweise in der Version SUNW.1.1 definiert, die einen Versionsdefinitionsindex von "2" aufweist. Somit enthält der Eintrag im Versionssymbolabschnitt entsprechend dem Eintrag in der Symboltabelle für foo1 "2". Beim beschriebenen Ausführungsbeispiel ist der Name für jede Version (z. B. SUNW.1.1) auch ein globales Symbol, das erzeugt wird, wenn die Versionsdefinition erzeugt wird.
Fig. 18 zeigt ein Beispiel eines Versionsabhängigkeitsabschnitts im dynamischen ausführbaren 120. Aufgrund der Versionsreduktion enthält der Abschnitt einen Eintrag für SUNW.1.2, aber nicht für SUNW.1.1. Der Abschnitt enthält auch einen Eintrag für die "schwache" Version SUNW.1.2.1. Zur Laufzeit stellt das Binderprogramm 126 fest, daß prog einen Versionsabhängigkeitsabschnitt aufweist (Schritt 1502), stellt fest, daß libfoo.so.1. einen Versionsdefinitionsabschnitt aufweist (Schritt 1504), und stellt fest, daß die erforderliche Version (SUNW.1.2) Vorhanden ist (Schritt 1508). Daher wird "prog" ausgeführt.
Mehrere bevorzugte Ausführungsbeispiele der vorliegenden Erfindung wurden beschrieben. Trotzdem ist es selbstverständlich, daß verschiedene Modifikationen vorgenommen werden können, ohne vom Schutzbereich der beanspruchten Erfindung abzuweichen.
Beim Beschreiben der bevorzugten Ausführungsbeispiele wurden eine Anzahl von speziellen Technologien, die zum Implementieren der Ausführungsbeispiele von verschiedenen Aspekten der Erfindung verwendet wurden, identifiziert und mit allgemeineren Begriffen in Zusammenhang gebracht, mit 1 denen die Erfindung beschrieben wurde. Es sollte jedoch selbstverständlich sein, daß eine solche Spezifität den Schutzbereich der beanspruchten Erfindung nicht begrenzen soll.

Claims

1. Verfahren zur Bereitstellung einer Versionsbildungsinformation in einem Softwareprogramm mit den folgenden Schritten, die von einem Datenverarbeitungssystem (100) durchgeführt werden:

Vorsehen eines ersten Objektcodes (112) für ein erstes Softwareprogramm (110);

Vorsehen einer Abbildungsdatei (130, 132) separat vom Objektcode, welche einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms zugeordnet ist, wobei die Abbildungsdatei (130, 132) ferner globale Symbole festlegt, die eine Schnittstelle der Version des ersten Softwareprogramms bilden; und

Verknüpfen (124) des ersten Objektcodes (112), so daß zum ersten Objektcode (112) gemäß der Abbildungsdatei (130, 132) eine Information hinzugefügt wird, die den Versionsnamen des ersten Softwareprogramms (110) identifiziert, um ein Versionsobjekt (114) zu ergeben,

wobei der Verknüpfungsschritt ferner den Schritt des Hinzufügens einer Information zum ersten Objektcode (112) gemäß der Abbildungsdateiinformation umfaßt, wobei die Information die globalen Symbole identifiziert, die die Schnittstelle der Version bilden.

2. Verfahren nach Anspruch 1, welches ferner die Schritte umfaßt:

Vorsehen eines zweiten Objektcodes (118) für ein zweites Softwareprogramm (116); und

Verknüpfen des zweiten Objektcodes (118) mit dem Versionsobjekt, wobei der Verknüpfungsschritt ferner die Schritte umfaßt:

Feststellen einer Version des ersten Softwareprogramms (110), die für das zweite Softwareprogramm (116) erforderlich ist, und

Hinzufügen einer Information zum zweiten Objektcode (118), die die Version festlegt, die für das zweite Softwareprogramm (116) erforderlich ist, um ein dynamisches ausführbares Programm (120) zu ergeben.

3. Verfahren nach Anspruch 2, welches ferner die Schritte umfaßt:

vor dem Ausführen (126) des dynamischen ausführbaren Programms (120) Feststellen, ob die erforderliche Version im dynamischen ausführbaren Programm der Version entspricht, die im Versionsobjekt identifiziert ist; und

Ausführen des dynamischen ausführbaren Programms (120), wobei das dynamische ausführbare Programm (120) die erforderliche Version des Versionsobjekts aufruft.

4. Verfahren nach Anspruch 2, wobei der Feststellungsschritt ferner den Schritt des Feststellens einer Version des ersten Softwareprogramms (110) umfaßt, die für das zweite Softwareprogramm (116) erforderlich ist, durch Feststellen, welche globalen Symbole für das zweite Softwareprogramm (116) erforderlich sind, und durch Feststellen, durch Prüfen der Information im Versionsobjekt, in welchen Versionen sich die erforderlichen globalen Symbole befinden.

5. Verfahren nach Anspruch 1, wobei die zum ersten Objektcode (112) hinzugefügte Information ein Versionsdefinitionsabschnitt (506) ist.

6. Verfahren nach Anspruch 1, wobei die zum ersten Objektcode (112) hinzugefügte Information ein Versionssymbolabschnitt (508) ist.

7. Verfahren nach Anspruch 2, wobei die zum zweiten Objektcode (116) hinzugefügte Information ein Versionsabhängigkeitsabschnitt (510) ist.

8. Verfahren nach Anspruch 1, wobei das Versionsobjekt (114) ein relativierbares Objekt ist.

9. Verfahren nach Anspruch 1, wobei das Versionsobjekt ein dynamisches ausführbares Objekt (120) ist.

10. Verfahren nach Anspruch 1, wobei das Versionsobjekt (114) ein gemeinsam genutztes Objekt ist.

11. Vorrichtung zur Bereitstellung einer Versionsbildungsinformation in einem Softwareprogramm, umfassend:

ein Speichermedium (104), das einen Objektcode für ein erstes Softwareprogramm (110) speichert;

ein Speichermedium, das eine Abbildungsdatei (130, 132) separat vom Objektcode (112) speichert, welche einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms (110) zugeordnet ist, wobei die Abbildungsdatei (130, 132) ferner globale Symbole festlegt, die eine Schnittstelle der Version des ersten Softwareprogramms (110) bilden; und

ein Binderprogramm (124), das dazu ausgelegt ist, eine zusätzliche Information im ersten Objektcode (112) gemäß der Abbildungsdatei (130, 132) vorzusehen, wobei die zusätzliche Information den Versionsnamen der Version des ersten Softwareprogramms (110) festlegt, um ein Versionsobjekt (114) zu ergeben,

wobei das Binderprogramm (124) ferner dazu ausgelegt ist, eine Information zum ersten Objektcode (112) gemäß der Abbildungsdateiinformation hinzuzufügen, wobei die Information die globalen Symbole identifiziert, die die Schnittstelle der Version bilden.

12. Vorrichtung nach Anspruch 11, welche ferner umfaßt:

ein Speichermedium, das einen zweiten Objektcode (118) für ein zweites Softwareprogramm (116) speichert; und

ein Binderprogramm, das dazu ausgelegt ist, den zweiten Objektcode (118) mit dem Versionsobjekt zu verknüpfen, um ein dynamisches ausführbares Programm (120) zu ergeben, durch Hinzufügen einer zusätzlichen Information zum zweiten Objektcode (118), der die Version festlegt, die für das zweite Softwareprogramm (116) erforderlich ist.

13. Vorrichtung nach Anspruch 12, welche ferner umfaßt: ein Laufzeit-Binderprogramm (126), das dazu ausgelegt ist, eine Ausführung des dynamischen ausführbaren Programms (120) vorzusehen, wenn das Laufzeit-Binderprogramm feststellt, daß die erforderliche Version, die im dynamischen ausführbaren Programm (120) festgelegt ist, der Version entspricht, die im Versionsobjekt festgelegt ist.

14. Vorrichtung nach Anspruch 11, wobei das Versionsobjekt ein relativierbares Objekt (114) ist.

15. Vorrichtung nach Anspruch 11, wobei das Versionsobjekt ein dynamisches ausführbares Objekt (120) ist.

16. Vorrichtung nach Anspruch 11, wobei das Versionsobjekt ein gemeinsam genutztes Objekt ist.

17. Computerprogrammprodukt mit:

einem vom Computer verwendbaren Medium mit einem darin verkörperten maschinenlesbaren Code zum Veranlassen einer Feststellung, daß eine Version eines Objekts, die für ein dynamisches ausführbares Programm (120) erforderlich ist, während der Ausführung des dynamischen ausführbaren Programms (120) vorliegt, wobei das Computerprogrammprodukt umfaßt:

Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer (102) zu veranlassen, die Bereitstellung eines ersten Objektcodes (112) für ein erstes Softwareprogramm (110) zu bewirken;

Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu veranlassen, die Bereitstellung einer Abbildungsdatei (130, 132) separat von dem Objektcode (112) zu bewirken, welche einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms (110) zugeordnet ist, wobei die Abbildungsdatei (130, 132) ferner globale Symbole festlegt, die eine Schnittstelle der Version des ersten Softwareprogramms (110) bilden; und

Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu veranlassen, eine Verknüpfung des ersten Objektcodes (112) zu bewirken, so daß zum ersten Objektcode (112) gemäß der Abbildungsdatei (130, 132) eine Information hinzugefügt wird, die den Versionsnamen der Version des ersten Softwareprogramms identifiziert, um ein Versionsobjekt (114) zu ergeben, und ferner dazu ausgelegt sind, eine Information zum ersten Objektcode (112) gemäß der Abbildungsdateiinformation hinzuzufügen, wobei die Information die globalen Symbole identifiziert, die die Schnittstelle der Version bilden.

18. Computerprogrammprodukt nach Anspruch 17, welches ferner umfaßt:

Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu veranlassen, die Bereitstellung eines zweiten Objektcodes (118) für ein zweites Softwareprogramm (116) zu bewirken; und

Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu veranlassen, die Verknüpfung des zweiten Objektcodes (118) mit dem Versionsobjekt zu bewirken, durch Feststellen einer Version des ersten Softwareprogramms (110), die für das zweite Softwareprogramm (116) erforderlich ist, und durch Hinzufügen einer Information zum zweiten Objektcode (118), die die Version festlegt, die für das zweite Softwareprogramm (116) erforderlich ist, um ein dynamisches ausführbares Programm (120) zu ergeben.

19. Computerprogrammprodukt nach Anspruch 18, welches ferner umfaßt: Vorrichtungen für einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu veranlassen, eine Feststellung dessen zu bewirken, ob die Version, die für das dynamische ausführbare Programm (120) erforderlich ist, um die Ausführung des Programms zu bewirken, der Version entspricht, die im Versionsobjekt (114) festgelegt ist; und dazu ausgelegt sind, das dynamische ausführbare Programm auszuführen, wobei das dynamische ausführbare Programm (120) die erforderliche Version des Versionsobjekts (114) aufruft.