Compile LINUX , cannot open shlwapi.dll

[bernhard_LA]

beim compilieren für LINUX bekomme ich diese Fehlermeldung :

Delphi-Quellcode:

[DCC Error] E2597 C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\ld-linux.exe: error: cannot open shlwapi.dll: No such file or directory
[DCC Fatal Error] F2588 Linker error code: 1 ($00000001)

wie löse ich dieses Problem , wer ist für diese DLL verantwortlich ?

[jaenicke]

Die DLL gehört zu Windows. Wenn diese bei dir nicht vorhanden ist, dürfte eigentlich Windows kaum noch funktionieren. Von daher ist bei dir wohl eher der Systempfad defekt.

Prüfen kannst du das indem du die Umgebungsvariable PATH prüfst oder mit dem Process Monitor prüfst wo diese DLL gesucht wird und was damit passiert.

[hoika]

Hallo,
fang an mit einem leeren Projekt,
dann deine Units (ohne Code) nach und nach einbinden.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1462889)

Die DLL gehört zu Windows. Wenn diese bei dir nicht vorhanden ist, dürfte eigentlich Windows kaum noch funktionieren. Von daher ist bei dir wohl eher der Systempfad defekt

Er will für Linux compilieren. Und da kann der Linux-Compiler nix mit *.dlls anfagen.
Hat wohl irgendwo eine Usage auf eine reine Windows-Unit.
Evtl. mal die Compilerwarnung dafür aktivieren.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1462901)

Er will für Linux compilieren. Und da kann der Linux-Compiler nix mit *.dlls anfagen.
Hat wohl irgendwo eine Usage auf eine reine Windows-Unit.

Sicher, dass an der Stelle bei einer entsprechenden Unit auf die DLL direkt zugegriffen wird? Und dass die Meldung dann so aussieht?
Wenn ich für Windows kompiliere, muss eine eingebundene DLL ja beim Kompilieren auf dem System gar nicht vorhanden sein (wozu auch).

Für mich sieht es eher so aus als ob der Linuxcompiler die DLL für das Ermitteln von Pfadangaben oder ähnlichem selbst versucht zu laden.

Aber es kann natürlich alles sein.

[bernhard_LA]

welche windows unit könnte ich in meinen source code eingebunden haben damit die shlwapi.dll beim compilieren aufgerufen wird ?
ich konnte ja schon mal für LINUX und Windows kompilieren .....

[hoika]

