All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain
@ 2014-06-09 10:26 Yann E. MORIN
  2014-06-09 12:23 ` Thomas Petazzoni
  0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2014-06-09 10:26 UTC (permalink / raw)
  To: buildroot

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

libbsd needs support for .init_array and checks for a
glibc >= 2.4 since .init_array was introduced at around
that time.

uClibc claims to be a glibc-compatible toolchain, but it
only impersonates a glibc-2.2.

Just disable libbsd on uClibc.

Fixes:
    http://autobuild.buildroot.net/results/e94/e949d8fabeeecc74bd1c324c516e0b4938c99dbc/
    http://autobuild.buildroot.net/results/d3e/d3e1b70fb91571efacbe32af2cd12d055508f5ac/
    http://autobuild.buildroot.net/results/b19/b19d24dbf9d05d86d839349695da45d548705b25/
    [...]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

---
Note: I initially introduced libbsd as an Nth-level dependency of
qemu to be able to run qemu on the target. So I'll have to revisit
this when I am ready to push my qemu-on-target series. For now,
just disable libbsd on uClibc.
---
 package/libbsd/Config.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/libbsd/Config.in b/package/libbsd/Config.in
index 8c90aa1..e22226a 100644
--- a/package/libbsd/Config.in
+++ b/package/libbsd/Config.in
@@ -4,6 +4,7 @@ config BR2_PACKAGE_LIBBSD
 	# architectures: arm, m68k, x86 (and alpha, but we don't care.)
 	depends on ( BR2_i386 || BR2_x86_64 )
 	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_TOOLCHAIN_USES_GLIBC
 	help
 	  This library provides useful functions commonly found on BSD
 	  systems, and lacking on others like GNU systems, thus making
@@ -13,6 +14,6 @@ config BR2_PACKAGE_LIBBSD
 
 	  http://libbsd.freedesktop.org/
 
-comment "libbsd needs a toolchain w/ threads"
+comment "libbsd needs an (e)glibc toolchain w/ threads"
 	depends on ( BR2_i386 || BR2_x86_64 )
-	depends on !BR2_TOOLCHAIN_HAS_THREADS
+	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_USES_GLIBC
-- 
1.8.3.2

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain
  2014-06-09 10:26 [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain Yann E. MORIN
@ 2014-06-09 12:23 ` Thomas Petazzoni
  2014-06-09 12:32   ` Yann E. MORIN
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Petazzoni @ 2014-06-09 12:23 UTC (permalink / raw)
  To: buildroot

Dear Yann E. MORIN,

On Mon,  9 Jun 2014 12:26:21 +0200, Yann E. MORIN wrote:

> -comment "libbsd needs a toolchain w/ threads"
> +comment "libbsd needs an (e)glibc toolchain w/ threads"
>  	depends on ( BR2_i386 || BR2_x86_64 )
> -	depends on !BR2_TOOLCHAIN_HAS_THREADS
> +	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_USES_GLIBC

Is it possible to have a glibc toolchain without threads? I think no.
In this case, what is our policy? Should we keep both the glibc and
thread dependencies?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain
  2014-06-09 12:23 ` Thomas Petazzoni
@ 2014-06-09 12:32   ` Yann E. MORIN
  2014-06-09 12:40     ` Thomas Petazzoni
  0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2014-06-09 12:32 UTC (permalink / raw)
  To: buildroot

Thomas, All,

On 2014-06-09 14:23 +0200, Thomas Petazzoni spake thusly:
> On Mon,  9 Jun 2014 12:26:21 +0200, Yann E. MORIN wrote:
> 
> > -comment "libbsd needs a toolchain w/ threads"
> > +comment "libbsd needs an (e)glibc toolchain w/ threads"
> >  	depends on ( BR2_i386 || BR2_x86_64 )
> > -	depends on !BR2_TOOLCHAIN_HAS_THREADS
> > +	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_USES_GLIBC
> 
> Is it possible to have a glibc toolchain without threads? I think no.
> In this case, what is our policy? Should we keep both the glibc and
> thread dependencies?

Indeed, Buildroot considers glibc toolchains have threads.

Just for this commit, I would not care we remove the threads dependency,
since it is implicit with glibc.

However, as I said, libbsd is an Nth-level dependency of QEMU, which I
am still p[lanning on submitting. Having static qemu-user programs is
very usefull to run foreign chroots, and is only possible with uClibc,
so I will have to fix that issue at some point in time. And keeping the
threads dependency will just be a warning to me at that point.

But for now, do as you prefer. It should be pretty easy to pinpoint
build failures at that time. ;-)

Do you want me to respin?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain
  2014-06-09 12:32   ` Yann E. MORIN
@ 2014-06-09 12:40     ` Thomas Petazzoni
  0 siblings, 0 replies; 4+ messages in thread
From: Thomas Petazzoni @ 2014-06-09 12:40 UTC (permalink / raw)
  To: buildroot

Dear Yann E. MORIN,

On Mon, 9 Jun 2014 14:32:22 +0200, Yann E. MORIN wrote:

> > Is it possible to have a glibc toolchain without threads? I think no.
> > In this case, what is our policy? Should we keep both the glibc and
> > thread dependencies?
> 
> Indeed, Buildroot considers glibc toolchains have threads.
> 
> Just for this commit, I would not care we remove the threads dependency,
> since it is implicit with glibc.
> 
> However, as I said, libbsd is an Nth-level dependency of QEMU, which I
> am still p[lanning on submitting. Having static qemu-user programs is
> very usefull to run foreign chroots, and is only possible with uClibc,
> so I will have to fix that issue at some point in time. And keeping the
> threads dependency will just be a warning to me at that point.

Ok, makes sense.

> Do you want me to respin?

Nah, that's fine.

Remember that we now have musl support, and musl supports static
linking, so it could be an alternative to uClibc for some of these use
cases :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-06-09 12:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-09 10:26 [Buildroot] [PATCH] package/libbsd: needs an (e)glibc toolchain Yann E. MORIN
2014-06-09 12:23 ` Thomas Petazzoni
2014-06-09 12:32   ` Yann E. MORIN
2014-06-09 12:40     ` Thomas Petazzoni

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.