Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 6/7] arch: Introduce blackfin-specific Makefile
Date: Mon, 8 Apr 2013 23:23:28 +0200	[thread overview]
Message-ID: <20130408232328.0baf2b9e@skate> (raw)
In-Reply-To: <CAJxxZ0MafRS7uggYwNVFRc6pHFNXwufsOtvq9=oxS8qJOZAcig@mail.gmail.com>

Dear Sonic Zhang,

On Mon, 8 Apr 2013 15:19:18 +0800, Sonic Zhang wrote:
> > I am still not happy with this, because it simply doesn't work unless
> > you have the Blackfin toolchain installed globally on your system,
> > which simply isn't the case for normal users.
> >
> > So I believe we should extend the external toolchain logic to be able
> > to use three variants of the Blackfin toolchain:
> >
> >         * Only FDPIC
> >         * Only FLAT
> >         * Both FLAT and FDPIC
> >
> > And then, this logic should be moved in the external toolchain logic,
> > where we already do the process of copying libraries from the toolchain
> > to the target, and from the toolchain to the staging directory.
> 
> Since FPDIC libraries are installed by default if BINFMT_FDPIC is
> selected, how about making INSTALL_FDPIC_LIB option depend on
> BINFMT_FLAT only? So do the INSTALL_FLAT_LIB option.

Yes, this makes sense.

> And no "Both FLAT and FDPIC" is needed in this case.

In fact, I looked again at our support for Blackfin external
toolchains, and I was wrong: we always install *both* the FDPIC and
Flat shared libraries. So in fact, you don't need to handle the
variants of the external toolchain.

Just move your logic into the external toolchain logic that copies
libraries, and that should be fine. I believe it belongs to the
external toolchain logic, because it is highly specific to Analog
Devices toolchains. If we ever support Blackfin in the internal
backend, it will always either be FDPIC *or* FLAT, but not both at the
same time.

> >  * the logic to determine which .so files to copy should use the
> >    $(LIB_EXTERNAL_LIBS) and $(USR_LIB_EXTERNAL_LIBS) that we already
> >    use in ext-tool.mk.
> 
> This only applies to the FDPIC libraries. The FLAT libraries use a
> different name policy.

Yes, sure, but I was referring to the FDPIC libraries in this part
(sorry if it wasn't clear).

> >  * I don't quite understand the logic you're using for the shared flat
> >    library copying. You use -print-file-name=libc, but then you copy it
> >    under the name 'lib1.so'. I think a comment above this part would be
> >    useful.
> 
> The flat libraries are found and linked according to the index in it
> name "libN.so". Index 1 is reserved for the standard C library.
> Customer libraries can use 4 and above. That's why the libc is renamed
> to lib1.so in target rootfs.

Oh, ok, interesting. Could you just copy/paste this explanation as a
comment above the relevant part of the code?

Thanks a lot Sonic for your very quick feedback in this discussion, I
think we're making great progress!

Thanks,

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

  reply	other threads:[~2013-04-08 21:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-29  9:50 [Buildroot] [PATCH v2 1/7] arch: Add blackfin CPU choice Sonic Zhang
2013-03-29  9:50 ` [Buildroot] [PATCH v2 2/7] arch: toolchain: Introduce target CPU revision Sonic Zhang
2013-04-07 20:42   ` Thomas Petazzoni
2013-04-08  6:30     ` Sonic Zhang
2013-03-29  9:50 ` [Buildroot] [PATCH v2 3/7] arch: toolchain: Introduce binary formats BINFMT_* Sonic Zhang
2013-04-07 20:45   ` Thomas Petazzoni
2013-04-08  6:03     ` Sonic Zhang
2013-04-07 20:47   ` Thomas Petazzoni
2013-04-08  6:04     ` Sonic Zhang
2013-03-29  9:50 ` [Buildroot] [PATCH v2 4/7] arch: toolchain: Introduce binary format FLAT types Sonic Zhang
2013-04-07 20:51   ` Thomas Petazzoni
2013-04-08  6:43     ` Sonic Zhang
2013-04-12  3:39     ` Sonic Zhang
2013-04-13 14:31       ` Thomas Petazzoni
2013-04-16 10:26         ` Sonic Zhang
2013-04-16 10:46           ` Thomas Petazzoni
2013-04-17  9:02             ` Sonic Zhang
2013-04-23  5:57               ` Sonic Zhang
2013-03-29  9:50 ` [Buildroot] [PATCH v2 5/7] package: Introduce package-specific BINFMT_FLAT options Sonic Zhang
2013-04-07 21:27   ` Thomas Petazzoni
2013-04-10  5:47     ` Arnout Vandecappelle
2013-04-10  8:10       ` Sonic Zhang
2013-04-10 10:36         ` Arnout Vandecappelle
2013-03-29  9:50 ` [Buildroot] [PATCH v2 6/7] arch: Introduce blackfin-specific Makefile Sonic Zhang
2013-04-07 21:41   ` Thomas Petazzoni
2013-04-08  7:19     ` Sonic Zhang
2013-04-08 21:23       ` Thomas Petazzoni [this message]
2013-03-29  9:50 ` [Buildroot] [PATCH v2 7/7] package: Introduce NOMMU symbol Sonic Zhang
2013-04-07 20:39 ` [Buildroot] [PATCH v2 1/7] arch: Add blackfin CPU choice Thomas Petazzoni
2013-04-08  3:28   ` Sonic Zhang

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=20130408232328.0baf2b9e@skate \
    --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