[Buildroot] [PATH 0/1] package/ncurses: disable use of the GPM library

[Buildroot] [PATH 0/1] package/ncurses: disable use of the GPM library

[Yann E. MORIN]

Hello All!

That one gave me a hard time most of the day, until I found out exactly
why building ncurses on my machine was consistently failing in buildroot
when it worked manually...

When building the toolchain, uClibc installs a host-ldd that is capable of
interpreting the target ELF files without running them (which the standard
ldd for the host can't, obviously).

That host-ldd is then installed as $(HOST_DIR)/usr/bin/ldd, which is first
in the PATH.

Then, when building the target ncurses, we first need to build the host tic
so we do configure ncurses for the host. At this step, ncurses' ./configure
tries to link against the GPM library, and if successful, extracts it's
SONAME using the ldd in the PATH, in it find the host-ldd previously
installed by uClibc. Alas, that host-ldd, besides being for interpreting
the _target_ files, is non-compliant on its output:

- ldd from glibc:
$ /usr/bin/ldd conftest
        linux-vdso.so.1 =>  (0x00007fffc87ff000)
        libgpm.so.2 => /usr/lib/libgpm.so.2 (0x00007f60ea873000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f60ea66f000)
        libc.so.6 => /lib/libc.so.6 (0x00007f60ea30d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f60eaa94000)

- ldd installed by uClibc:
$ /home/ymorin/dev/buildroot/O/host/usr/bin/ldd conftest
checking sub-depends for '/usr/lib/libgpm.so.2'
checking sub-depends for '/lib64/libdl.so.2'
checking sub-depends for '/lib64/libc.so.6'
        libgpm.so.2 => /usr/lib/libgpm.so.2 (0x00000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000000)
        libc.so.6 => /lib64/libc.so.6 (0x00000000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00000000)

Well, apart the addresses that are obviously faked, but has absolutely no
impact whatsoever, the problem are the first three lines, which makes
./configure improperly extract the SONAME as beeing (whitout leading spaces):
  libgpm.so.2'
  libgpm.so.2

And, no, that's not a typo; first line has a trailing single quote, and the
second line repeats the library name, without the trainling single quote.

Which makes the build break very hard soon afterward...

This problem only happens if one does have the GPM developement files
installed on the host, of course, which happens to be my case... :-/

Regards,
Yann E. MORIN.

[Buildroot] [PATCH] package/ncurses: disable use of the GPM library

[Yann E. MORIN]

When building the host-ncurses, we don't really need to link against the GPM
library, as only the tic program is of any interest to us. Disable that when
configuring the host-ncurses.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
---
 package/ncurses/ncurses.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/package/ncurses/ncurses.mk b/package/ncurses/ncurses.mk
index ac4c12b..50e85e8 100644
--- a/package/ncurses/ncurses.mk
+++ b/package/ncurses/ncurses.mk
@@ -131,7 +131,8 @@ define HOST_NCURSES_BUILD_CMDS
 endef
 
 HOST_NCURSES_CONF_OPT = \
-	--without-shared
+	--without-shared	\
+	--without-gpm
 
 $(eval $(call AUTOTARGETS,package,ncurses))
 $(eval $(call AUTOTARGETS,package,ncurses,host))
-- 
1.7.2.5

[Buildroot] [PATH 0/1] package/ncurses: disable use of the GPM library

[Thomas Petazzoni]

Le Wed, 14 Sep 2011 02:05:16 +0200,
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> a ?crit :

> That host-ldd is then installed as $(HOST_DIR)/usr/bin/ldd, which is
> first in the PATH.

When you build uClibc for ARM, uClibc installs an host-ldd ? Why is
this ldd necessary ?

I don't criticize the --without-gpm fix, but I'm just wondering if that
ldd in $(HOST_DIR) could create other problems with other packages.

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

[Buildroot] [PATH 0/1] package/ncurses: disable use of the GPM library

[Yann E. MORIN]

On Wednesday 14 September 2011 09:21:05 Thomas Petazzoni wrote:
> Le Wed, 14 Sep 2011 02:05:16 +0200,
> "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> a ?crit :
> 
> > That host-ldd is then installed as $(HOST_DIR)/usr/bin/ldd, which is
> > first in the PATH.
> 
> When you build uClibc for ARM, uClibc installs an host-ldd ?

Well, this time it was for MIPS. 

> Why is this ldd necessary ?

Probably not `necessay' for buildroot, but this host-ldd tries to be the
Holy Grail of cross-compilation: an ldd that can interpret the target
ELF files, and behaves the same as if it was run on the target.

> I don't criticize the --without-gpm fix,

Well, it's not a fix per-se, I prefer to view it as a workaround that is
also beneficial by explicitly stating that we do not need gpm just to
build tic.

> but I'm just wondering if that
> ldd in $(HOST_DIR) could create other problems with other packages.

Well, I'm surprised to be the first to notice and report this issue.
Probably not many people have the libgpm-dev package installed. So, I
can understand that _this_ error went unnoticed for years.

But with the number of packages in buildroot, I can hardly think that a
similarly broken combination did not appear yet.

But you're right. The proper way to fix this is to decide whether that
host-ldd is usefull or not.

Well, I can tell it could be usefull for at least one situation: when we
build the ncurses for the target, which happens every time we want gdb on
the target. But, as we do not package the GPM library in buildroot, we do
not currently benefit from this host-ldd.

To be noted, ncurses would still be broken, as it uses plain 'ldd' to do
the check, and does not even try with 'tuple-ldd'. It's hardcoded (all on
one line initially):

    cf_cv_gpm_soname=`ldd conftest$ac_exeext 2>/dev/null    \
                      | sed -e 's,^.*/,,' -e 's, .*$,,'     \
                      | fgrep libgpm.`

To be noted also, crosstool-NG also provides a kind of host-ldd (calls it
the cross-ldd), but only installs it tuple-prefixed; and it is consistent
with the glibc's ldd in terms of output (or it is a bug), so should not be
an issue for host packages.

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATH 0/1] package/ncurses: disable use of the GPM library

[Arnout Vandecappelle]

On Wednesday 14 September 2011 12:06:40, Yann E. MORIN wrote:
> On Wednesday 14 September 2011 09:21:05 Thomas Petazzoni wrote:
> > Le Wed, 14 Sep 2011 02:05:16 +0200,
> > 
> > "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> a ?crit :
> > > That host-ldd is then installed as $(HOST_DIR)/usr/bin/ldd, which is
> > > first in the PATH.
> > 
> > When you build uClibc for ARM, uClibc installs an host-ldd ?
> 
> Well, this time it was for MIPS.
> 
> > Why is this ldd necessary ?
> 
> Probably not `necessay' for buildroot, but this host-ldd tries to be the
> Holy Grail of cross-compilation: an ldd that can interpret the target
> ELF files, and behaves the same as if it was run on the target.

 It should then be called <arch-tuple>-ldd, like the crosstool-ng one, right?

[snip]
> But you're right. The proper way to fix this is to decide whether that
> host-ldd is usefull or not.

 It's useful in the same way that cross-gdb is useful.

 However, there sure is something broken about it: it should use the staging 
directory as sysroot, not /.  This would also fix the ncurses case.  
(Actually, also the cross-gdb could benefit from this; now you always have to 
do a 'set solib-absolute-prefix ...' for remote debugging.)


 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43