Watcom-16bit-DOS-Projekt Linker-Fehler E2030 ... multiple starting addresses found



  • Hallo Gemeinschaft,

    ich versuche eine 16bit-DOS-Anwendung mit Open Watcom 1.8 zu erstellen.
    Ich habe ein heilloses Durcheinander an Quelldateien (.c) und Headern (.h), sowie einige *.LIB bekommen und noch viele viele weitere Dateien zur Verfügung. Ich habe nun in den alten Projektordnern *.MAK-Dateien gefunden (LINKF_K.MAK und MAKEF_K.MAK). In diesen habe ich Informationen über die für die Anwendung (K.exe) benötigten *.LIB's und *.OBJ's gefunden.
    Die Lib's (aus LINKF_K.MAK) habe ich in WC1.8 bei "Options"->"Linker-Switches..."->"2.Import, Export and Library Switches" unter "Library Files" eingetragen. Ausserdem habe ich dort unter "Library directories" den Pfad angegeben, unter dem die Lib's liegen.
    Alle benötigten Quelldateien (laut MAKEF_K.MAK) habe ich zum WC1.8-Projekt hinzugefügt, so dass die Obj's erzeugt werden können. Alle Header liegen im Projektverzeichnis.
    Wenn ich nun auf "Make Target" drücke, compiliert WC1.8 auch durch (abgesehen von den unzähligen Warnungen bezüglich ungenutzter Variabeln, Funktionen ohne Prototyp etc.), beim Linken gibt es jedoch ein Problem...
    Hier mal die WC1.8-Meldungen nach dem Compilieren:

    IDE Log schrieb:

    wlink name k_new SYS dos op m libp C:\k_dos libf C6_T20L2.LIB libf IEEE488.LIB libf GRAPHICS.LIB op maxe=25 op q op symf @k_new.lk1
    Warning! W1027: file KAL2.obj(C:\k_dos\KAL2.C): redefinition of _s_s ignored
    Warning! W1027: file KAL3.obj(C:\k_dos\KAL3.C): redefinition of _s_s ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __ovlflag ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __intno ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __ovlvec ignored
    Error! E2030: file clibl.lib(cstart): multiple starting addresses found
    Warning! W1027: file clibl.lib(argcv.c): redefinition of ___argv ignored
    Warning! W1027: file clibl.lib(argcv.c): redefinition of ___argc ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __child ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __psp ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osmajor ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osminor ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osmode ignored
    Warning! W1027: file clibl.lib(errno.c): redefinition of _errno ignored
    Warning! W1027: file clibl.lib(errno.c): redefinition of __doserrno ignored
    Error(E42): Last command making (C:\k_dos\kali_new.exe) returned a bad status
    Error(E02): Make execution terminated
    Execution complete

    k_new.map schrieb:

    Open Watcom Linker Version 1.8
    Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
    Created on: 09/05/07 16:08:49
    Warning! W1027: file K2.obj(C:\k_dos\K2.C): redefinition of _s_s ignored
    Warning! W1027: file K3.obj(C:\k_dos\K3.C): redefinition of _s_s ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __ovlflag ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __intno ignored
    Warning! W1027: file clibl.lib(cstart): redefinition of __ovlvec ignored
    Error! E2030: file clibl.lib(cstart): multiple starting addresses found
    Warning! W1027: file clibl.lib(argcv.c): redefinition of ___argv ignored
    Warning! W1027: file clibl.lib(argcv.c): redefinition of ___argc ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __child ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __psp ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osmajor ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osminor ignored
    Warning! W1027: file clibl.lib(crwdata): redefinition of __osmode ignored
    Warning! W1027: file clibl.lib(errno.c): redefinition of _errno ignored
    Warning! W1027: file clibl.lib(errno.c): redefinition of __doserrno ignored
    Executable Image: k_new.exe
    creating a DOS executable

    +--------------------+
    | Libraries Used |
    +--------------------+

    LLIBCE.lib
    C:\Programme\WATCOM/lib286\math87l.lib
    C:\Programme\WATCOM/lib286/dos\emu87.lib
    C:\Programme\WATCOM/lib286/dos\graph.lib
    C:\Programme\WATCOM/lib286/dos\clibl.lib

    Die Linker-Zeile (aus k_new.mk1) sieht so aus:

    *wlink name k_new SYS dos op m libp C:\k_dos libf C6_T20L2.LIB libf IEEE488.LIB libf GRAPHICS.LIB op maxe=25 op q op symf @k_new.lk1

    Die Error-Meldung aus der k_new.map habe ich mal in der WC1.8-Hilfe nachgeschlagen und sinngemäß übersetzt:

    "E2030: Die Start-Adresse definiert den Ort, an dem die Ausführung beginnt. Die Fehlermeldung wird ausgegeben, wenn mehr als 1 Objektdatei einen "Module End"-Eintrag enthält, der eine Start-Adresse festlegt."

    Darunter kann ich mir garnichts vorstellen... was bedeutet das? Wodurch kann die Meldung entstehen? Was kann ich dagegen tun?

    Ich bin im Moment ziemlich ratlos, vielleicht kann mir ja jemand weiterhelfen... ich bin für jeden Hinweis dankbar!

    MfG



  • Ohne dir bei deinem konkreten Problem (das ein bißchen so aussieht, als würdest du mehrfach gegen Startup-Code linken) weiterhelfen zu können, eine kleine Zwischenfrage: die Zahl der Probleme deutet darauf hin, daß die Anwendung damals nicht mit dem Watcom-Compiler erstellt wurde. Aus welchem Grund benutzt du nicht das ursprüngliche Toolset?



  • Hey,

    du hier? Na wenigstens gleich ein "bekanntes Gesicht" 🙂

    audacia schrieb:

    Ohne dir bei deinem konkreten Problem (das ein bißchen so aussieht, als würdest du mehrfach gegen Startup-Code linken) weiterhelfen zu können [...]

    Gut, sieht also so aus als würde ich mehrmals den Startup-Code linken... 😕 Wie kann ich das prüfen?

    audacia schrieb:

    [...] die Zahl der Probleme deutet darauf hin, daß die Anwendung damals nicht mit dem Watcom-Compiler erstellt wurde. Aus welchem Grund benutzt du nicht das ursprüngliche Toolset?

    Deine Vermutung ist sehr richtig. Mit ziemlicher Sicherheit wurde die Anwendung nicht mit WC erstellt... nur leider weiß keiner mit welchem Toolset die Anwendung damals erstellt wurde und der entsprechende Mitarbeiter ist 1996 nicht aus dem Urlaub wiedergekommen und seinen Rechner gibt es nicht mehr 😉

    Wie würdest du an das Problem herangehen?



  • Kolumbus schrieb:

    du hier?

    Ich werde wohl demnächst auch das Vergnügen haben, mit einem alten 16-Bit-Compiler arbeiten zu müssen. Da bereite ich mich schon mal vor 🤡

    Kolumbus schrieb:

    Gut, sieht also so aus als würde ich mehrmals den Startup-Code linken... 😕 Wie kann ich das prüfen?

    Ein möglicher Ansatz wäre, mit TDUMP zu überprüfen, welche der hinzugelinkten Bibliotheken noch Startup-Code exportiert.
    Was sind das eigentlich für Bibliotheken, die du da manuell hinzulinkst? Nicht etwa übriggebliebene Runtime-Bibliotheken des ursprünglichen Compilers?

    audacia schrieb:

    nur leider weiß keiner mit welchem Toolset die Anwendung damals erstellt wurde und der entsprechende Mitarbeiter ist 1996 nicht aus dem Urlaub wiedergekommen und seinen Rechner gibt es nicht mehr 😉

    Wie würdest du an das Problem herangehen?

    Anhand von Quelltext, Makefiles und verwendeten Libraries versuchen, auf den ursprünglichen Compiler zu schließen.

    Oder vielleicht existiert noch eine kompilierte Version des Projektes? Daraus dürfte sich ebenfalls die Compiler-Version entnehmen lassen (die meisten Compiler hinterlassen ihre Signatur in der Executable).



  • audacia schrieb:

    Kolumbus schrieb:

    du hier?

    Ich werde wohl demnächst auch das Vergnügen haben, mit einem alten 16-Bit-Compiler arbeiten zu müssen. Da bereite ich mich schon mal vor 🤡

    Sehr weise 👍 Mich hat es leider unvorbereitet getroffen...

    audacia schrieb:

    Kolumbus schrieb:

    Gut, sieht also so aus als würde ich mehrmals den Startup-Code linken... 😕 Wie kann ich das prüfen?

    Ein möglicher Ansatz wäre, mit TDUMP zu überprüfen, welche der hinzugelinkten Bibliotheken noch Startup-Code exportiert.

    Gut, ist vorgemerkt - Danke! 🙂

    audacia schrieb:

    Was sind das eigentlich für Bibliotheken, die du da manuell hinzulinkst? Nicht etwa übriggebliebene Runtime-Bibliotheken des ursprünglichen Compilers?

    Was soll ich sagen... die liegen da so im Projektverzeichnis rum (das Verzeichnis in dem sich die Quelltexte und Header befinden). Da ich in der LINKF_K.MAK diese Bibliotheken wiedergefunden habe, dachte ich mir die sollten dazugelinkt werden. Und tatsächlich waren dann viele Fehlermeldungen über fehlende Funktionen verschwunden... Die Bibliotheken heißen C6_T20L2, GRAPHICS und IEEE4888. bis auf die Graphics bin ich eigentlich ziemlich sicher, dass es keine Standard-Bibliotheken sind, sondern externe Zusatzbibliotheken. Aber ich werde mal nachprüfen, ob es wegen der Graphics.lib Probleme gibt.

    audacia schrieb:

    Kolumbus schrieb:

    nur leider weiß keiner mit welchem Toolset die Anwendung damals erstellt wurde [...] Wie würdest du an das Problem herangehen?

    Anhand von Quelltext, Makefiles und verwendeten Libraries versuchen, auf den ursprünglichen Compiler zu schließen.

    Ich fürchte da fehlt mir die Erfahrung... was wären Hinweise auf den verwendeten Compiler? Sowas wie der Kopf der map-Datei in meinem Eingangspost?

    audacia schrieb:

    Oder vielleicht existiert noch eine kompilierte Version des Projektes? Daraus dürfte sich ebenfalls die Compiler-Version entnehmen lassen (die meisten Compiler hinterlassen ihre Signatur in der Executable).

    Aha! Ja, eine kompilierte Version ist vorhanden... wie bekommen ich die Signatur aus der Executable heraus?

    Man Man, du hilfst mir echt oft weiter - irgendwann muss ich dir mal n Bier und n Essen spendieren (falls du Bier und Essen magst 😉 )!



  • Kolumbus schrieb:

    was wären Hinweise auf den verwendeten Compiler? Sowas wie der Kopf der map-Datei in meinem Eingangspost?

    Eher nicht - die erstellt ja der Watcom-Linker.

    Ich würde zunächst ganz stupide mit GREP im Projektverzeichnis nach BORLAND, MICROSOFT und MSCVER suchen.

    Kolumbus schrieb:

    Aha! Ja, eine kompilierte Version ist vorhanden... wie bekommen ich die Signatur aus der Executable heraus?

    Einfach mal mit einem Hex-Editor reinschauen. Meist steht irgendwo so etwas wie z.B. "Borland C++ - Copyright 1993, 1994 Borland International".



  • Sollten bei dem Projekt Standard-Header dabei sein poste mal die Größe von diesen und das Erstellungsdatum. Von der Graphis-Bibiothek ebenso.

    Einige Compiler hinterliessen ihr Logo in etwa in den letzten Zeilen:
    Einfach mal nach Copyright suchen und einige Zeichen danach könnte es stehen.

    MfG f.-th.



  • audacia schrieb:

    [...]Einfach mal mit einem Hex-Editor reinschauen. Meist steht irgendwo so etwas wie z.B. "Borland C++ - Copyright 1993, 1994 Borland International".

    f.-th. schrieb:

    [...]Einige Compiler hinterliessen ihr Logo in etwa in den letzten Zeilen.
    Einfach mal nach Copyright suchen und einige Zeichen danach könnte es stehen.

    Folgendes konnte ich per Hex-Editor weiter hinten in der Executable (nach einem Block von 2881mal 00h) finden:

    MS Run-Time Library - Copyright (c) 1992, Microsoft Corp.

    Ganz am Ende fand ich (nach einem Block von 1903mal 00h) Folgendes:

    M&T QuickC-Toolbox

    f.-th. schrieb:

    Sollten bei dem Projekt Standard-Header dabei sein poste mal die Größe von diesen und das Erstellungsdatum. Von der Graphis-Bibiothek ebenso.

    zB. STDLIB.H mit 7.351 Byte, Geändert am 11. Dezember 1991 16:52:50
    GRAPHICS.LIB mit 97745 Byte, Geändert am 06. März 1992 16:41:04

    Das verstehe ich nun so, dass die Anwendung mit einem Werkzeug / einer IDE Namens "M&T QuickC-Toolbox" erstellt wurde. Dieses Werkzeug nutzt die MS Runtime-Library von 1992.

    Was denkt ihr?

    Edit: Per Suchmaschine habe ich jetzt gefunden, dass es eine "Microsoft QuickC Programmer's Toolbox" und einen Microsoft QuickC-Compiler gab...



  • Schon mal kurz vorweg:
    Es gab damals Microsoft-Compiler/-IDE mit dem Namen: Quick-C
    Mal sehen ob ich die Version noch heraus kriege?
    Weiterhin wurde bei dem Projekt eine Toolbox des Verlags Markt&Technik für den Compiler genutzt.

    MfG f.-th.



  • Oh, das wird sehr interessant 😃
    Meines Wissens war der Quick-C 2.5 die letzte Version dieser Reihe -
    da ist der stdlib.h aber 6,64kB groß und hat einen Timestamp vom 25.07.1990 - 13:00.
    Vielleicht gab es noch ein späteres Bugfix oder so?

    Manchmal hat man aber mit dem Quick-C-Compiler mit Dateien des MSC 6.0, nicht zu verwechseln mit der Visual-Variante, eingesetzt.

    Schau mal in der Headerdatei, was da im Vorspann steht?

    graphics.lib würde ich eher bei Borland ansiedeln - such hier mal nach BGI in der Datei.

    Andere Varinate, beide Dateien stammen von der M&T-Toolbox oder noch woanders her?

    MfG f.-th.



  • Es gab wohl doch noch einen kleinen Nachschlag: Quick C 2.51


Anmelden zum Antworten