Compile LINUX , cannot open shlwapi.dll

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

Sicher dass ihr an der richtigen Stelle sucht?

Nö.

Zitat von himitsu:

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

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