Skip to contentSkip to conversation

package/ncurses: disable use of the GPM library

PATCH New Yann E. MORIN 3 participants 5 messages Sep 14, 2011

lore
Share & tools
lore
#0 lore raw

cover package/ncurses: disable use of the GPM library

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.

#1 lore raw

PATCH 1/1 package/ncurses: disable use of the GPM library

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.

---
 package/ncurses/ncurses.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
package/ncurses/ncurses.mk +2 -1
index ac4c12b..50e85e8 100644
@@ -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))
Signature · 1 line
1.7.2.5
#2 lore raw

cover package/ncurses: disable use of the GPM library

In reply to Yann E. MORIN

Le Wed, 14 Sep 2011 02:05:16 +0200,
"Yann E. MORIN" <[email protected]> a ?crit :

Quoted 2 lines

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#3 lore raw

cover package/ncurses: disable use of the GPM library

Quoted 7 lines · On Wednesday 14 September 2011 09:21:05 Thomas Petazzoni wrote:

Le Wed, 14 Sep 2011 02:05:16 +0200,
"Yann E. MORIN" <[email protected]> a ?crit :

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#4 lore raw

cover package/ncurses: disable use of the GPM library

Quoted 9 lines · Yann E. MORIN
Quoted 7 lines · On Wednesday 14 September 2011 09:21:05 Thomas Petazzoni wrote:

Le Wed, 14 Sep 2011 02:05:16 +0200,

"Yann E. MORIN" <[email protected]> a ?crit :

Quoted 2 lines

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 ?

Quoted 7 lines

Well, this time it was for MIPS.

Quoted 1 line

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]

Quoted 2 lines

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

Signature · 6 lines
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