Hallo,
siehe mein Post (#3).
Wir kennen deinen Quellcode nicht.

Klappt denn ein komplett leeres Programm?

[bernhard_LA]

@hoika

< 1 Mio Zeilen code
~ 1000 units die sich x mal untereinander einbinden .............



wenn ich wüsste was die dll macht könnte ich den Suchraum einschränken ....

[Delphi.Narium]

shlwapi

https://docs.microsoft.com/en-us/win...2/api/shlwapi/

https://www.geoffchappell.com/studie.../api/index.htm

Grob: Kappselt gaaaaanz vieeeeel von der Windows-Api.

Dürfte für Linux absolut uninteressant sein. Da müssen dann die entsprechenden "Linux-Gegenstücke" genutzt werden.

Mal nur 'ne Vermutung:

Irgendwo fehlt ein Kompilerschalter, der für die Unterscheidung zwischen Windows und Linux zuständig ist.

EmbeddedWB nutzt die Dll z. B., ebenso die JCL.

Achso: Es gibt auch 'ne Unit shlwapi (Zumindest in den Quellen zu https://www.delphipraxis.net/203147-...er-delphi.html).

Ist die irgendwo unter Deinen 1000?

[himitsu]

Sicher dass ihr an der richtigen Stelle sucht?
Beim Kompilieren werden die eingebundenen .DLL (Windows) bzw. .SO (Linux) niemals geladen, also ist es "erstmal" egal falls im Quellcode irgendwo eine Referenz darauf stünde, weil z.B. ein IFDEF fehlt.

Die Fehlermeldung in #1 sieht eher so aus, als wenn sie aus der ld-linux.exe kommt.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1463036)

Sicher dass ihr an der richtigen Stelle sucht?

Nö.

Zitat:

Zitat von himitsu (Beitrag 1463036)

Beim Kompilieren werden die eingebundenen .DLL (Windows) bzw. .SO (Linux) niemals geladen, also ist es "erstmal" egal falls im Quellcode irgendwo eine Referenz darauf stünde, weil z.B. ein IFDEF fehlt.

Prinzipiell erstmal richtig.

Zitat:

Die Fehlermeldung in #1 sieht eher so aus, als wenn sie aus der ld-linux.exe kommt.

Dagegen spricht aber die Fehlernummer: E2597
Meine Interpretation des Fehler geht dahin, dass der Linker meint, er müsse die DLL beim Linken mit einbinden (z. B. als Resource oder was auch immer), auch wenn das eigentlich vollständiger Humbug sein dürfte.

Was passiert denn, wenn ein neues Projekt für Linux kompiliert werden soll. Tritt der Fehler dann auch auf?
Müsste ja eigentlich, wenn die ld-linux.exe die DLL für sich selbst, also die eigene Funktionalität, benötigt. (Achso: Muss ja nicht unbedingt sein, dass die DLL grundsätzlich geladen werden muss, sondern nur, wenn 'ne Routine aus ihr benötigt wird. Von daher ist so ein Test auch nicht zwingend verlässlich.)

[hoika]

Hallo,
und noch mal ...
Klappt denn ein komplett leeres (VCL-) Programm?

< 1 Mio.
puh, dann geht das ja ;)
> 1 Mio. wäre in der Tat zu aufwendig

[bernhard_LA]

@

was müsste ich machen wenn

Zitat:

"Fehlermeldung in #1 sieht eher so aus, als wenn sie aus der ld-linux.exe kommt."

[Assarbad]

Zitat:

Zitat von bernhard_LA (Beitrag 1463033)

@hoika

< 1 Mio Zeilen code
~ 1000 units die sich x mal untereinander einbinden .............



wenn ich wüsste was die dll macht könnte ich den Suchraum einschränken ....

Also, als erstes könnte man ein Tool wie ack oder ripgrep einsetzen, oder sogar kommerzielle Werkzeuge wie meinen persönlichen Favoriten PowerGREP (übrigens in Delphi geschrieben!). Letzteres läuft perfekt unter Wine und ist daher bei mir auch auf Linux Werkzeug der Wahl im Klickibuntiland (GUI).

Ach ja (Einfügung): ripgrep läßt sich im Handumdrehen auf dem eigenen Rechner bauen, sofern man sich mit rustup die entsprechende Umgebung installiert (ist lokal im eigenen Profil) und das dann mit cargo baut.

Und wenn sich Delphianer zusammentun, könnte es demnächst sogar Unterstützung in SourceTrail für Delphi geben.

Zitat:

Zitat von himitsu (Beitrag 1463036)

Sicher dass ihr an der richtigen Stelle sucht?
Beim Kompilieren werden die eingebundenen .DLL (Windows) bzw. .SO (Linux) niemals geladen, also ist es "erstmal" egal falls im Quellcode irgendwo eine Referenz darauf stünde, weil z.B. ein IFDEF fehlt.

Die Fehlermeldung in #1 sieht eher so aus, als wenn sie aus der ld-linux.exe kommt.

Tsk tsk tsk ... beim Kompilieren vielleicht nicht. Aber beim Linken brauchste mit dem Linker aus den Binutils auch auf Windows die DLL (bzw. auf Linux die .so). Wie das in der Welt von Delphi umgesetzt ist, oder ob man sich bei bestehenden Projekten bedient hat (Binutils?), weiß ich nicht. Geladen im Sinne von Codeausführung stimmt auch auf Linux; das passiert also nicht. Aber während sich auf Windows Import-Libs eingebürgert haben, in denen bereits die Stubs für den Linker vorliegen, ist es auf Linux Usus, daß der Linker sich diese Informationen direkt aus der .so zusammensammelt. Und ja, dazu wird die .so geladen (wobei der Begriff ja mehrdeutig ist, und ich nicht weiß welche Bedeutung hier von dir gemeint war).

Soweit ich mich entsinne, brachte auch Delphi Werkzeuge mit um den Inhalt (Symbole) von Objektdateien anzuschauen. Man könnte also quasi auch "ganz simpel" mit einem Tool dieser Art die Symbole in eine Textdatei ausgeben lassen und danach mit simpler Textsuche den Verweis auf die shlwapi aufspüren. Ich habe sehr gute Erfahrungen mit Bash for Git, weil dort die Basiswerkzeuge aus den coreutils von GNU beiliegen (also GNU find, grep, awk ...). Damit läßt sich wunderbar bspw. ein Verzeichnis nach Objektdateien durchsuchen und der Dateiname weiterverwursten.

Da der Linker laut Namensgebung vielleicht sogar der von Binutils ist (ld-linux.exe --version), würde ich mal gucken ob nicht vielleicht ein passendes objdump beiliegt. Und falls nicht, könnte man mal auf's Gratewohl per objdump/nm (usw.) auf einem Linux versuchen ob das Format bekannt ist. Da für Linux gebaut wird, gehe ich mal davon aus, daß ein Linux vorhanden ist. :mrgreen:

Letztens habe ich noch andernorts einen Rüffel bekommen (Zitat 2), warum ich mich quasi nicht einfach auf eine Entwicklungsumgebung konzentriere, jetzt sehe ich wieder, daß auch Vielseitigkeit seine Vorteile hat :zwinker:

[jaenicke]

Am sinnvollsten wäre doch erst einmal wie ich in der ersten Antwort geschrieben hatte festzustellen wo eigentlich das Problem liegt. Sprich einfach mal die 5 Minuten zu investieren und mit dem Process Monitor zu schauen was mit der Datei eigentlich passiert. Vielleicht wird die ja schlicht wirklich nicht gefunden, weil der Systempfad kaputt ist oder ähnliches...

[Assarbad]

Zitat:

Zitat von jaenicke (Beitrag 1464583)

Am sinnvollsten wäre doch erst einmal wie ich in der ersten Antwort geschrieben hatte festzustellen wo eigentlich das Problem liegt. Sprich einfach mal die 5 Minuten zu investieren und mit dem Process Monitor zu schauen was mit der Datei eigentlich passiert. Vielleicht wird die ja schlicht wirklich nicht gefunden, weil der Systempfad kaputt ist oder ähnliches...

Also nix für ungut, aber ... wenn man die Windows-Mechanismen zugrundelegt, sieht man daß ...

Zitat:

Zitat von jaenicke (Beitrag 1462889)

Die DLL gehört zu Windows. Wenn diese bei dir nicht vorhanden ist, dürfte eigentlich Windows kaum noch funktionieren. Von daher ist bei dir wohl eher der Systempfad defekt.

... eigentlich nicht sein kann. Wie kommt es, daß ich mich zu dieser "skandalösen" Aussage versteige? Systemverhalten! Die besagte Bibliothek ist dem System bekannt und wird als Section (MMF) bereits vorgehalten. Überprüfen kannst du das ohne Kenntnis des Inhalts von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\KnownDLLs usw. auf einem laufenden System mit meinem ntobjx oder WinObj. Einfach mal unter \KnownDlls und \KnownDlls32 nachgucken und dort sollte seit gefühlter Windows-Steinzeit auch shlwapi.dll immer dabei sein. Normalerweise sollte bei statischen Importen auch noch vor Ausführung von ld-linux.exe das Ding knallen, aber Delay-Load Importe sind natürlich zumindest denkbar. Und der Fehler den der PE-Loader dann wirft, wäre ein anderer als der den wir sehen und käme eben nicht von dem Programm selber (was ja nicht einmal bis zum Start des Main-Threads kommt).

Das mal nachzuschauen ist aber in der Tat billig und schnell getan und ich muß sagen, daß ich beim Schreiben dieser Antwort mehr und mehr deinen Vorschlag unterstütze. Ich will kurz umreißen warum.

Angenommen diese ld-linux.exe linkt gegen die Cygwin-DLL o.ä. dann weiß ich aus eigener Erfahrung, daß die Umgebungsvariablen, insbesondere der Pfad zwischen Backslash und Slash hin- und herkonvertiert werden. Ich hatte bereits selbst denn Fall, daß bei einer großen Anzahl Variablen und großer Größe der einzelnen Werte diese Konvertierung verlustbehaftet war. Bei mir führte dies zu einem Fehler der zum Nichtauffinden einer (Nicht-System-)DLL. Zwar halte ich es aufgrund des oben beschriebenen Systemverhaltens für unwahrscheinlicher, daß überhaupt nach dieser DLL gesucht wird und würde eher davon ausgehen, daß der Linker meint gegen diese DLL linken zu wollen, aber schnell überprüfen ist trotzdem gut.

Sehen sollte man das daran ob die Datei shlwapi.dll in einem Verzeichnis gesucht wird wo die ganzen Objektdateien und Shared Objekts des Zielsystems liegen ("sysroot" im GCC-Jargon). Process Monitor sollte das zeigen.

@bernhard_LA: ich bin also bei @jaenicke. Bitte erst einmal abklären!

Nachtrag: das hier spricht auch eher dafür, daß die Datei gelinkt und nicht in den Prozeß von ld-linux.exe geladen werden sollte.

[bernhard_LA]

@ Check#1

a) die shlwapi.dll ist auf meinem System x mal vorhanden

