From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] RPC support for modern (e)glibc toolchains
Date: Wed, 27 Jun 2012 08:00:40 -0300 [thread overview]
Message-ID: <359dafd382a8aa5ccaaa5ebbde9b38ff@zacarias.com.ar> (raw)
In-Reply-To: <20120627000701.506f534e@skate>
On 2012-06-26 19:07, Thomas Petazzoni wrote:
> Hello,
Hi Thomas.
> So I've created a package for libtirpc, which after a few fixes,
> seems
> to work fine. But now, the hard part is how to handle this new
> package
> in terms of dependencies, and this is where I'd like to have your
> opinion.
How big is libtirpc in the target? Curiosity :)
> I have essentially two problems:
>
> *) Should we consider libtirpc just an add-on for (e)glibc, and
> therefore make it visible/available/used only when a (e)glibc
> toolchain lacking RPC support is used, or instead, should we
> offer
> libtirpc as soon as the toolchain lacks RPC support (which would
> also be the case for uClibc toolchain with no RPC support from
> the
> C library) ?
I'd say while we're working at it we could do it for uClibc as well
since it provides benefits which (probably) also apply to uClibc's RPC.
> *) Should we make the dependency from packages on libtirpc a
> "select", like all other library dependencies, or a "depends on",
> to
> mimic what we currently do for RPC support (packages "depends on
> BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
> available) ?
Probably keep it as a "depends on", in some cases you'll already have
the toolchain providing RPC.
Maybe even block libtirpc if the origin toolchain has RPC support? Or
can they be used at the same time? (Not that anyone would want too i
think...)
> *) How to handle the case of the Crosstool-NG backend? With the
> current Crosstool-NG backend, we have no idea which version of
> (e)glibc is being built, so we have no idea whether RPC support
> will be provided by the toolchain. Should we add a config option
> saying "My toolchain will have RPC support", which we will then
> check after the toolchain build, like we do with external
> toolchains? Other suggestions?
BR2_TOOLCHAIN_I_WANT_RPC ?
After the toolchain is done we do an RPC check with readelf, if it's
not there we build libtirpc, otherwise we leave it be.
Regards.
next prev parent reply other threads:[~2012-06-27 11:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 22:07 [Buildroot] RPC support for modern (e)glibc toolchains Thomas Petazzoni
2012-06-27 2:55 ` [Buildroot] RPC and Busybox Michael J. Hammel
2012-06-27 7:18 ` Thomas Petazzoni
2012-06-27 8:25 ` [Buildroot] RPC support for modern (e)glibc toolchains Thomas Petazzoni
2012-06-27 11:00 ` Gustavo Zacarias [this message]
2012-06-27 12:53 ` Thomas Petazzoni
2012-06-28 11:51 ` Gustavo Zacarias
2012-06-28 11:57 ` Thomas Petazzoni
2012-06-28 12:06 ` Gustavo Zacarias
2012-06-30 12:24 ` Arnout Vandecappelle
2012-07-03 19:48 ` Thomas Petazzoni
2012-07-03 20:37 ` Arnout Vandecappelle
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=359dafd382a8aa5ccaaa5ebbde9b38ff@zacarias.com.ar \
--to=gustavo@zacarias.com.ar \
--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