Linker error code: 1 [XE7]

[RWarnecke]

Hallo zusammen,

bei jedem Start von einer Android App im Debug-Modus bekomme ich die folgende Fehlermeldung :

Zitat:

[DCC Error] E2597 D:\PlatformSDKs\android-ndk-r9c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-ld.exe: error: cannot open L: No such file or directory
[DCC Fatal Error] F2588 Linker error code: 1 ($00000001)

Wenn ich dann meine DCU und BUILD-Dateien lösche, muss ich danach einmal neu compilieren und dann kann ich auch die App auf dem Nexus 5 wieder starten. Kennt jemand diese Meldung und wenn ja, wie kann ich hier Abhilfe schaffen ? Oder ist es ein Bug der IDE ?

[RWarnecke]

*push* Hat denn keiner eine Idee ? Ich habe auch schon die Projektdatei komplett neu angelegt, leider keinen Erfolg.

[mensch72]

"D:\PlatformSDKs\android-ndk-r9c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-ld.exe"

1. Frage: Ist die Datei denn wirklich da?
2. Frage: Wurden alle Verzeichnisse im SDK-Manager unter Optionen geprüft, sodass dort keine (gelben) Ausrufezeichen mehr sind?

Bei mir läuft alles mit 4.4.2 und Installation in Standardverzeichnissen. Hier mit "D:\.." muss unter Optionen bei Android SDK's doch garantiert erst manuell dem RadStudio Projekt gesagt werden, wo bestimmte Sachen sind(es gibt dort 3 Tab-Reiter!).

EDit:
..."cannot open !!L!! No such file or directory"...

Kann es sein das für das Beta Android "L" noch nicht alles da ist?
Schonmal mit normalen "alten" Androidversionen, also <4.4.4 probiert ?

[RWarnecke]

Hallo und danke für Deine Antwort.
Nun zu Deinen Fragen :

Zitat:

Zitat von mensch72 (Beitrag 1271523)

1. Frage: Ist die Datei denn wirklich da?

Jepp, die Datei ist da.

Zitat:

Zitat von mensch72 (Beitrag 1271523)

2. Frage: Wurden alle Verzeichnisse im SDK-Manager unter Optionen geprüft, sodass dort keine (gelben) Ausrufezeichen mehr sind?

siehe Anhang, dort sind die drei Reiter von meinem SDK-Manager.

Zitat:

Zitat von mensch72 (Beitrag 1271523)

EDit:
..."cannot open !!L!! No such file or directory"...

Kann es sein das für das Beta Android "L" noch nicht alles da ist?
Schonmal mit normalen "alten" Androidversionen, also <4.4.4 probiert ?

Ich habe bewusst nichts umgestellt. Wie ich schon in meinem ersten Beitrag schrieb :

Zitat:

Wenn ich dann meine DCU und BUILD-Dateien lösche, muss ich danach einmal neu compilieren und dann kann ich auch die App auf dem Nexus 5 wieder starten.

Passiert auch auf einem Nexus 7.Es funktioniert ja alles, wenn keine Build und DCU Dateien da sind. Nur ein nochmaliges Kompilieren oder Starten spuckt die Meldungen aus Beitrag #1 aus.

[mensch72]

bleiben drei Sachen:
1. ein ziemlich altes 2013 Java
2. keine Standardverzeichnisse
3. der ADB Treiber und die Windows Version


Da ich wegen der Treiber eh ein paar "Installationsversuche" mit verschiedenen Windowsversionen machen muss, schau ich mal ob es da auftritt wenn alles als Standard installiert wird(Win7SP1x64, Win8x64 und Win811x64). Als JavaVersion incl. SDK nehme ich die neuste (Version 7 Update 67).

An ADB 64bit Treibern versuche ich alles von "Universal" bis handgepatchte PID's. Mit Win7x64 geht sicher alles, unter Win811 werden (angeblich) die Geräte nicht erkannt... ich bin gespannt.

