From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
Date: Thu, 9 Aug 2012 22:44:01 +0200 [thread overview]
Message-ID: <20120809224401.32f625ee@skate> (raw)
In-Reply-To: <CAJxxZ0N4JFf5U34pw=LQOa6hR7XL7scyp5dckHc9fTgZvg2e1g@mail.gmail.com>
Hello,
Le Thu, 9 Aug 2012 18:26:54 +0800,
Sonic Zhang <sonic.adi@gmail.com> a ?crit :
> If "target board makefile" doesn't exit, where should we add arch
> specific makefile targets and compile/link flags? Where should arch
> specific Config options be put? Take blackfin specific makefile as an
> example bellow.
There is no general rule for this, it depends on each thing you want to
add. For things that must be added globally, package/Makefile.in is
usually the current place (though this file would probably need some
cleanup, but this is a different topic).
> Makefile.in
> ----------------
> TARGET_CFLAGS += -D__NOMMU__ -D__uClinux__ -D_GNU_SOURCE
I don't think the -D_GNU_SOURCE should be passed globally to all
packages. Each package should define it if it is needed to build this
package.
Also, before globally defining __NOMMU__ and __uClinux__, I'd like to
understand why they are needed. I think __NOMMU__ is generally used to
test whether fork() or vfork() should be used, but this should probably
be tested using autoconf tests when possible.
That said, if such flags are indeed necessary, package/Makefile.in is a
good place for that.
> ifeq ($(BR2_ABI_FLAT),y)
> TARGET_LDFLAGS += -Wl,-elf2flt
> endif
> ifeq ($(BR2_BFIN_SHARED_FLAT), y)
> TARGET_LDFLAGS += -mid-shared-library -mshared-library-id=0
> TARGET_CFLAGS += -mid-shared-library -mshared-library-id=0
> TARGET_CXXFLAGS += -mid-shared-library -mshared-library-id=0
> endif
Same thing for these flags, package/Makefile.in.
> CROSS_COMPILE_SHARED_ELF ?= bfin-linux-uclibc-
No, this should use the existing variables to get the cross-compiler
location.
> romfs.shared.libs.elf:
> set -e; \
> t=`$(CROSS_COMPILE_SHARED_ELF)gcc $(CPUFLAGS)
> -print-file-name=libc.a`; \
> t=`dirname $$t`/../..; \
> for i in $$t/lib/*so*; do \
> i=`readlink -f "$$i"`; \
> soname=`$(CROSS_COMPILE_SHARED_ELF)readelf -d "$$i" |
> sed -n '/(SONAME)/s:.*[[]\(.*\)[]].*:\1:p'`; \
> $(INSTALL) -D $$i $(TARGET_DIR)/lib/$$soname; \
> done
Why is this needed? How is this romfs.shared.libs.elf target being used?
> CROSS_COMPILE_SHARED_FLAT ?= bfin-uclinux-
> romfs.shared.libs.flat:
> set -e; \
> t=`$(CROSS_COMPILE_SHARED_FLAT)gcc $(CPUFLAGS)
> -mid-shared-library -print-file-name=libc`; \
> if [ -f $$t -a ! -h $$t ] ; then \
> $(INSTALL) -D $$t $(TARGET_DIR)/lib/lib1.so; \
> fi
Ditto.
> Config.in
> ----------------------------------------------------
> config BR2_TARGET_ANALOGDEVICES_INSTALL_ELF_SHARED
> bool "Install ELF shared libraries" if !BR2_BFIN_FDPIC
> default y
>
> config BR2_TARGET_ANALOGDEVICES_INSTALL_FLAT_SHARED
> bool "Install FLAT shared libraries" if !BR2_BFIN_SHARED_FLAT
> default y
Any reason to have these in addition to the existing selection of ABI?
What are the use cases for these?
> Blackfin Linux distribution has a different file system layout from
> current default one in buildroot. And we have no plan to deviate from
> current one used for years. Anyway without this patch, we can still
> set a custom skeleton for blackfin.
How does the filesystem layout differs? Depending on how it differs,
having a separate skeleton may or may not be the right solution.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-08-09 20:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 6:57 [Buildroot] [PATCH] buildroot: Makefile: Allow target board makefile fill in default target_skeleton path Sonic Zhang
2012-08-09 8:41 ` Thomas Petazzoni
2012-08-09 10:26 ` Sonic Zhang
2012-08-09 20:44 ` Thomas Petazzoni [this message]
2012-08-13 5:04 ` 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=20120809224401.32f625ee@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