name mangeling beim Linken von .o Dateien aus GCC?

[Christian]

@FPGUIcoder Vllt würde ein einfaches beispiel hier eiterhelfen. Mach doch ein möglichst kleines Demo Projekt samt den .a,.o files und der dll alles gezippt und hängs an. Dann erbarmt sich marcov oder Anonymous vllt und schaut mal 10 min drüber.

[fpGUIcoder]

@Christian:

Wenn ich wüßte wie dieses "einfache Beispiel" aussehen könnte?

Im Eingangsbeitrag habe ich C Quelltext. Der liegt auch als .o Datei vor. Wenn ich mit $LINK utext.o den in meine Unit linke, egal ob oben im Interfaceteil oder zudammen mit der Funktion, dann erhalte ich den Linkfehler, sobald ich mein Testprogramm übersetzen will. Mein Testprogramm ruft derzeit eine der Funktionen auf.

Die Unit wird ohne Beanstandung kompiliert, das Linken der Bibliothek erfolgt wohl erst in der letzten Phase, beim Bau der Anwendung. Beim Übersetzen der Unit wird der Objektcode noch nicht verlinkt, sonst müsste der Compilerfeheler beim Übersetzen der unit kommen. Der kommt aber erst beim Übersetzen der Anwendung.

Im Beitrag 8 der ersten Seite hier habe ich schon ein Beispiel mit der Unit, die im Interfaceteil die Funktion UTextToUpper importiert, die external definiert ist und deren Implementation in der Binärdatei utext.o enthalten ist. Diese Binärdatei ist Bestandteil des Projektes und vorcompiliert von den Erstellern des Projektes.

Es handelt sich um die Quellen der Aura GUI aus Freedos, welche aber auch unter Windows und Linux laufen. Das funktioniert deshalb, weil die Aura GUI auf Allegro basiert. Für Allegro gibt es eine Pascal Implementation, die mindestens unter Windows läuft. Ich vermute, das es dafür auch eine Linux Implementation gibt.

Ich weiß auch, dass das Freepascal Team Pläne hat, OPenGEM unter Freepascal bereit zu stellen. Dieses Projekt ist um Länge aufwendiger, also langwieriger zu portieren, wenn ich da helfen soll, brauche ich zwingend passende C/C++ Objejektdateien, die ich nur noch dazu linken muss. Ansonsten ist die Aura Gui günstiger, da ist der zu portierende Quellcode weniger umfangreich ist, der Fensterstil gefällt mir persönlich besser (sieht moderner aus) und die Aura GUI zudem auf allen 3 Plattformen läuft (Linux Windows UND DOS).

Warum unter DOS keine GUI mehr sein darf erschließt sich mir nicht.

Heutige PKW Oldtimer werden auch mit heutigen farbenprächtigen Lacken lackiert. Die PKW's Wartburg und Trabant gab es auch in der DDR sowohl als 2- als auch als 4-Takter.

In C/C++ gibt es jede Menge GUI's die auch unter DOS laufen. Warum also nicht auch in Pascal.

OPenGEM zu portieren dauert zu lange, bei den Problemen mit dem Linken der C/C++ Binaries. AUra GUI geht da schneller und die läuft dann zusätzlich noch plattformübergreifend. OPenGEM läuft dann nur unter DOS.

Ich bevorzuge daher die Aura GUI. Nicht zuletzt auch wegen ihres moderneren Fensterstils.

Der gleiche Beitrag enthält auch eine Anwendung mit Namen "Test", welche die Funktion "UTextToUpper" aufruft.

Daher muss ich fragen, wie denn mein Demo Beispiel aussehen soll, um besser verständlich zu sein.

So lange werd ich wohl doch, wie @Anonymus rät, alles von Hand in Pascal Code überführen. Ich brauche den Code jetzt. Nicht erst, wenn die nächste Version raus ist, in der dann irgendwann das Linken mit C/C++ Code einfacher werden soll.