Ich werde alles "clean" separat unter VMwareESXi installieren und testen. Neben der lokalen normalen Arbeitslizenz gibt es ja mittlerweile die Trailinstallationen zum Experimentieren.

[canoniac]

Hi,
ich bekomme in etwa den selben Fehler. Hast du herausfinden können woran es liegt?

[RWarnecke]

Zitat:

Zitat von canoniac (Beitrag 1271963)

Hi, ich bekomme in etwa den selben Fehler. Hast du herausfinden können woran es liegt?

Nein, bis jetzt noch nicht, verliere aber auch gerade irgendwie die Lust danach zu suchen und arbeite mich gerade ins Android Studio ein.

[canoniac]

Schade :? ich weiß auch nicht mehr weiter. Zumal ich nicht einen einzigen build hinbekomme.

[RWarnecke]

Auch nicht, wenn Du die DCU's und das BUILD-Verzeichnis komplett löscht ?

[canoniac]

Leider nein. Ich habe in meiner Fehlermeldung auch stehen : cannot find -lnodave

vielleicht eine Idee wieso die nicht gefunden wird?

Okay :D frage ich anders. Wo sollte die Datei denn stehen? Bzw muss ich irgendwo den Pfad angeben oder in ein bestimmtes Verzeichnis kopieren?

[Dabei-seit-Turbo-Pascal-2]

Hallo,

ich ärger(t)e mich auch gerade mit dem "... androideabi cannot open L"-Fehler herum und bin dabei auf diesen Thread gestoßen.

Der Fehler ist bei mir verschwunden, nachdem ich das ganze Projekt in ein neues Verzeichnis abgespeichert habe.

Zu den Details: Ich nutze RAD XE7 in einem virtuellen Windows 8.1. Das läuft mit Parallels auf einem Mac. RAD XE7 und alle SDKs sind mit den Default-Pfaden auf dem virtuellen Laufwerk C: installiert. Das Projekt war in einem PSF-Laufwerk W: (PSF = Parallels Shared Folder = Verzeichnis auf dem Mac im Mac-Dateisystem, welches über Laufwerksbuchstaben in Windows gemappt ist, also ähnlich einem Netzwerklaufwerk) gespeichert und damit hatte ich den "L"-Fehler.

Nachdem ich das Projekt auf XE7 heraus mit "Projekt speichern unter..." auf Laufwerk C: gespeichert habe, ist der Fehler weg.

Vielleicht gibt es ein Problem, wenn unterschiedliche Laufwerksbuchstaben im Spiel sind oder ein Nicht-NTFS-Dateisystem.

Hilft das weiter?

[RWarnecke]

Hallo,

danke erstmal für Deine Antwort.

Zitat:

Zitat von Dabei-seit-Turbo-Pascal-2 (Beitrag 1272541)

Vielleicht gibt es ein Problem, wenn unterschiedliche Laufwerksbuchstaben im Spiel sind oder ein Nicht-NTFS-Dateisystem.

Das ist ja wohl nicht war. :shock: Sowas habe ich noch nicht erlebt. Ich kann es nur bestätigen. Sobald das Projekt auf einer lokalen Festplatte der Parallels VM liegt, bekomme ich auch nicht mehr den Fehler. Ich habe die gleiche Konfiguration wie Du. Welche Parallels Version hats Du ? Ich habe die Parallels Version 10.0.2 auf MacOSX 10.9.5.

Nachtrag:
Auch ein mehrfaches Kompilieren des Projektes auf der lokalen VM-Platte und dann wieder zurückspielen auf das PSF-Laufwerk vom Mac bringt keine Besserung. Es taucht der Fehler wieder auf.

[mensch72]

...

[mensch72]

Mit VMware 9 oder 10 (Fusion,Workstation oder ESXi) klappt die SharedFolder Freigabe ist es auch nicht perfekt deshalb immer alles "lokal" oder notfalls per echter Netzwerkfreigabe auf/zu einem WindowsServer.