b) wenn ich meine app anstelle von Target = LINUX auf Target = WIN64 umstelle funktioniert alles bestens


@ Check#2

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlS et\Control\Session Manager\KnownDLLs , hier ist diese dll eingetragen, scheint alles mit meinem System OK zu sein

@ Check#3

andere Programme, weniger Komplex, andere units kann ich weiterhin für LINUX compilieren, PA Server etc ... sieht eigentlich gut aus


@Check#4

ich habe in einer anderen App einen Linker error #1 ohne Angabe einer DLL erzeugt ...

@ Check#5

über {$IFDEF ...} kann ich zwischen FMX und VCL , Firedac und ADO .... und diversen Featuren hin und her switchen,
ich vermute ganz stark, irgendwo ist halt der Link auf eine Win only DLL, Klasse eingebaut , eine unit steht im verkehrten ifdef block, nur die Suchstrategie
hat bisher nicht zur Lösung geführt :-(

[Assarbad]

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

@ Check#1

a) die shlwapi.dll ist auf meinem System x mal vorhanden

Ich zähle viermal in deinem Screenshot, wobei einmal 32-bit und einmal 64-bit dabei ist und die vermutlich als Hardlinks mit denen unter SxS (side-by-side) verknüpft sind. Also sieht so aus als hättest du zwo. Die MUI-Dateien sind Sprachdateien.

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

