From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] xlib libXt build problem
Date: Mon, 27 Jul 2009 21:50:59 +0200 [thread overview]
Message-ID: <20090727215059.2aa274de@surf> (raw)
In-Reply-To: <8109ECD0-3E25-4BAD-B4D7-DE97BEEBE007@earthlink.net>
Le Mon, 27 Jul 2009 13:30:44 -0400,
Steve Bennett <sablists@earthlink.net> a ?crit :
> I'm making an educated guess that the patch effectively overrides
> the XLIB_LIBXT_CONF_ENV setting (or something else isn't including
> that setting), but I'm not sure what the right fix for this is. A
> brute force fix would be something like changing the patch to read:
>
> HOST_CC=gcc -I$(STAGING_DIR)/usr/include
>
> ...but is that the correct approach here? And why hasn't anything
> regarding this issue come up before? It seems odd that nobody else
> is running into this.
I'd say the issue is that makestrs is a program compiled for the host,
and the way we compile it in Buildroot assumes that the development
headers for X11 are installed on your host (through your distribution).
On my Ubuntu system, X11/Xos.h is part of the x11proto-core-dev package.
On my system, this package is installed, so when makestrs gets
compiled, the host gcc compiler uses /usr/include/X11/Xos.h during the
compilation.
When building some packages requires things from the host, we have
currently two different approaches in Buildroot:
* for some dependencies, we rebuild it, and install it in $(HOST_DIR)
* for some other dependencies, we assume that it is available on the
host
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2009-07-27 19:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 17:30 [Buildroot] xlib libXt build problem Steve Bennett
2009-07-27 19:50 ` Thomas Petazzoni [this message]
2009-07-27 20:18 ` Steve Bennett
2009-07-27 20:09 ` Steve Bennett
2009-07-27 23:36 ` Dan Lykowski
2009-07-28 8:03 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090727215059.2aa274de@surf \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox