4. OpenSSL bauen mit anderen DLL Namen

OpenSSL bauen mit anderen DLL Namen


  • Ich sitze hier vor der OpenSSL, und ärgere mich schon den ganzen Tag schwarz dass die keine "ordentlichen" Build Files für VS mitliefern.

    Im Prinzip will ich das Ding nur mit Visual Studio bauen, allerdings bräuchte ich einen anderen Output-Namen, nicht bloss "SSLEAY32.DLL" und "LIBEAY32.DLL". Der Grund ist u.A. dass wir bei thirdparty DLLs die Version mit in den Dateinamen aufnehmen, aber auch dass wir diverse Compiler-Einstellungen wie z.B. Release vs. Debug mit in den Dateinamen aufnehmen.

    Nun hab' ich es soweit hinbekommen diverse Dinge zu konfigurieren wie den Include-Pfad zur ZLIB zu setzen sowie den Namen der Import-Library (dafür gibt's ja Configure-Flags), aber der Name des generierten DLL Files lässt sich einfach nicht ändern.
    Das DLL File selbst ist dabei nicht unbedingt das Problem, denn das kann man einfach mit "ren" umnennen. Das generierte .LIB File für die DLL ist allerdings ein Problem, denn selbst wenn ich das umbenenne "verweist" es immernoch auf den alten DLL-Namen.

    Natürlich kann man leicht Änderungen in den entsprechenden Pearl-Files machen, aber ich möchte nicht unbedingt dass Änderungen von Hand nötig sind um ein Update auf eine neuere OpenSSL Version zu machen.

    Was ich mir vorstellen könnte wäre mittels irgendeines Tools den DLL Namen im .LIB File "umzuschreiben", allerdings kenne ich leider kein Tool welches das kann. Darf ruhig auch eine Verkettung mehrerer Tools sein wenns anders nicht geht.

    Der letzte Ausweg den ich noch erkennen kann, wäre in dem während des Build-Vorganges erzeugten .DEF File einfach die Zeile "LIBRARY SSLEAY32" ("LIBRARY LIBEAY32") anzupassen bevor nmake rausgetreten wird. Allerdings verlässt sich das wieder auf "Details" des OpenSSL Build-Vorganges, was ich dann auch wieder nicht so toll finde.

    Also, Frage: weiss jemand einen Weg wie man das (=DLL Namen ändern) hinbekommen könnte?

    ----

    Weiters fände ich gut wenn die generierte SSLEAY32.DLL "by name" gegen die LIBEAY.DLL linken würde, und nicht "by ordinal". Die beiden Libraries müssen zwar immer zusammen gebaut werden, von daher dürfte es nix machen "by ordinal" zu linken, aber mir wäre trotzdem wohler wenn es "by name" wäre. Speziell da die Export-Ordinals anscheinend von einem Script erzeugt werden (*schauder*).

    Bin für jeden Tip dankbar.

    0
  • ?

    Ich weiss ja nicht obs dir hilft, aber ich benutze das hier:
    http://www.slproweb.com/products/Win32OpenSSL.html
    Da sind die statischen und dynamische LIBs schon fertig compiliert. Ich verlinke dann mein Projekt drauf und binde gerade die Funktionen ein die ich brauche. Naja du kannst dir ja ein Projekt zur Erzeugung von einer *.dll anlegen und aus der statischen LIB alles rausziehen was du brauchst dann hast du deinen eigene DLL.

    0

  • Danke für den Tip (genauer: die Tips).

    Die Seite hatte ich schon gefunden. Ist aber auch nicht das was ich möchte. z.B. möchte ich schon wenns geht .pdb Files haben und die dazupassenden Source-Files. Ausserdem eben wie erwähnt die Version und Kennung ob Debug/Release im Dateinamen.

    Was das Erzeugen einer eigenen DLL angeht die halt dann gegen die statische OpenSSL LIB linkt, auch das ist mir schon eingefallen. Halte ich aber für relativ mühsam. Ich will die OpenSSL auch mit der Boost.ASIO verwenden, und ich fürchte dass es da etliche Dinge zu exportieren gäbe damit das klappt. Ansonsten aber keine schlechte Idee 🙂

    0
  • ?

    Mal nachgehackt. Hast du für openssl einen Workspace für das Visual Studio. Den eigentlichen Sourcecode von OpenSSl bekomme ich irgendwie nicht zum laufen. Hab mir zwar Perl installiert, aber mit dem makefile usw klappt das mit dem Kompilieren nicht.

    0

  • Ich habe keinen "Workspace" - zumindest nix was ein normales VS Projekt wäre. Sonst könnte ich ja auch einfach die Output-Filenamen umstellen.

    Bauen mittels des Configure Scripts + "ms\do_masm" + "nmake -f ms\ntdll.mak" funktioniert bei mir aber schon. Musste viel rumsuchen um die zlib schön eingebunden zu bekommen, aber ohne zlib war ganz einfach, und nu gehts auch mit zlib.

    Was ich gerade dabei bin zu bauen ist eine VS Solution die mir das Bauen über perl+batch+nmake automatisiert.

    ----

    Welche Probleme hast du wenn, also wo stellts ihn auch, mit was für Fehlermeldung?

    p.S.: und gib dir mal nen Namen. Wenn das ne längere Konversation wird wäre das schon nett 🙂

    0
  • E

    <- OK Name hier 🙂
    So nun zu meinem Problem, das sich dann auch von selbst gelöst hat nachdem ich den Befehl "ms\do_masm" direkt in der OpenSSl-Root ausgeführt habe und nicht im Verzeichniss "ms". Das Ding hat kompiliert und im Verzeichniss "out32dll" stehen jetzt die DLL und die LIB sowie einige EXE drinnen.

    So, jetzt würde ich mir nur gerne keine Dynamische LIB sondern eine statische LIB mit Hilfe des Sourcecodes erstellen. D.h. irgendwie muss man dann wohl irgendwelche Scriptdateien anpassen und mann erhält dann wenn alles gut geht die LIB z.B: im Verzeichniss "out32lib". Hast du eine Ahnung wie das geht? Mir dem Perl Zeug hatte ich vorher noch nie was zu tun, genausowenig wie die ganzen Kommadozeilen Teile die da wohl irgendwie auf mysteriöse Art und Weise die ganzen *.exe, *.lib etc erstellen. Also wir können uns da auch zusammen durchfummeln wenn du Lust hast.

    0

  • Naja, DAS ist einfach. Bleibt sich alles gleich, bloss rufst du nmake mit einem anderen Makefile auf:

    nmake -f ms\nt.mak

    Das nt.mak wird standardmässig von do_masm miterstellt, das ist also noch relativ einfach.

    Wenn du ne DEBUG Konfiguration haben willst musst du allerdings entweder do_masm.bat anpassen, oder selbst das nötige Perl Script raustreten welches das debug-makefile erstellt:

    perl util\mk1mf.pl debug VC-WIN32 >ms\nt_dbg.mak

    Und dann entsprechend mit nmake -f ms\nt_dbg.mak bauen.
    Das mk1mf.pl Script startest du dabei einfach nach "do_masm" und vor "nmake".

    Aber aufpassen: das mk1mf.pl Script ändert Header-Dateien. Das #define CFLAGS ... wir z.B. geändert. Wenn du also mk1mf.pl debug ... aufrufst, danach aber mit dem release Makefile baust, dann stimmt die CFLAGS Variable nicht mit den wirklichen Compiler-Einstellungen überein.

    Alles sehr doof.

    0
  • E

    Danke für den Hinweis, das hat so geklappt.

    Nochmal zu deinem Problem mit den Namen. Wie du bereits festgestellt hast, musst du lediglich .\ms\libeay32.def, .\ms\ssleay32.def ändern. Um den Build auch mit dem entsprechenden Dateinamen zu erzeugen, noch die Datei .\ms\ntdll.mk unter SSL=ssleay32 und CRYPTO=libeay32 anpassen, dann wars das. Das sind doch eigentlich Änderungen die innerhalb einer Minute durchzuführen sind, was schreckt dich da ab?

    0
Anmelden zum Antworten