cross-compiler doesn't have /usr/include on the search path

Bug #799965 reported by Steve Langasek on 2011-06-20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Linaro Ubuntu
gcc-4.6 (Ubuntu)
gcc-4.6-armel-cross (Ubuntu)
Marcin Juszkiewicz
gcc-4.6-armhf-cross (Ubuntu)
gcc-4.7 (Debian)
Fix Released
gcc-4.7 (Ubuntu)
gcc-4.7-armel-cross (Ubuntu)
gcc-4.7-armhf-cross (Ubuntu)

Bug Description

As more multiarch support makes its way into the system, I gave a try to cross-building mesa with only the armel cross-compiler packages and multiarch-installable headers/libraries. This works ok until the build tries to find X headers, because /usr/include is not on the default path:

make[5]: Entering directory `/home/vorlon/devel/linaro/multiarch/mesa/git/build/swx11+glu/src/mesa/drivers/x11'
arm-linux-gnueabi-gcc -c -I../../../../include -I../../../../src/mapi -I../../../../src/mesa -I../../../../src/mesa/main -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM fakeglx.c -o fakeglx.o
In file included from fakeglx.c:44:0:
glxheader.h:36:23: fatal error: X11/Xlib.h: No such file or directory
compilation terminated.
make[5]: *** [fakeglx.o] Error 1

In the multiarch world, it's assumed that since not all headers are architecture-dependent, not all of them will have to be moved to the per-architecture path /usr/include/<triplet>. That means cross-compilers will also need to look in /usr/include, not just in /usr/<arch>/include and /usr/include/<arch>.

Actually, it's possible that this compiler isn't currently multiarch-enabled at all?

$ arm-linux-gnueabi-gcc -print-search-dirs|sed -n -e's/libraries: =//p' | sed -e's/:/\n/g' | xargs -n1 readlink -f

No mention of /usr/lib/arm-linux-gnueabi here yet.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: gcc-arm-linux-gnueabi 4:4.5.2-8
ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
Uname: Linux 2.6.38-7-generic x86_64
Architecture: amd64
Date: Mon Jun 20 15:33:59 2011
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
 PATH=(custom, user)
SourcePackage: gcc-defaults-armel-cross
UpgradeStatus: Upgraded to natty on 2011-03-24 (88 days ago)

Steve Langasek (vorlon) wrote :
tags: added: multiarch
removed: natty
Steve Langasek (vorlon) wrote :

To be clear, though this bug report was filed from natty, the testing was done in an oneiric chroot. Reassigning to gcc-4.6.

affects: gcc-defaults-armel-cross (Ubuntu) → gcc-4.6-armel-cross (Ubuntu)
Marcin Juszkiewicz (hrw) on 2011-06-21
Changed in gcc-4.6-armel-cross (Ubuntu):
status: New → Confirmed
Marcin Juszkiewicz (hrw) on 2011-10-13
Changed in gcc-4.6-armel-cross (Ubuntu):
importance: Undecided → Medium
Changed in linaro-ubuntu:
assignee: nobody → Marcin Juszkiewicz (hrw)
milestone: none → 11.10
Fathi Boudra (fboudra) on 2011-11-11
Changed in linaro-ubuntu:
milestone: 11.10 → 11.11
Ricardo Salveti (rsalveti) wrote :

Marcin, can you update this bug with your latest status on the issue?

Changed in linaro-ubuntu:
status: New → In Progress
importance: Undecided → High
Marcin Juszkiewicz (hrw) wrote :

working on it - now when I merged all my toolchain changes/improvements into one tree this is next on a list.

David Zinman (dzinman) wrote :

The resolution to this bug did not make it into 11.11, re-target to 11.12

Changed in linaro-ubuntu:
milestone: 11.11 → 11.12
Marcin Juszkiewicz (hrw) on 2011-12-15
Changed in gcc-4.6-armel-cross (Ubuntu):
importance: Medium → Critical
assignee: nobody → Marcin Juszkiewicz (hrw)
Changed in linaro-ubuntu:
milestone: 11.12 → 12.01
importance: High → Critical
Marcin Juszkiewicz (hrw) wrote :

This patch adds /usr/include /usr/include/arm-linux-gnueabi/ to include search paths and /usr/lib/arm-linux-gnueabi to library search path.

So far it is a hack as I hardcoded triplet inside. If someone know how to generalize it I listen.

Changed in gcc-4.6 (Ubuntu):
status: New → Confirmed
tags: added: patch

On Wed, Jan 11, 2012 at 7:54 AM, Marcin Juszkiewicz
<email address hidden> wrote:
> This patch adds /usr/include /usr/include/arm-linux-gnueabi/ to include
> search paths and /usr/lib/arm-linux-gnueabi to library search path.
> So far it is a hack as I hardcoded triplet inside. If someone know how
> to generalize it I listen.

Will you at least enable it at a PPA or something for now? I wonder if
a similar fix could also be available for ARMHF, or should we just
start looking for the proper fix.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.6-armel-cross - 1.58

gcc-4.6-armel-cross (1.58) precise; urgency=low

  * Added hack to make cross compiler use multiarch dirs - LP: #799965
 -- Marcin Juszkiewicz <email address hidden> Wed, 18 Jan 2012 08:14:22 +0100

Changed in gcc-4.6-armel-cross (Ubuntu):
status: Confirmed → Fix Released
Marcin Juszkiewicz (hrw) wrote :

I am not closing bug cause what we have now is rather hack then solution.

Changed in linaro-ubuntu:
milestone: 12.01 → 12.02
Changed in linaro-ubuntu:
milestone: 12.02 → 12.03
Changed in linaro-ubuntu:
milestone: 12.03 → 12.04
Changed in linaro-ubuntu:
milestone: 12.04 → none
Changed in gcc-4.7 (Debian):
status: Unknown → New
Wookey (wookey) wrote :

This is with current quantal:
gcc-4.7-arm-linux-gnueabihf Version: 4.7.1-5ubuntu1cross1.67
gcc-arm-linux-gnueabihf Version: 4:4.7.0-7

This seems to have become more broken again and is currently breaking a lot of builds:

/usr/include is not on the system search path, never mind /usr/include/<triplet>. Oddly enough anything depending on the compiler to find -dev package headers is failing. A simple example is acl

---build-log excerpt---
checking attr/xattr.h usability... no
checking attr/xattr.h presence... no
checking for attr/xattr.h... no

FATAL ERROR: attr/xattr.h does not exist.
$ dpkg -s libattr1-dev:armhf
Package: libattr1-dev
Status: install ok installed
Architecture: armhf
Multi-Arch: same

$ dpkg -L libattr1-dev:armhf

And indeed if we check the compiler is not looking in /usr/insclude:

(quantal-amd64-test)wookey@e102475-lin:~/chroots/testrepo/packages-modded/acl-2.2.51$ `gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.

