gcc-arm-none-eabi, picolib und stdint.h?

push?

stdint.h ist ein Header der C-Standardlibrary. Zu einer vollständigen und standardkonformen C-Toolchain gehört eine C-Standardlibrary dazu.

Das sollte deine Frage allumfassend beantworten.

Oliver

Du hast Recht, wenn man das Kleingedruckte zu diesem Unterforum ernst nimmt: "Programmierung abseits des Embedded-Bereichs". Aber "Compiler und IDE" gibt's nicht mehr :(

Mit -ffreestanding braucht man keine C-Standardlibrary. Das finde ich für kleine uC-Programme durchaus passend. Aber stdint.h sollte trotzdem dabei sein, gerade, weil in C23 noch mehr dazu gekommen ist. ISO/IEC 9899:2024 (en) — N3220 working draft sagt:

1

A conforming freestanding implementation shall accept any

2

strictly conforming program in which the use of the features

3

specified in the library clause (Clause 7) is confined to the

4

contents of the standard headers <float.h>, <iso646.h>,

5

<limits.h>, <stdalign.h>, <stdarg.h>, <stdbit.h>, <stdbool.h>,

6

<stddef.h>, <stdint.h>, and <stdnoreturn.h>.

7

8

Additionally, a conforming freestanding implementation shall

9

accept any strictly conforming program where:

10

 - the features specified in the header <string.h> are used,

11

except the following functions: strcoll, strdup, strerror,

12

strndup, strtok, strxfrm; and/or,

13

 - the selected function memalignment from <stdlib.h> is used.

Bauform B. schrieb:

Mit -ffreestanding braucht man keine C-Standardlibrary.

Da sag ich mal, du irrst. freestanding als Gegensatz zu hosted braucht kein Betriebssystem, aber sehr wohl eine (minimale) cstandardlib.

Oliver

Oliver S. schrieb:

freestanding als Gegensatz zu hosted braucht kein Betriebssystem, aber sehr wohl eine (minimale) cstandardlib.

Ja, mindestens mit float.h über stdint.h bis stdnoreturn.h; natürlich mit den zugehörigen Funktionen. Das war alles beim gcc dabei. Manches wie z.B. stdarg braucht ja auch spezielle Unterstützung vom Compiler. Und jetzt fehlt in /usr/lib/gcc/arm-none-eabi/15/include/ genau eine Datei:

1

$ diff -u /tmp/1*

2

--- /tmp/14.2.1 2026-10-06 13:45:52.338549748 +0200

3

+++ /tmp/15     2026-10-06 13:46:06.714909237 +0200

4

@@ -18,7 +18,6 @@

5

 stdckdint.h

6

 stddef.h

7

 stdfix.h

8

-stdint.h

9

 stdnoreturn.h

10

 syslimits.h

11

 tgmath.h

Das mag am Unterschied zwischen STABLE und TESTING liegen. Die Unterscheidungen gibt es nicht ohne Grund und die Namen sind sorgfältig gewählt.

Bauform B. schrieb:

Das war alles beim gcc dabei.

Das sind Standardlibrary-Header. gcc als reiner Compiler hat gar keine. Warum die Debian-Maintainer die Pakete jetzt umsortiert haben, musst du die selber fragen.

Da stdint.h aber auch nur ein reiner Header ohne Binärcode dahinter ist, kopier den halt einfach ins passende Verzeichnis.

Oliver

Vorläufig hab' ich die alte kopiert, aber das kann nicht so bleiben. Ausgerechnet dieser Rechner war bisher überhaupt noch nicht vermüllt ;)

Sowas fällt natürlich keinem auf, weil jeder aus Gewohnheit newlib o.ä. installiert. Muss ich tatsächlich einen Bug aufmachen?

Wenn’s denn bug ist. Die picolib ist ja nur optional, das gcc-Paket braucht ja ansonsten die normale libc6. Dafür wirds dann auch eine stdint.h geben. Die solltest du mal vergleichen, ob die identisch sind.

Oliver

Oliver S. schrieb:

Wenn’s denn bug ist.

Eben.

Die picolib ist ja nur optional,

genau deswegen wollte ich sie weglassen. Aber die ist recommended, also schöner ist's schon, wenn ich sie installiere. Und es gibt "LDFLAGS += -nostdlib". Damit sollte die picolib beim Linken ignoriert werden. Das wäre optimal, gibt aber sehr spannende neue Fehler. Irgendwo ist noch ein neuer Schalter versteckt.

das gcc-Paket braucht ja ansonsten die normale libc6. Dafür wirds dann auch eine stdint.h geben.

Die sind verschieden, alleine wegen 64-Bit vs 32-Bit und gcc 16 vs gcc 15.