Cross compiling fails with "error: '__uint64_t' does not name a type"
Bug #1262305 reported by
Alan Griffiths
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
Critical
|
Andreas Pokorny | ||
mir (Ubuntu) |
Fix Released
|
Critical
|
Unassigned |
Bug Description
For example:
http://
This is recent and seems to relate to upstream changes. Using a cached partial-
Related branches
lp:~andreas-pokorny/mir/fix-missing-system-path
- PS Jenkins bot (community): Approve (continuous-integration)
- Daniel van Vugt: Approve
- Kevin DuBois (community): Approve
- kevin gunn (community): Approve
-
Diff: 14 lines (+2/-2)1 file modifiedcmake/LinuxCrossCompile.cmake (+2/-2)
tags: | added: blockingci |
Changed in mir: | |
importance: | Undecided → High |
milestone: | none → 0.1.3 |
Changed in mir: | |
assignee: | nobody → Andreas Pokorny (andreas-pokorny) |
status: | New → In Progress |
Changed in mir: | |
importance: | High → Critical |
Changed in mir: | |
status: | Fix Committed → Fix Released |
Changed in mir (Ubuntu): | |
importance: | Undecided → Critical |
status: | New → Fix Released |
To post a comment you must log in.
There are changes in the headers that make code conditionally compiled with "# if __GLIBC_ HAVE_LONG_ LONG" now compile unconditionally. But I haven't tracked down why there's no definition of __uint64_t.
It is also strange that the error shows as being on /usr/arm- linux-gnueabihf /include/ bits/byteswap. h when that shouldn't be on the search path (and, AIUI, ~/partial- armhf-chroot/ usr/include/ arm-linux- gnueabihf/ bits/byteswap. h should be picked up). The diff between these files is - as you might guess basically:
< #elif __GLIBC_ HAVE_LONG_ LONG
---
> #else
I've tried dumping the system path from CMake - but it looks right.
Logging current state of progress as it's EOD here.