All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Issue for the integration of Codesourcery external toolchains
Date: Tue, 12 Jan 2010 11:54:41 +0100	[thread overview]
Message-ID: <20100112115441.0c21b140@surf> (raw)
In-Reply-To: <20100106065952.GA12127@jasper.tkos.co.il>

On Wed, 6 Jan 2010 08:59:53 +0200
Baruch Siach <baruch@tkos.co.il> wrote:

> >  * Build a more normal sysroot in $(STAGING_DIR) by combining the
> >    contents of armv4t and the header files. But this would require
> >    telling gcc that the libraries aren't in armv4t anymore. This is
> >    probably possible using a custom spec file, but is quite
> >    complicated.
> 
> How about generating symlinks in the staging directory:
> 
> armv4t/usr/include -> ../../usr/include
> thumb2/usr/include -> ../../usr/include
> 
> and then using the output of -print-sysroot for each target?

Because everything in Buildroot assumes that the libraries and headers
must be installed in $(STAGING_DIR)/usr/include and
$(STAGING_DIR)/usr/lib, not in $(STAGING_DIR)/armv4/usr/include and
$(STAGING_DIR)/armv4/usr/lib.

See the following part of my original e-mail:

==============================================
When the armv5t architecture is selected, everything works as
expected: the includes are in $(STAGING_DIR)/usr/include, the
libraries in $(STAGING_DIR)/lib and $(STAGING_DIR)/usr/lib.

When armv4t is selected, the include files are in
$(STAGING_DIR)/usr/include, but the libraries are in
$(STAGING_DIR)/armv4t/lib and $(STAGING_DIR)/armv4t/usr/lib. And the
linker *only* looks in these directories for the libraries.

Unfortunately, all Buildroot packages install their libraries in
$(STAGING_DIR)/lib and $(STAGING_DIR)/usr/lib, so the linker doesn't
find them.

For example, compiling zlib works, but compiling libpng fails because
it cannot find zlib. This is because zlib has been installed in
$(STAGING_DIR)/usr/lib and not in $(STAGING_DIR)/armv4t/usr/lib.
==============================================

Thanks for the feedback!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2010-01-12 10:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-04 15:24 [Buildroot] Issue for the integration of Codesourcery external toolchains Thomas Petazzoni
2010-01-04 23:23 ` Lionel Landwerlin
2010-01-12 10:52   ` Thomas Petazzoni
2010-01-12 22:09     ` Yann E. MORIN
2010-01-12 23:39       ` Thomas Petazzoni
2010-01-12 23:40     ` Lionel Landwerlin
2010-01-06  6:59 ` Baruch Siach
2010-01-12 10:54   ` Thomas Petazzoni [this message]
2010-01-12 12:48     ` Baruch Siach
2010-01-12 12:56       ` Lionel Landwerlin
2010-01-12 13:25         ` Baruch Siach

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=20100112115441.0c21b140@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.