Forum: PC-Programmierung GCC zu viele Quelldateien


von Lothar (Gast)


Lesenswert?

Ich möchte ein grosses Projekt mit vielen Quelldateien kompilieren. Das 
geht nicht mit:

g++ file1.cc file2.cc file3.cc ...

weil scheinbar der Argument-String nicht beliebig lang sein darf. Wie 
kann man es sonst machen? Mit einem Linker-Skript?

von Jemand (Gast)


Lesenswert?

Mit einem Build-System.

von foobar (Gast)


Lesenswert?

Schau dir die @-Option an.

Aber "jemand" hat schon recht: wenn die Kommandozeile so lang wird, dass 
sie das System nicht mehr will (bei mir wären das ca 2MB), sollte man 
auf Make o.ä. wechseln.

von Sven P. (Gast)


Lesenswert?

Lothar schrieb:
> weil scheinbar der Argument-String nicht beliebig lang sein darf. Wie
> kann man es sonst machen? Mit einem Linker-Skript?

Und dir sind dabei nie absurd lange Kompilier-Zeiten aufgefallen?
Also ich meine, du hast dich nie gewundert, dass du bei jeder winzigen 
Änderung in einer Quelldatei wieder recht lange kompilierst?

von A. S. (Gast)


Lesenswert?

Sven P. schrieb:
> Und dir sind dabei nie absurd lange Kompilier-Zeiten aufgefallen?

Das sind bei Windows nur 2 oder 8 tausend Zeichen, also je nach Pfaden 
und Optionen nur ein paar Dutzend quell-Dateien. Das fällt einem 
Anfänger nicht wirklich auf. Zumal dann jede Datei nur 10 Funktionen a 
10 Zeilen hat.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

Das scheint ein guter Zeitpunkt zu sein, sich mit make zu beschäftigen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Lothar schrieb:
> Ich möchte ein grosses Projekt mit vielen Quelldateien kompilieren. Das
> geht nicht mit:
>
> g++ file1.cc file2.cc file3.cc ...
>
> weil scheinbar der Argument-String nicht beliebig lang sein darf.

Genau, denn du verwendest offenbar MS Windows.

> Wie kann man es sonst machen?

Linux verwenden oder mit @-Datei versuchen, in welche du die 
Kommandozeilenargumente schreibst.

http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html

Das hilft aber nur bis dahin, wo der Compiler(treiber) wieder eine 
Kommandozeile für nen Subprozess zusammenbastelt, etwa für den Linker: 
Der muss ja alle Object-Dateien bekommen.

Wenn GCC mit einem @-File aufgerufen wurde, dann erstellt er auch ein 
@-File, um die Argumente an den Linker zu übergeben — falls der 
GNU-Linker verwendet wird und GCC dies beim configure bekannt ist: 
configure ... --with-gnu-ld ...

Oder eine statische Lib erstellen, die die Module enthält, und gegen 
diese linken.


 Mit einem Linker-Skript?

von mh (Gast)


Lesenswert?

Johann L. schrieb:
> Oder eine statische Lib erstellen, die die Module enthält, und gegen
> diese linken.

Hat man dabei nicht evtl. das gleiche Problem?

von Lothar (Gast)


Lesenswert?

Johann L. schrieb:
> du verwendest offenbar MS Windows

Nein ist auf Pi mit RISC OS. Inzwischen habe ich aber eine "Lösung" ...

Alles ausser main.cc unter Linux mit GCC Cross-Compiler für ARM in eine 
statische Library packen und auf Pi mit RISC OS dann nur noch:

g++ lib.a main.cc

> Kommandozeile für nen Subprozess zusammenbastelt

Das war wohl genau das Problem.

Sven P. schrieb:
> absurd lange Kompilier-Zeiten

Der RISC OS Port vom GCC ist schon bei einer Quelldatei lahm und wird 
dann nicht mehr viel lahmer. Es soll aber Abhilfe in Arbeit sein :-)

http://riscosblog.huber-net.de/2019/10/erste-anzeichen-fuer-gcc-8-2-0/

Beitrag #6032399 wurde von einem Moderator gelöscht.
von S. R. (svenska)


Lesenswert?

Lothar schrieb:
> Wie kann man es sonst machen?

Mir getrennten Aufrufen... so wie jedes gebrauchbare Build-System auch.

Lothar schrieb:
> g++ file1.cc file2.cc file3.cc ...
1
g++ -c -o file1.o file1.cc
2
g++ -c -o file2.o file2.cc
3
...
4
g++ -o prog file1.o file2.o ...