Mit VMware-VM und Win7x64 klappt alles 1:1 OutOfTheBox. Mit Parallels hab ich keine Erfahrung und ich betreibe die VM's auch andersherum... also unter Windows eine Win7-VM und eine OSx-VM(manche behaupten MAC-VM ohne Mac sei "böse")

[RWarnecke]

Ich habe die gleiche Konstellation mit XE6 und da hat alles funktioniert.

[kbor]

Meine Deutsch ist sehr slecht. So ich gebrauche English.

I have the same error with XE7, for iOS and Android.

The first time build is ok. Then I change something, so compiler needs to recompile, and then I get this message for iOS:
[ld Error] ld: file not found: L

The only thing that helps is to first Clean the project en then Build (Building without Clean does not help).
With Android same behaviour, the compiler cannot find "something' starting with L:.

I have a virtual machine on Mac running Windows 7.
My projects and all sources are on a shared directory outside the virtual machine.

I discovered the following:

When I create a new project and save in on the the shared directory then I have the error.

But when I create a new project and save it on the default directory which XE7 suggest, that is in de Documents directory on C (in my case C:\Users\Administrator\Documents\Embarcadero\Studi o\Projects) then I have no error!

I hope this answer can help and I am curious if you have same behaviour.

[kbor]

Ich habe nicht gut die Antworten gelesen. Weil "Dabei-seit-Turbo-Pascal-2" dasselbe has geschrieben.
Sorry for not reading the answers good, because "Dabei-seit-Turbo-Pascal-2" already described same situation and solution.

[RWarnecke]

Hier ist der entsprechende QC-Eintrag dazu.

Here is the QC-Entry.

[eddie11]

Hi allerseits,

gibts da schon eine Lösung? Ich habe soeben auf Parallels 10.x upgedatet und habe jetzt auch diesen L-fehlt-Fehler. Bei mir liegen die Projekte auch in einem PSF.
Wie habt ihr das gelöst, bzw. welchen Workaround nutzt ihr?

[RWarnecke]

Zitat:

Zitat von eddie11 (Beitrag 1276844)

Wie habt ihr das gelöst, bzw. welchen Workaround nutzt ihr?

Ich weiß, dass Dir meine Aussage nicht weiterhelfen wird. Aber ich habe mittlerweile meine komplette Entwicklung für Android und iOS auf die Herstellertools (Android Studio & XCode) umgebaut. Ich habe keinen Bock mehr.

Das einzigste was Du machen kannst, ist Deinen Sourcecode auf eine Platte in Deiner VM zu legen. Dann funktioniert es wieder. Es hängt lediglich nur an diesem PSF-Share zum Mac.

[eddie11]

Zitat:

Zitat von RWarnecke (Beitrag 1276852)

... ich habe mittlerweile meine komplette Entwicklung für Android und iOS auf die Herstellertools (Android Studio & XCode) umgebaut. Ich habe keinen Bock mehr..

ok, das scheint ja kein Workaround zu sein, sieht eher nach 'ner endgültigen Lösung aus...

[eddie11]

also ich habe das wie folgt gelöst:

zunächst habe ich alles direkt in die VM auf c:\Tralala... verschoben, das hat funktioniert, ich konnte mehrmals compilieren, ohne immer den Ziel-Ordner löschen zu müssen. Aber: nach jeder Änderung hat das anschließende TimeMachine-Backup die komplette VM gesichert - das sind dann jedes Mal 100 GB, das dauert mir zu lange

Ich habe jetzt eine echte Netzwerkfreigabe (nicht über psf) auf dem Mac eingerichtet, diese Freigabe benutze ich für meine Delphi-Projekte - es gibt diese Linker-Fehlermeldung nicht mehr, und TimeMachine sichert wirklich nur die geänderten Daten.

[Dabei-seit-Turbo-Pascal-2]

Zitat:

Zitat von eddie11 (Beitrag 1276979)

