Compile LINUX , cannot open shlwapi.dll

[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 von 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

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 von Bernhard Geyer:

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?

[Assarbad]

Zitat von 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 ....

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 von 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.

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.

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