In h2Pas einarbeiten brigt mir auch nix, denn wenn ich mir da erst Regeln für die Umwandlung erarbeiten muss und zudem mit dem Lazarus Package hierzu vertraut werden muss, da wird h2Pas gar nicht aufgerufen, obwohl ich den Bin Pfad für das Kommandozeilentool h2Pas im Pfad angegeben habe, dann habe ich in jener Zeit, die ich für die Einarbeitung in h2Pas benötige auch die Konvertierung per Hand vorgenommen und erfülle so gleichzeitig Markovs Forderung, mich so richtig anzustrengen und lerne nebenbei gleich noch die Programmiersprache C/C++, was mir später auch noch nützlich sein könnte.

[Thandor]

Hallo,

ich habe Ende 2011 mal eine Unit zu einer DLL-Datei von den USB-Experimentierinterface Board von Vellemann erstellt. Hier bin ich nach der Dokumentation vorgegangen.
In der Unit habe ich statt "cdecl;" "stdcall;" verwndet, andern Falls hatt es nicht funktioniert. Versuch es mal damit.

Hier mal noch der Code meiner Unit zu, Vergleichen:

Code: Alles auswählen

 
unit K8055;
{******************************************************************************
 *                          Unitname : K8055                                  *
 *                          Autor    : Sebastian Kuhnert                      *
 *                          Datum    : 24.12.2011                             *
 *                          Uodate   : 25.12.2011                             *
 ******************************************************************************}
{******************************************************************************
 * Diese Unit macht die Routienen der K8055d.DLL, des                         *
 * "USB Experiment Inteface Board K8055" Verfügbar.                           *
 ******************************************************************************}
{$mode objfpc}{$H+}
 
//#############################################################################
interface
//#############################################################################
 
  {Allgemein}
    Function  Version : Integer;                                          stdcall;
    Function  SetCurrentDevice    (CardAddress: Integer): Integer;        stdcall;
    Function  SearchDevices : Integer;                                    stdcall;
    Function  OpenDevice          (CardAddress : LongInt):LongInt;        stdcall;
    Procedure CloseDevice;                                                stdcall;
  {Analog in Digital Konvertieren}
    Function  ReadAnalogChannel   (Channel          : LongInt) : LongInt; stdcall;
    Procedure ReadAllAnalog       (var Data1, Data2 : LongInt);           stdcall;
  {Digital in Analog konvertieren}
    Procedure OutputAnalogChannel (Channel, Data    : LongInt);           stdcall;
    Procedure OutputAllAnalog     (Data1  , Data2   : LongInt);           stdcall;
    Procedure ClearAnalogChannel  (Channel          : LongInt);           stdcall;
    Procedure ClearAllAnalog;                                             stdcall;
    Procedure SetAnalogChannel    (Channel          : LongInt);           stdcall;
    Procedure SetAllAnalog;                                               stdcall;
  {Digitaler Ausgang}
    Procedure WriteAllDigital     (Data             : LongInt);           stdcall;
    Procedure ClearDigitalChannel (Channel          : LongInt);           stdcall;
    Procedure ClearAllDigital;                                            stdcall;
    Procedure SetDigitalChannel   (Channel          : LongInt);           stdcall;
    Procedure SetAllDigital;                                              stdcall;
  {Digitaler Eingang}
    Function ReadDigitalChannel   (Channel          : LongInt) : Boolean; stdcall;
    Function ReadAllDigital : LongInt;                                    stdcall;
  {Zählerfunktionen}
    Procedure ResetCounter        (CounterNumber    : LongInt);           stdcall;
    Function ReadCounter          (CounterNumber    : LongInt) : LongInt; stdcall;
    Procedure SetCounterDebounceTime (CounterNr, DebounceTime : LongInt); stdcall;
 
  {Eigenes}
    Function VersionToStr (Ver : Integer) : String;
 
Const CARDADR_0 = 1;
      CARDADR_1 = 2;
      CARDADR_2 = 4;
      CARDADR_3 = 8;
 
