Compile LINUX , cannot open shlwapi.dll

[Assarbad]

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

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

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.

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

@ 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 von bernhard_LA:

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

Ist ja nicht ungewöhnlich oder

Zitat von bernhard_LA:

@ 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 von bernhard_LA:

@ 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 von bernhard_LA:

@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 von bernhard_LA:

@ 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 von bernhard_LA:

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 von jaenicke:

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.

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