b) wenn ich meine app anstelle von Target = LINUX auf Target = WIN64 umstelle funktioniert alles bestens

Ist ja nicht ungewöhnlich oder :zwinker:

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

@ Check#2

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlS et\Control\Session Manager\KnownDLLs , hier ist diese dll eingetragen, schein alles mit meinem System OK zu sein

Jupp, wer spielt da auch schon dran rum. Vermutlich sind die ACLs auch restriktiv gesetzt.

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

@ Check#3

andere Programme, weniger Komplex, andere units kann ich weiterhin für LINUX compilieren, PA Server etc ... sieht eigentlich gut aus

Ich weiß - weil ich das Problem beim Weggang von Delphi auch hatte - daß das aus Sicht eines Delphianers kompliziert klingt, aber das Kompilieren ist ja augenscheinlich auch kein Problem, sondern das Linken. Hier versteckt Delphi eine Komplexität (eigentlich verschiedene Schritte) die aber unter der Haube dennoch besteht. Die Unterscheidung ist aber wichtig.

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

@Check#4

ich habe in einer anderen App einen Linker error #1 ohne Angabe einer DLL erzeugt ...

Scheint generisch zu sein, siehe letzter Link in meinem vorherigen Beitrag. Sprich: der Linker wirft diesen gleichen Fehler für mehrere verschiedene Fehlerbedingungen.

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