//#############################################################################
implementation
//#############################################################################
 
Const DLL = 'K8055d.dll';
 
{Allgemein}
  Function  Version : Integer;                                          stdcall; external DLL;
  Function  SetCurrentDevice(CardAddress: Integer): Integer;            stdcall; external DLL;
  Function  SearchDevices : Integer;                                    stdcall; external DLL;
  Function  OpenDevice (CardAddress : LongInt):LongInt;                 stdcall; external DLL;
  Procedure CloseDevice;                                                stdcall; external DLL;
{Analog in Digital Konvertieren}
  Function  ReadAnalogChannel (Channel : LongInt) : LongInt;            stdcall; external DLL;
  Procedure ReadAllAnalog (var Data1, Data2 : LongInt);                 stdcall; external DLL;
{Digital in Analog konvertieren}
  Procedure OutputAnalogChannel (Channel, Data : LongInt);              stdcall; external DLL;
  Procedure OutputAllAnalog (Data1, Data2 : LongInt);                   stdcall; external DLL;
  Procedure ClearAnalogChannel (Channel : LongInt);                     stdcall; external DLL;
  Procedure ClearAllAnalog;                                             stdcall; external DLL;
  Procedure SetAnalogChannel (Channel : LongInt);                       stdcall; external DLL;
  Procedure SetAllAnalog;                                               stdcall; external DLL;
{Digitaler Ausgang}
  Procedure WriteAllDigital (Data : LongInt);                           stdcall; external DLL;
  Procedure ClearDigitalChannel (Channel : LongInt);                    stdcall; external DLL;
  Procedure ClearAllDigital;                                            stdcall; external DLL;
  Procedure SetDigitalChannel (Channel : LongInt);                      stdcall; external DLL;
  Procedure SetAllDigital;                                              stdcall; external DLL;
{Digitaler Eingang}
  Function ReadDigitalChannel (Channel : LongInt) : Boolean;            stdcall; external DLL;
  Function ReadAllDigital : LongInt;                                    stdcall; external DLL;
{Zählerfunktionen}
  Procedure ResetCounter (CounterNumber : LongInt);                     stdcall; external DLL;
  Function ReadCounter (CounterNumber : LongInt) : LongInt;             stdcall; external DLL;
  Procedure SetCounterDebounceTime (CounterNr, DebounceTime : LongInt); stdcall; external DLL;
 
{Eigenes}
  Function IntToStr (i : LongInt) : String; Begin str(i, Result); end;
 
  Function VersionToStr (Ver : Integer) : String;
  Begin
    Result := IntToStr (         Ver shr 24) +'.'+
              IntToStr ($FF and (Ver shr 16))+'.'+
              IntToStr ($FF and (Ver shr  8))+'.'+
              IntToStr ($FF and  Ver);
  end;
 
end. {K8055}
 

[marcov]

@Markov:
Dass sich @fpGUIcoder nur nicht genug anstrengt, kann ich nicht erkennen. Wenn die genannten codes nicht weiter helfen scheint es mit der Kompatibilität doch nicht so weit her zu sein.

