Linker Error: Out of memory
-
Hallo,
ich habe folgendes Problem mit dem RAD Studio XE2 und ilink32.exe (V6.21):
Mein Projekt besteht aus 7 statischen Bibliotheken + Anwendungsprojekt, mit insgesamt etwa 900 Units. Wenn ich alles im Release Modus übersetze treten keine Probleme auf, im Debug Modus steigt der Linker allerdings mit einer "Out of Memory" Fehlermeldung aus. Um das Projekt weiter debuggen zu können übersetze ich nur die relevanten Teilprojekte im Debug Modus und den Rest im Release, das funktionierte auch eine Zeit lang ganz gut. Jetzt bin ich allerdings an einem Punkt, wo das nicht mehr möglich ist, weil eine Bibliothek im Debug Modus einfach zu groß wird (Debug Modus: 760MB, Release 62MB). Das resultierende Executable ist im Debug- und Release Modus etwa 20MB groß.
Hatte jemand von euch ähnliche Probleme und eine Lösung dazu gefunden? Auf der Embarcadero Website findet man keine Email Adresse für technischen Support, auf Antwort einer Email an info@embarcadero.com warte ich seit einer Woche. Ich habe mir auch schon folgenden Thread im Embarcadero Forum durchgelesen, bringe den ulink aber irgendwie nicht zum Laufen (der verschluckt sich irgendwo an Pfadangaben, die entweder mit einem Backslash beginnen oder in Anführungszeichen eingeschlossen sind).
Meine aktuelle "Lösung" besteht darin, für selten benutzte Teile der Bibliothek lokale Einstellungen zu benutzen, die keine Debug Informationen enthalten. Unschön, und absehbar, dass das auch irgendwann nicht mehr reichen wird. Die Bibliothek in Einzelteile zu zerlegen und in mehrere Teilbibliotheken aufzuteilen ist auch keine wirkliche Option. Laut Projektvorgabe muss ich sie als statische Bibliothek zur Verfügung stellen und darf keine DLL erzeugen.
Wäre sehr dankbar, wenn da jemand eine Idee hat, wie man das Problem in den Griff bekommt.Das Problem besteht seit dem BCB6, mit jedem Upgrade (CG2007, XE2) konnte der Linker mit etwas größeren Bibliotheken umgehen, aber jetzt bin ich auch an die Grenzen des Linkers von XE2 gestossen.
-
Zwei Möglichkeiten:
- ULink zum Laufen bringen
- An Embarcadero-Support wendenDie Eröffnung eines Support-Falles ist allerdings wohl kostenpflichtig, wenn ihr nicht den Support & Maintenance-Vertrag habt. Was ULink angeht, so würde ich einfach mal in den Embarcadero-Newsgroups fragen, dort gibt es einiges an Erfahrung mit den Einsteigerproblemen (siehe z.B. hier). Dort wird auch öfter betont, man könne dem Autor einfach eine Mail mit Linkset zukommen lassen, wenn's mal nicht klappt.
-
Danke für die Antwort, habe sowas schon irgendwie befürchtet. Aber ein kostenpflichtiges Ticket für etwas, das der Linker eigentlich können sollte...
.
Irgendwie häufen sich die Gründe für einen Compilerwechsel...
-
DocShoe schrieb:
Irgendwie häufen sich die Gründe für einen Compilerwechsel...
Vermutlich auch bei Embarcadero.
Ich denke, an XE3 (oder meinetwegen auch XE4; wenn sie mehr Zeit brauchen, kommts darauf auch nicht an) wird sich die Sache entscheiden. Wenn es ihnen gelingt, einen modernen Compiler und eine brauchbare Linker-Infrastruktur für Win64 zu präsentieren, wird die Sache sich entspannen, und C++Builder kann wieder konkurrenzfähig werden. Wenn man das wie schon den Mac-Support doch wieder mit BCC/ILINK löst, dann sehe ich wenig Zukunft.
-
DocShoe schrieb:
Irgendwie häufen sich die Gründe für einen Compilerwechsel...
Das dürfte bei einer Anwendung dieser Größe nicht ganz einfach sein. Ist das alles VCL abhängiger Code ?
Wir sind damals mit einer halben Million Codezeilen vom BCB 6 nach VS 2003 gesprungen. Das war schon ein Stück Arbeit, hat die Anwendung aber langfristig vorangebracht.
audacia schrieb:
Ich denke, an XE3 (oder meinetwegen auch XE4; wenn sie mehr Zeit brauchen, kommts darauf auch nicht an) wird sich die Sache entscheiden.
Das sehe ich auch so. Wenn sie bis XE4 nichts entscheidendes verbessern, kann man die Sache vergessen.
-
Da in unserer Firma alle Projekte seit 12 Jahren mit dem Borland/Codegear/Embarcadero RAD Studio entwickelt werden wird er Umstieg wohl eher schwierig. Nicht alles ist VCL Code, die nicht-visuellen Teile sind größtenteils Standard C++. Trotzdem ein Riesenbatzen Arbeit, vor allem, weil man die Tücken und Besonderheiten anderer Frameworks nicht kennt. Das Thema Compilerwechsel kam schon einige Male bei uns auf den Tisch, ist aber wegen der Nicht-Abschätzbarkeit des Aufwands nie ernsthaft in Betracht gezogen worden.
Aber vielleicht kann man kleinere Projekte mit dem Visual Studio abwickeln, um Erfahrungen zu sammeln.
-
DocShoe schrieb:
...
Aber vielleicht kann man kleinere Projekte mit dem Visual Studio abwickeln, um Erfahrungen zu sammeln.Das wäre auch m.E. nach der beste Weg.
Eigentlich schade, das selbst XE2 noch an sowas scheitert, aber wenn einen das Produkt keine andere "Wahl" lässt.
-
audacia schrieb:
...
Wenn man das wie schon den Mac-Support doch wieder mit BCC/ILINK löst, dann sehe ich wenig Zukunft.
...iLink passt doch gut zu Apple
-
Ja, Erfahrungen mit anderen Tools sammeln kann nie verkehrt sein.
In unseren Anwendungen gibt es diverse kleine Hilfsprogramme, teilweise nur für den internen Bedarf. So etwas eignet sich ganz gut für Pilotprojekte.
Auf diese Weise halte ich auch noch eine letzte Brücke zum C++ Builder, mit der Wartung zweier Tools unter XE2, die ursprünglich mit dem BCB 3 entwickelt wurden. Ein paar neuere Sachen sind so mit Qt entstanden.
Bei der Hauptanwendung standen wir damals vor zwei Herausforderungen, einmal mussten zwei Projektteams integriert werden, von denen das eine mit dem BCB 6 und das andere mit VC 6 und MFC arbeitete. Außerdem war die Situation mit der Ankündigung des C++BuilderX auf der VCL-Seite total unklar.
Wir sind dann auf ein in Standard C++ geschriebenes Backend und ein C# Frontend umgestiegen.
-
DocShoe schrieb:
iLink passt doch gut zu Apple
Netterweise ist iLink (bzw. i.LINK) ein Sony-Trademark für FireWire und viel älter als alles iBranding bei Apple
-
@nn
Bei uns lief das auch ähnlich. Wir wollten aber Frontend und Backend in der gleichen Programmiersprache halten. Deswegen, und wegen der (relativen) Plattformvielfalt sind wir auf Qt umgestiegen und bereuen das nicht.
-
Ja, Qt ist auch attraktiv, im Moment jedenfalls deutlich mehr als der "brennende Affe" im Builder XE2.
