Compile LINUX , cannot open shlwapi.dll

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