@ Check#5

über {$IFDEF ...} kann ich zwischen FMX und VCL , Firedac und ADO .... und diversen Featuren hin und her switchen,
ich vermute ganz stark, irgendwo ist halt der Link auf eine Win only DLL, Klasse eingebaut , eine unit steht im verkehrten ifdef block, nur die Suchstrategie
hat bisher nicht zur Lösung geführt :-(

Also wenn du ein paar Tage Zeit hast, habe ich auch wieder ein Studio XE installiert. Aber ob das überhaupt diese Dinge an Bord hat, weiß ich nicht mehr.

Aber schau dir doch mal bitte an, was ich erwähnt hatte. Nach kurzer Recherche (ohne installiertes Delphi) fand ich tdump welches zumindest für Windows-Targets wohl das Werkzeug wäre welches ich mit ...

Zitat:

Soweit ich mich entsinne, brachte auch Delphi Werkzeuge mit um den Inhalt (Symbole) von Objektdateien anzuschauen.

... meinte. Denkbar, daß du bei Linux als Zielsystem aber andere Werkzeuge brauchst. Die Details hatte ich ja schon erwähnt. Ist ja kein Ding mal flott ein kleines Skript zu schreiben mit dem man die Ausgaben von tdump/objdump/nm durchgeht um zu schauen wo die Referenz auf shlwapi herkommt, oder?

[jaenicke]

Zitat:

Zitat von bernhard_LA (Beitrag 1464592)

ich vermute ganz stark, irgendwo ist halt der Link auf eine Win only DLL, Klasse eingebaut , eine unit steht im verkehrten ifdef block, nur die Suchstrategie
hat bisher nicht zur Lösung geführt :-(

Auch das würdest du im Process Monitor eventuell eingrenzen können, denn damit siehst du welche Units bzw. beim Linken welche kompilierten Units vor dem Fehler gelesen wurden. Wenn du Glück hast, ist das die, die den Fehler verursacht, wenn es daran liegt.

Wie der Linux-Linker arbeitet weiß ich nicht, es kann natürlich auch sein, dass man das so nicht sieht, aber einen Versuch ist es wert...

[Assarbad]

Zitat:

Zitat von jaenicke (Beitrag 1464597)

Auch das würdest du im Process Monitor eventuell eingrenzen können, denn damit siehst du welche Units bzw. beim Linken welche kompilierten Units vor dem Fehler gelesen wurden. Wenn du Glück hast, ist das die, die den Fehler verursacht, wenn es daran liegt.

Wie der Linux-Linker arbeitet weiß ich nicht, es kann natürlich auch sein, dass man das so nicht sieht, aber einen Versuch ist es wert...

Guter Überblick hier. So arbeiten eigentlich - grob - alle Linker (jetzt bis auf die ELF-Spezialfälle). Leider sammelt sich ein Linker das eigentlich zu einem Gesamtbild. Will heißen der guckt erstmal nach Symbolen und die werden erst am Ende aufgelöst (was wiederum dazu führen würde, das ProcMon nicht klappt, aber versuchen würde ich es allemal).

Ich finde daß jaenickes Idee einen Versuch wert ist. Im Vergleich zum bisher betriebenen Aufwand ist das minimaler Aufwand, aber könnte ne Menge Zeit sparen.

[bernhard_LA]

mit procmon konnte ich einen ersten Fehler tatsächlich finden, Active X stand in einer unit.....; Diese unit ist nun entfernt, nur leider immer noch der selbe Fehler ,
vermutlich aus einer weiteren unit.

Delphi-Quellcode:

[DCC Error] E2597 C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\ld-linux.exe: error: cannot open shlwapi.dll: No such file or directory

Nur hilft mit procmon aktuell nicht weiter, hier der aktuelle dump, die letzten Zeilen bis zum Abbruch :-(

[hoika]

Hallo,
such mal per Grep nach SH*, z.B. SHDeleteKey in deinem Code.

Hier
https://docs.microsoft.com/en-us/win...2/api/shlwapi/
ist eine Auflistung aller Funktionen.

PS:
Hattest du denn mal ein neues, leeres Projekt getestet?

[bernhard_LA]

jede Einbindung von Windows units in diesem Stil, speziell ShlObj, unterbunden
via grep shlobj überprüft

Delphi-Quellcode:

  
  {$IFDEF  LINUX}
   Myunit_TRegistry
  {$ENDIF}
  {$IFDEF  MSWINDOWS}
  Registry,
  Windows,
  ShlObj;
  {$endif}

ich kann eine ganz Reihe von anderen Anwendungen weiterhin auch für LINUX deloyen ....

[hoika]

Hallo,
und die shlwapi selber mal per grep gesucht, das ist ja auch eine normale Delphi-Unit?

Vielleicht lungert ja auch nur eine alte DCU bei dir rum?

[Assarbad]

Jetzt verrate doch mal was da sonst noch so in C:\Program Files (x86)\Embarcadero\Studio\20.0\bin rumlungert? Wie ich vorher schon getippt hab, könnte es sich um die Binutils handeln und dann könnte man da mit der Bash for Git rangehen so ala:

Code:

find -type f -name '*.o'|while read fname; do objdump -t "$fname"|tee "${fname##*/}.objdump.txt"|grep -i shlwapi; done

Beschreibung: Finde alle Dateien (-type f) mit einem Namen (-name) der auf '*.o' (vielleicht bei euch *.obj?) paßt und pipe die Ausgabe in eine while-Schleife (while; do ...; done). Lies jede Zeile in die Variable fname (read fname) und führe aus objdump (aus Binutils) und sage diesem alle Symbole auszugeben (-t) die in der Datei "$fname" gefunden werden. Pipe diese Ausgabe in eine Datei die auf dem ursprünglichen Namen basiert (abgeschnittener Pfad) und hänge .objdump.txt dran (die Dateien landen im aktuellen Verzeichnis!). Durchsuche wiederum diese Ausgabe ohne Beachtung von Groß- und Kleinschreibung (-i) mithilfe von grep nach shlwapi ...

Ich habe deutlich mehr Zeit damit verbracht diese Beschreibung einzutippen als den Befehl.

Statt am Ende nach shlwapi zu suchen kann man auch Path und SH suchen ... vielleicht dann lieber mit "grep -Pi" und in Form von '\WPath\w+' bzw. '\WSH\w+' ...

Die ganze Übung kann doch nicht so schwierig sein, solange der Compiler vor dem Linken Objektdateien ausspuckt. Ich habe leider keine so aktuelle Delphiversion zur Verfügung um das erster Hand zu testen.

[bernhard_LA]

Problem gelöst .... der Übeltäter // unit gefunden ..... :P

anstelle von grep die Funktion "suche in Files /directories" von Delphi verwendet, eigentlich ganz einfach :-) alles
und dabei noch 100 Referenzen in diversen Programmstellen auf die unit windows entfernt ,
mit procmon und einem Filter auf id_linux auch noch das eine / andere Problem entdeckt ...

Danke