(quantal-amd64-test)wookey@e102475-lin:~/chroots/testrepo/packages-modded/acl-2.2.51$ `arm-linux-gnueabi-gcc -print-prog-name=cc1plus` -v
ignoring duplicate directory "/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list

The config.log output is attached to show the full failure example but it's dead easy to reproduce:
In a quantal chroot:
apt-get source acl
apt-get -a armhf build-dep acl
cd acl-2.2.51
dpkg-buildpackage -aarmhf

This bug is already critical, and the current 4.6 hack seems to have got lost in 4.7- any idea when it might get hacked again or fixed properly?

Marcin Juszkiewicz (hrw) wrote :

I will take care of it at 11th September.

Changed in linaro-ubuntu:
milestone: none → 12.09
Wookey (wookey) wrote :

Updated package tested with some previously-failing builds (linpng, libxext) and they worked. The listed output from
`arm-linux-gnueabihf-gcc -print-prog-name=cc1plus` -v
shows /usr/include on the end of the list

So that looks fixed to me.

Matthias Klose (doko) wrote :

this should only be set as fixed, if the patch is upstreamable

Changed in linaro-ubuntu:
milestone: 12.09 → none
Matthias Klose (doko) wrote :

all the cross builds were missing the --with-sysroot=/ config option. now fixed for 4.6 and 4.7 cross packages.

Changed in gcc-4.7-armhf-cross (Ubuntu):
status: New → Fix Released
Changed in gcc-4.7-armel-cross (Ubuntu):
status: New → Fix Released
Changed in gcc-4.6-armhf-cross (Ubuntu):
status: New → Fix Released
Matthias Klose (doko) wrote :

nothing to fix in gcc-4.7 itself

Changed in gcc-4.7 (Ubuntu):
status: New → Invalid
Matthias Klose (doko) wrote :

nothing to fix in gcc-4.6 itself

Changed in gcc-4.6 (Ubuntu):
status: Confirmed → Invalid
Changed in gcc-4.7 (Debian):
status: New → Fix Released
Fathi Boudra (fboudra) on 2013-05-31
Changed in linaro-ubuntu:
assignee: Marcin Juszkiewicz (hrw) → nobody
status: In Progress → New
importance: Critical → Undecided
Riku Voipio (riku-voipio) wrote :

With the focus on binary toolchains instead of ubuntu toolchains, this no longer affects linaro-ubuntu project.

Changed in linaro-ubuntu:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.