Die letzte Zeile dürfte bei vielen Dateien auch ein bisschen kürzer sein 
als dein Ausgangsbeispiel.

Unter aktuellen Betriebssystemen sind die Grenzen aber hinreichend groß, 
dass man sich meist nicht mit Parameterdateien behelfen muss (bei DOS 
lag die Grenze bei 127 Bytes über alles, da waren @-Dateien spätestens 
beim Linken normal).

: Bearbeitet durch User
von Heiko L. (zer0)


Lesenswert?

S. R. schrieb:
> Mir getrennten Aufrufen... so wie jedes gebrauchbare Build-System auch.

Problem dürfte da aber bleiben, dass auch die Linker-Zeile viel zu lang 
werden wird.

Fazit: So ein Projekt muss man sinnvoll aufteilen.

von Jemand (Gast)


Lesenswert?

Heiko L. schrieb:
> S. R. schrieb:
>> Mir getrennten Aufrufen... so wie jedes gebrauchbare Build-System auch.
>
> Problem dürfte da aber bleiben, dass auch die Linker-Zeile viel zu lang
> werden wird.

Dann Linkt man in mehreren Schritten, so wie jedes brauchbare 
Buildsystem es kann. Hilft auch mit der Parallelisierung.

von Rolf M. (rmagnus)


Lesenswert?

mh schrieb:
> Johann L. schrieb:
>> Oder eine statische Lib erstellen, die die Module enthält, und gegen
>> diese linken.
>
> Hat man dabei nicht evtl. das gleiche Problem?

Man muss ja nicht das gesamte Programm in eine einzige Lib stecken. Eine 
statische Lib ist nicht mehr als ein Archiv, das mehrere Object-Files 
enthält. Ich packe also zusammengehörende Object-Files in ein Archiv und 
muss sie dann nachher dem Linker nicht mehr alle einzeln angeben, 
sondern einfach das komplette Archiv auf einmal.

von Olaf (Gast)


Lesenswert?

> Nein ist auf Pi mit RISC OS. Inzwischen habe ich aber eine "Lösung" ...

Interessant. Kannst du mal ein bisschen mehr darueber erzaehlen? (gerne 
mit eigenem Subject)

Ich  finde RISCO OS naemlich grundsaetzlich auch sehr interessant, aber 
habe den Eindruck das es halt eher so die Nische von alten Englaendern 
bedient die sich mit Wehmut an ihren Archimedes erinnern. Wuerdest du 
sagen das dies ein lebendiges Betriebsystem ist mit dem sich die 
Beschaeftigung lohnt?
Gibt es eine lebendige Communitiy?

Ich vermute mal RISC OS auf dem neuen PI4 koennte ziemlich atemberaubend 
sein oder?

Olaf

von Lothar (Gast)


Lesenswert?

Olaf schrieb:
> Gibt es eine lebendige Communitiy?

https://www.riscosopen.org/forum/

> RISC OS auf dem neuen PI4

Ich nutze RISC OS hauptsächlich für Pi Zero und Pi 1A+ um die als 
"dicke" Mikrocontroller zu nutzen. Der Desktop ist aber auch schon auf 
dem Pi 1A+ sehr schnell so dass man auf einem Pi 3B+ den Unterschied 
nicht so merkt. Ausser bei Grafik-Benchmarks. Der Pi 4 wäre trotzdem 
interessant wegen den zwei HDMI-Ports. Nachdem die Foundation RISC OS zu 
Anfang noch sehr unterstützt hat:

https://www.raspberrypi.org/blog/risc-os-for-raspberry-pi/

Hat das aber inzwischen stark nachgelassen so dass alles mühsam von 
Raspbian portiert werden muss. Ist also noch nicht fertig:

https://gitlab.riscosopen.org/RiscOS/Sources/HAL/HAL_BCM2835/merge_requests/2

RISC OS läuft übrigens auch auf teuren Industrie-Boards z.B.

http://www.ti.com/tool/ELESAR-3P-SITARA-SOMS
https://revolution.kunbus.de/
https://www.wandboard.org/

Und auf ARM Laptops:

https://www.pine64.org/pinebook/

von Peter D. (peda)


Lesenswert?

Ich kannte auch mal einen Kollegen, der hat als Verzeichnisnamen ganze 
Romane geschrieben. Damit hat er alle anderen regelmäßig zur 
Verzweiflung getrieben.
Da hilft dann, das aktuelle Projekt in ein Verzeichnis in der Root zu 
kopieren oder per subst zu linken.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.