Ich habe jetzt eine echte Netzwerkfreigabe (nicht über psf) auf dem Mac eingerichtet, diese Freigabe benutze ich für meine Delphi-Projekte - es gibt diese Linker-Fehlermeldung nicht mehr, und TimeMachine sichert wirklich nur die geänderten Daten.

Hallo, wollte nur kurz bestätigen, dass die Lösung von eddie11 auch bei mir funktioniert. Der selbe Verzeichnisbaum auf dem Mac ist einmal als U: über 'PSF' und einmal als V: über '\\NameDesMac' in die VM gemountet. Öffne ich in XE7 das Projekt auf U: gibt es den "L-Fehler", öffne ich auf V:, geht es.

Ergänzung: Musste leider feststellen, dass der Zugriff über Netzwerkfreigabe viel langsamer ist: Unter XE6 benötigt das Erzeugen eines Win32-VCL-Projektes 25 Sekunden über die Netzwerkfreigabe, aber nur 7 Sekunden über das PSF-Laufwerk! Ich werde daher nur meine Android-Projekte über Netzwerkfreigabe laufen lassen und alles andere auf PSF lassen (was seit über einem Jahr auch problemlos funktioniert).

Warum nicht alles auf C: (in der VM)? Nun, ich möchte die virtuelle Festplatte der VM so klein wie möglich halten und möglichst viele Dateien direkt im Mac-Dateisystem ablegen, wo sie von Time-Machine völlig streßfrei im Stundentakt gesichert werden.

[Sherlock]

Jetzt muß ich doch auch noch meinen Senf zu diesem alten Thema geben. Ich stand natürlich vor dem gleichen Problem mit meiner Parallels Lösung. Ich wollte jedoch keine Verlangsamung akzeptieren und auch keine unnötige Vergrößerung des Win-Images. Uns alten DOS-Hasen hat aber ein cleveres Kerlchen mal den subst Befehl mit auf den Weg gegeben. Damit kann man sich dann eine Batchdatei erzeugen, die dann in den Autostart Ordner gelegt wird. Inhalt ungefähr wie folgt:

Code:

subst f: \\Mac\Home\Documents\Embarcadero\Studio\Projekte\

Schon hat man ein Laufwerk F: und darin liegt alles, was unterhalb von \\Mac\Home\Documents\Embarcadero\Studio\Projekte\ abgelegt wurde, ganz transparent und dennoch Android/iOS/XCode/Linker freundlich.

Sherlock

[Dabei-seit-Turbo-Pascal-2]

Ja der gute alte SUBST-Befehl :thumb:

Ich habe das Problem für mich gelöst, indem ich das Ausgabeverzeichnis des Projektes in den Projektoptionen auf das lokale Laufwerk der Windows-VM eingestellt habe: Projekt -> Optionen -> Delphi Compiler -> Ausgabeverzeichnis -> "C:\Firemonkey\Projektname\$(Platform)\$(Confi g)". Das Projekt selber liegt auf der PSF-Freigabe. RAD-Studio ist mit den Default-Pfaden auf C: installiert. Nachteil dieser Lösung ist, dass für jedes neue Projekt einmalig der Pfad eingestellt werden muss.

Die SUBST-Lösung werde ich aber auch mal ausprobieren. Danke!

[mensch72]

Ich bevorzuge schon immer die Variante mit den separaten Ausgabeverzeichnissen, denn ich mag den Source immer schön getrennt von den Kompilaten.
Es hat mehrere Vorteile:
- die Datensicherungen des SoucreCodes und der Resourcen bleiben viel kleiner und "sauberer"
- die Kompilate können nicht aus versehen Dateien benutzen, welche nur unter Sourcen verfügbar sind
- das man das pro Projekt einstellen muss, sehe ich als Vorteil, denn ich kann 5 Varianten/Versionen meines Projektes parallel als Source/SVN haben, welche bei Übersetzung dann im doch gleichem eingestellen "Produkt-Verzeichnis" laufen, wo ja auch Datenbanken und sonstige Tools&Dateien aus zig Plattformen zusammenkommen.