| Submitter | Saul Wold |
|---|---|
| Date | Jan. 5, 2012, 6:30 a.m. |
| Message ID | <04bb0f6bbd41ec9c2234df49130dba2346d9a3bf.1325744640.git.sgw@linux.intel.com> |
| Download | mbox | patch |
| Permalink | /patch/18353/ |
| State | New |
| Headers | show |
Comments
Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > - f=${D}${libdir}/$i.so > + f=${D}${base_libdir}/$i.so this breaks builds because 'ld' does not search ${base_libdir}: | gcc -shared ... -ltermcap | /usr/bin/ld: cannot find -ltermcap | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed Enrico
On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote: > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > > > - f=${D}${libdir}/$i.so > > + f=${D}${base_libdir}/$i.so > > this breaks builds because 'ld' does not search ${base_libdir}: > > | gcc -shared ... -ltermcap > | /usr/bin/ld: cannot find -ltermcap > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed Note this is a -native problem, not a target library one. I suspect we need to enhance: export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \ -Wl,-rpath-link,${STAGING_LIBDIR_NATIVE} \ -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-O1" in bitbake.conf. Cheers, Richard
On Fri, 2012-01-06 at 11:07 +0000, Richard Purdie wrote: > On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote: > > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > > > > > - f=${D}${libdir}/$i.so > > > + f=${D}${base_libdir}/$i.so > > > > this breaks builds because 'ld' does not search ${base_libdir}: > > > > | gcc -shared ... -ltermcap > > | /usr/bin/ld: cannot find -ltermcap > > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed > > Note this is a -native problem, not a target library one. It looks to me like the same would probably occur on the target. The .so devel symlinks should be in ${libdir} not ${base_libdir} since the latter is indeed not in the linker's standard search path. There are some commented-out bits in bitbake.conf which would put it there: #export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${libdir} \ # -Wl,-rpath-link,${STAGING_DIR_TARGET}${libdir} \ # -Wl,-O1" but even then it would still fail for on-target builds that don't use bitbake and I think we should just fix ncurses to install itself into the correct place. Or everyone should use micro and avoid this whole class of problems. :-) p.
On Fri, 2012-01-06 at 11:33 +0000, Phil Blundell wrote: > On Fri, 2012-01-06 at 11:07 +0000, Richard Purdie wrote: > > On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote: > > > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > > > > > > > - f=${D}${libdir}/$i.so > > > > + f=${D}${base_libdir}/$i.so > > > > > > this breaks builds because 'ld' does not search ${base_libdir}: > > > > > > | gcc -shared ... -ltermcap > > > | /usr/bin/ld: cannot find -ltermcap > > > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > > > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed > > > > Note this is a -native problem, not a target library one. > > It looks to me like the same would probably occur on the target. > The .so devel symlinks should be in ${libdir} not ${base_libdir} since > the latter is indeed not in the linker's standard search path. Are you 100% sure about that? I was pretty sure that /lib is in the default linker's search path as well as /usr/lib? I can't find a commandline option to make ld dump its search path but looking at the linker scripts for various architectures, it does appear that /lib is listed as a search directory... Cheers, Richard
On Fri, 2012-01-06 at 12:06 +0000, Richard Purdie wrote: > On Fri, 2012-01-06 at 11:33 +0000, Phil Blundell wrote: > > On Fri, 2012-01-06 at 11:07 +0000, Richard Purdie wrote: > > > On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote: > > > > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > > > > > > > > > - f=${D}${libdir}/$i.so > > > > > + f=${D}${base_libdir}/$i.so > > > > > > > > this breaks builds because 'ld' does not search ${base_libdir}: > > > > > > > > | gcc -shared ... -ltermcap > > > > | /usr/bin/ld: cannot find -ltermcap > > > > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > > > > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed > > > > > > Note this is a -native problem, not a target library one. > > > > It looks to me like the same would probably occur on the target. > > The .so devel symlinks should be in ${libdir} not ${base_libdir} since > > the latter is indeed not in the linker's standard search path. > > Are you 100% sure about that? I was pretty sure that /lib is in the > default linker's search path as well as /usr/lib? Not 100%, admittedly, but I can't think of any other instances of these things being installed in /lib. I know that glibc, for example, puts libc.so in /usr/lib even though the corresponding libraries are in /lib. Admittedly that one isn't a symlink though. > I can't find a commandline option to make ld dump its search path but > looking at the linker scripts for various architectures, it does appear > that /lib is listed as a search directory... I think "ld -verbose" should do that. Look for SEARCH_DIR or some such. p.
On Fri, 2012-01-06 at 12:07 +0000, Phil Blundell wrote: > On Fri, 2012-01-06 at 12:06 +0000, Richard Purdie wrote: > > On Fri, 2012-01-06 at 11:33 +0000, Phil Blundell wrote: > > > On Fri, 2012-01-06 at 11:07 +0000, Richard Purdie wrote: > > > > On Fri, 2012-01-06 at 11:29 +0100, Enrico Scholz wrote: > > > > > Saul Wold <sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > > > > > > > > > > > - f=${D}${libdir}/$i.so > > > > > > + f=${D}${base_libdir}/$i.so > > > > > > > > > > this breaks builds because 'ld' does not search ${base_libdir}: > > > > > > > > > > | gcc -shared ... -ltermcap > > > > > | /usr/bin/ld: cannot find -ltermcap > > > > > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > > > > > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed > > > > > > > > Note this is a -native problem, not a target library one. > > > > > > It looks to me like the same would probably occur on the target. > > > The .so devel symlinks should be in ${libdir} not ${base_libdir} since > > > the latter is indeed not in the linker's standard search path. > > > > Are you 100% sure about that? I was pretty sure that /lib is in the > > default linker's search path as well as /usr/lib? > > Not 100%, admittedly, but I can't think of any other instances of these > things being installed in /lib. I know that glibc, for example, puts > libc.so in /usr/lib even though the corresponding libraries are in /lib. > Admittedly that one isn't a symlink though. > > > I can't find a commandline option to make ld dump its search path but > > looking at the linker scripts for various architectures, it does appear > > that /lib is listed as a search directory... > > I think "ld -verbose" should do that. Look for SEARCH_DIR or some such. $ ./i586-poky-linux-ld --verbose | grep SEARCH SEARCH_DIR("/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/i586-poky-linux/lib32"); SEARCH_DIR("=/usr/local/lib32"); SEARCH_DIR("=/lib32"); SEARCH_DIR("=/usr/lib32"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); which makes sense since the builds are all still working... Cheers, Richard
On Fri, 2012-01-06 at 12:20 +0000, Richard Purdie wrote: > $ ./i586-poky-linux-ld --verbose | grep SEARCH > SEARCH_DIR("/media/build1/poky/build/tmp/sysroots/x86_64-linux/usr/i586-poky-linux/lib32"); SEARCH_DIR("=/usr/local/lib32"); SEARCH_DIR("=/lib32"); SEARCH_DIR("=/usr/lib32"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); > > which makes sense since the builds are all still working... Oh, right, fair enough. I guess it does need to search /lib for NEEDED libs, at least, and maybe it just uses the same search path for .so links. Anyway, yeah, that seems fine then. p.
On 01/06/2012 02:29 AM, Enrico Scholz wrote: > Saul Wold<sgw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes: > >> - f=${D}${libdir}/$i.so >> + f=${D}${base_libdir}/$i.so > > this breaks builds because 'ld' does not search ${base_libdir}: > > | gcc -shared ... -ltermcap > | /usr/bin/ld: cannot find -ltermcap > | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' > | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed Which is why I added: # tic from the -native build cannot run without setting this explicitly BUILD_LDFLAGS_virtclass-native += "-Wl,-rpath,${base_libdir}" to ncurses.inc Is this not working? I build-tested this with our -minimal and -sato images, and readline is built as a part of this. Not sure how I could have missed this, unless some host contamination was creeping in. Scott
Scott Garman <scott.a.garman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes: >>> - f=${D}${libdir}/$i.so >>> + f=${D}${base_libdir}/$i.so >> >> this breaks builds because 'ld' does not search ${base_libdir}: >> >> | gcc -shared ... -ltermcap >> | /usr/bin/ld: cannot find -ltermcap >> | ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb, do_install) failed with exit code '1' >> | ERROR: 'virtual:native:.../readline/readline_6.2.bb' failed > > Which is why I added: > > # tic from the -native build cannot run without setting this explicitly > BUILD_LDFLAGS_virtclass-native += "-Wl,-rpath,${base_libdir}" > > to ncurses.inc > > Is this not working? no; error happens when building 'readline-native' (which does not read ncurses.inc). Build of 'ncurses(-native)' succeeded. > I build-tested this with our -minimal and -sato images, and readline > is built as a part of this. Not sure how I could have missed this, > unless some host contamination was creeping in. probably, the ncurses development files were installed on the host and '-ltermcap' linked against them and not against the oe ones.. Enrico
Patch
diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc index 583dad7..8321d7b 100644 --- a/meta/recipes-core/ncurses/ncurses.inc +++ b/meta/recipes-core/ncurses/ncurses.inc @@ -26,6 +26,9 @@ ENABLE_WIDEC ?= "true" # builds. BUILD_CPPFLAGS += "-D_GNU_SOURCE" +# tic from the -native build cannot run without setting this explicitly +BUILD_LDFLAGS_virtclass-native += "-Wl,-rpath,${base_libdir}" + # Helper function for do_configure to allow multiple configurations # $1 the directory to run configure in # $@ the arguments to pass to configure @@ -41,6 +44,7 @@ ncurses_configure() { --enable-hard-tabs \ --enable-xmc-glitch \ --enable-colorfgbg \ + --libdir=${base_libdir} \ --with-termpath='${sysconfdir}/termcap:${datadir}/misc/termcap' \ --with-terminfo-dirs='${sysconfdir}/terminfo:${datadir}/terminfo' \ --with-shared \ @@ -120,7 +124,6 @@ do_install() { ! ${ENABLE_WIDEC} || \ oe_runmake -C widec ${_install_opts} - cd narrowc # include some basic terminfo files @@ -155,28 +158,29 @@ do_install() { # else when '-Wl,--no-copy-dt-needed-entries' has been set in # linker flags. for i in libncurses libncursesw; do - f=${D}${libdir}/$i.so + f=${D}${base_libdir}/$i.so test -h $f || continue rm -f $f echo '/* GNU ld script */' >$f echo "INPUT($i.so.5 AS_NEEDED(-ltinfo))" >>$f done - # Make sure that libcurses is linked so that it gets -ltinfo - # also, this should be addressed upstream really. - ln -sf libncurses.so ${D}${libdir}/libcurses.so + + # Make sure that libcurses is linked so that it gets -ltinfo + # also, this should be addressed upstream really. + ln -sf libncurses.so ${D}${base_libdir}/libcurses.so # create libtermcap.so linker script for backward compatibility - f=${D}${libdir}/libtermcap.so + f=${D}${base_libdir}/libtermcap.so echo '/* GNU ld script */' >$f echo 'INPUT(AS_NEEDED(-ltinfo))' >>$f - oe_multilib_header curses.h + oe_multilib_header curses.h } python populate_packages_prepend () { - libdir = bb.data.expand("${libdir}", d) + base_libdir = bb.data.expand("${base_libdir}", d) pnbase = bb.data.expand("${PN}-lib%s", d) - do_split_packages(d, libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses %s library', prepend=True, extra_depends = '', allow_links=True) + do_split_packages(d, base_libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses %s library', prepend=True, extra_depends = '', allow_links=True) } @@ -210,6 +214,10 @@ FILES_${PN} = "\ ${datadir}/tabset \ " +FILES_${PN}-dev += "\ + ${base_libdir}/*.so \ +" + # This keeps only tput/tset in ncurses # clear/reset are in already busybox FILES_${PN}-tools = "\ @@ -223,6 +231,7 @@ FILES_${PN}-tools = "\ ${bindir}/tack \ ${bindir}/tabs \ " + # 'reset' is a symlink to 'tset' which is in the 'ncurses' package RDEPENDS_${PN}-tools = "${PN}"