Der FPC Textmode IDE linkt den ganzen mingw GDB ein. Es ist also möglich. -> man konnte sich einmal packages/gdbint/* ansehen.

Soweit ich mich mit freepascal auskenne, geht die alias Direktive nicht im Interfaceteil. Und die External Definitionen der Pascal Funktionen befinden sich im Interfaceteil.

public alias benoetigt man um pascal funktionen an C bereit zu stellen. external definitionen um C prozeduren zu benutzen.

Wenn ich mir dann noch das Problem mit dem Underscore anschaue und er schon alles mögliche, womöglich noch andere Direktiven getestet hat und nicht weiter kommt, das kann er sich wohl "anstrengen" wie er will, aber nicht zum Ziel kommen.

also er muss procedure xx; external name '_xx'; typen. Das ist ja schrecklich.

So ein programmiersprachenübergreifendes Problem hatte auch ich schon mal. Ich hatte mich damals für das Umschreiben des Codes entschieden.

Ich hatte mir vom Anonymus Kollectiv etwas mehr gedacht. Sicher binär Datei Architectur hoert zu Hackerkultur dazu hoffe ich? Oder sind es alle Scriptkiddies heute?

[Socke]

Daher muss ich fragen, wie denn mein Demo Beispiel aussehen soll, um besser verständlich zu sein.

Zip Datei mit:

• Lazarus-Projekt
• Deine Unit
• C-Quelltext
• *.a und *.o Dateien der C-Datei

Damit kann dann jeder deine Unit selbst compilieren und linken und bei Bedarf den C-Quelltext neu übersetzen.

[marcov]

Wenn ich wüßte wie dieses "einfache Beispiel" aussehen könnte?

Wenn ich das alles so lese würde ich vorschlagen

1. erst mal ein einfaches vorbild in C mit mingw zu kompilieren bis .o und dann mit FPC zu verbinden, bevor man große unbekannte Bibliotheken versuch zu verlinken.

2. Wenn das klappt schau dich den OpenGEM Bibliotheken an mit mingw tools wie objdump/nm/file usw. Sind die wirklich im win32 mingw 32-bit objekt format?

Als FPC core mitglied ist mir nichts bekannt über OpenGEM im FPC verband. Vielleicht ein mitglied (Tomas, Pierre oder Karoly/Charlie ) individuell.

[fpGUIcoder]

Wenn ich wüßte wie dieses "einfache Beispiel" aussehen könnte?

also er muss procedure xx; external name '_xx'; typen. Das ist ja schrecklich.

Hab ich gemacht, aber dann ist plötzlich "xx" das undefinierte Symbol.

Wenn ich das alles so lese würde ich vorschlagen

1. erst mal ein einfaches vorbild in C mit mingw zu kompilieren bis .o und dann mit FPC zu verbinden, bevor man große unbekannte Bibliotheken versuch zu verlinken.

Werde ich in der nächsten Zeit mal machen. Falls ich mit der Kommandozeilenversion nicht klar komme, hab ich mir wxDevC++ runter geladen und installiert. Damit kann ich das dann tun.

2. Wenn das klappt schau dich den OpenGEM Bibliotheken an mit mingw tools wie objdump/nm/file usw. Sind die wirklich im win32 mingw 32-bit objekt format?

Objdump ist ein guter Tipp. Hab ich bei den binaries von Djgpp gesehen.

Werde dann aber bei AuraGUI oder Vorgänger OzoneGUI bleiben, da gefällt mir der Fensterstil besser. Und diese GUI's laufen neben DOS auch unter Windows und Linux. Möchte den Windows Comfort auch nicht mehr missen, aber wenn DOS (go32) (djgpp) schon noch unterstützt werden und noch dazu mit Freedos dieses in die Jahre gekommene Betriebssystem sogar neu aufgelegt wird, möchte ich dafür auch eine anständige GUI sehen. GEM sieht mir da zu altmodisch aus. Obwohl die farbige Variante schon bedeutend besser aussieht als die ursprüngliche Schwarzweiß Version. In C/C++ gibt es gute GUIs für DOS, leider aber nicht mehr in Pascal. Da ich aber ansonsten auch bei Windows angekommen bin, ist dies mein zweites Argument für AuraGUI oder Vorgänger OzoneGUI, weil diese zusätzlich unter Windows und Linux laufen.

Als FPC core mitglied ist mir nichts bekannt über OpenGEM im FPC verband. Vielleicht ein mitglied (Tomas, Pierre oder Karoly/Charlie ) individuell.

Auch gut, vielleicht kommt die Idee ja wirklich individuell von Thomas, Pierre oder Karoly. Im Zweifelsfall gilt es dann also diese von meinem Ansinnen zu überzeugen. Zumal die AuraGUI auch mit Freedos ausgeliefert wird.

Kann den Artikel nicht mehr finden, wo von diesem Plan die Rede war. Ist auch egal, ich liefere die AuraGUI, die Originalquellen stehen unter GPL, von daher passt das also. Nur sind die halt nicht Pascal. Aber das kann sich ja ändern.

[fpGUIcoder]

@Socke:

Ok, da will ich mal das Lazarusprojekt hoch laden. Neben den .h Dateien und der Datei utext.c habe ich auch die Datei utext.o mit hochgeladen und paar Bibliotheken, die nur zur Sicherheit, ich glaube nicht, dass die auch gebraucht werden zur Übersetzung.

Das Projekt ist die Datei test.lpr

Da hoffe ich dann mal, klären zu können, ob eine Neuübersetzung des c-Codes unausweichlich ist oder ob es eine Chance gibt, diesen Code zu linken.

[marcov]

@Socke:

Ok, da will ich mal das Lazarusprojekt hoch laden. Neben den .h Dateien und der Datei utext.c habe ich auch die Datei utext.o mit hochgeladen und paar Bibliotheken, die nur zur Sicherheit, ich glaube nicht, dass die auch gebraucht werden zur Übersetzung.

Das Projekt ist die Datei test.lpr

Da hoffe ich dann mal, klären zu können, ob eine Neuübersetzung des c-Codes unausweichlich ist oder ob es eine Chance gibt, diesen Code zu linken.

FPC generiert ein utext.o, der dein 2012 utext.o ueberschreibt

C's utext.o nach utextc.o umbenannt , dund $L der ebenso modifiziert.

Dann:

Free Pascal Compiler version 3.0.0 [2015/11/16] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
Compiling utext.pp
Linking test.exe
test.lpr(20,1) Error: Undefined symbol: _AddSymbol
test.lpr(20,1) Error: Undefined symbol: _toupper
test.lpr(20,1) Error: Undefined symbol: _tolower
test.lpr(20,1) Error: Undefined symbol: _DebugCheckPtr
test.lpr(20,1) Error: Undefined symbol: _malloc
test.lpr(20,1) Fatal: There were 5 errors compiling module, stopping
Fatal: Compilation aborted
Error: C:\FPC\3.0.0\bin\i386-Win32\ppc386.exe returned an error exitcode

D:\testing\97>

Ich denke das sind C RTL Proceduren die in utextc.o genutzt werden. Aber es gibt kein C RTL Bibliotheken in dieses Archiv "?

[fpGUIcoder]

Danke erst mal für die bisherige Hilfe. Da ist es ja kein Wunder, dass der Compiler die C Funktionen nicht mehr gefunden hat.

Aber:

Nein, die Standardbibliotheken sind nicht mit im Paket der Aura GUI enthalten. Ich hoffe mal, dass da die Bibliotheken aus DJGPP für DOS, für Windows die aus MInGW benötigt werden. Für Linux dann diejenigen der Linuxversion des GCC Compilers.

Da werd ich mal die Übersetzung unter Hinzufügung der wahrscheinlich zusätzlich benötigten Bibliotheken erneut testen.

[marcov]

Danke erst mal für die bisherige Hilfe. Da ist es ja kein Wunder, dass der Compiler die C Funktionen nicht mehr gefunden hat.

Aber:

Nein, die Standardbibliotheken sind nicht mit im Paket der Aura GUI enthalten. Ich hoffe mal, dass da die Bibliotheken aus DJGPP für DOS, für Windows die aus MInGW benötigt werden.

DJGPP hat sich in die letzten Monate erneuert mingw jedes Viertel oder so. Ja vielleicht sind die "noch" Kompatibel, aber es besser dies direkt beim Build zu sichern.

Meiner Meinung nach, alte Kram raus werfen (ist das auch eine Redensart in Deutsch?), und am schnellsten selbst Builden.

[fpGUIcoder]

@marcov:

Gibt es irgendwo eine Doku darüber, welche Funktionen, Prozeduren und Methoden in Klassen in welcher Bibliothek zu finden sind. Analog zur Pascal-Doku, die sagt, in welcher unit der Bezeichner (Funktion, Prozedur, Methode, ... ) zu finden ist.


Welche MinGW Standardbibliotheken hast Du zur Übersetzung meines Beispiels hinzu gelinkt?

Ich besitze MinGW 4.7.1

und

die aktuelle Version.

Welche Bibliotheken aber muss ich da installieren. Ich benutze den grafischen Instaler, mit der Baumstruktur links, die die Auswahl aller Pakete anthält und rechte die Liste mit den Bibliotheken und sonstigen Dateien, die zum ausgewählten Paket gehören.

Ich will da jetzt nur das installieren, was ich für die Übersetzung hier brauche.


Ja, "alten Kram rauswerfen", ist Deutsch.

Allerdings möchte ich, dass die Übersetzung und spätere Verwendung erst mal überhaupt funktioniert. Im Zweifelsfall eben mit alten Bibliotheken, die dann in der Distri halt mitgegeben werden müssen.

Anders bei der Windows und Linux Version. Aber auch da interesseiert mich zuerst mal die funktionierende Übersetzung und spätere Verwndbarkeit. Da kommen eh wieder neue Widgetsets, die dann gerne mit den neuen Teilen übersetzt werden können.

Meine Version der Aura-GUI enthält die DJGPP-Version vom 08.03.2012, die dort Bestandteil der Aura-GUI Distribution ist.

Wenn alle Stränge reißen, will ich ebenso die alte Version der Bibliotheken mitliefern, damit die Übersetzung klappt. Es sei denn, die Übersetzung funktioniert auch mit den neuen Bibliotheken und die GUI funktioniert dann auch wirklich.

[AndreasMR]

Hallo zusammen,

ich bin ja (noch) in anderen Programmiersprachen besser zuhause als in FreePascal/Lazarus.

Vor einem halben Jahr habe ich mal für eine andere Programmiersprache ein Tutorial geschrieben, mit dem Quellcode in C in ein Projekt einfließt, das in einer anderen Programmiersprache geschrieben ist.

Dort habe ich herausgefunden, dass der C-Quellcode in eine .so (shared object) compiliert wird - nicht in eine .o-Datei. Diese .so-Datei wird dann "ganz normal" dazugelinkt.

Das Kommando, um aus C-Quellcode eine s.o-Datei zu erzeugen ist:

Code: Alles auswählen

 
cc ­-c ­-fPIC bitcount.c ­-o bitcount.o
cc bitcount.o -­shared -­o mylib.so
 

oder in einem Schritt

Code: Alles auswählen

 
cc -shared ­-o mylib.so -­fPIC bitcount.c
 

Beste Grüße

Andreas

[marcov]

@marcov:

Gibt es irgendwo eine Doku darüber, welche Funktionen, Prozeduren und Methoden in Klassen in welcher Bibliothek zu finden sind. Analog zur Pascal-Doku, die sagt, in welcher unit der Bezeichner (Funktion, Prozedur, Methode, ... ) zu finden ist.

1. Ja, google

2. Es gibt "man" aber der beschreibt nur Symbole die für End-nutzer Programmierer nutzen sein, nicht interne Symbole.

Meistens googlen und dann kommt man auf Seiten über C Linking Problemen, und da muss man versuchen von Symptom zu Grund zu kommen. Es hilft die basis Bibliotheken eines C Programms benennen zu können, und dafür ist es oft nützlich der Verbose Output vom (C) kompiler/linker zu studieren. (wie FPC prt0.as system.o als basis hat die überall herein gelinkt werden, aber C hat mehr Komponenten)

Das ist einfach Basiswissen das man braucht um Linking Problemen zu lösen.

Ich habe keine Ahnung von mingw und djgpp installation und betreiben im Praxis.