nfs-utils-1.1.2 problem

nfs-utils-1.1.2 problem

[Steffen Sledz]

I see a problem with mountd from nfs-utils-1.1.2 (Angstrom, current OE dev branch):

starting mountd: /usr/sbin/mountd: line 148: /usr/bin/sed: not found
/usr/sbin/mountd: line 148: /usr/bin/sed: not found
/usr/sbin/mountd: cd: line 1: can't cd to /home/DRESEARCH/production/METABUILD/20090826190001-hydraip-build-1978/OE/tmp.3/wor
k/armv5te-angstrom-linux-gnueabi/nfs-utils-1.1.2-r4/nfs-utils-1.1.2/utils/mountd
arm-angstrom-linux-gnueabi-gcc: mountd-mountd.o: No such file or directory
arm-angstrom-linux-gnueabi-gcc: mountd-mount_dispatch.o: No such file or directory
arm-angstrom-linux-gnueabi-gcc: mountd-auth.o: No such file or directory
...

The first problem is that /usr/sbin/mountd uses /usr/bin/sed but sed is installed under /bin/sed.

The second one is that /usr/sbin/mountd contains a relink_command which uses pathes from the build host:

relink_command="(cd /home/DRESEARCH/sledz/work/HydraIP/OE/tmp.3/work/armv5te-angstrom-linux-gnueabi/nfs-utils-1.1.2-r4/nfs-utils-1.1.2/utils/mountd;  ...

Could someone please have a look at this.

Thx,
Steffen

Re: nfs-utils-1.1.2 problem

[Chris Larson]

That sounds like a case of someone installing the libtool wrapper
script into the rootfs instead of the real binary.  The do_install may
be directly using 'install' to install it.  It should be changed to
use a normal make install, or call out ${S}/${HOST_SYS}-libtool
--mode=install install <rest of install command>.  NOTE: This is
conjecture, I haven't read the recipe, or tested, but it's similar to
an issue I hit last week.

On Thu, Aug 27, 2009 at 2:21 AM, Steffen Sledz<sledz@dresearch.de> wrote:
> I see a problem with mountd from nfs-utils-1.1.2 (Angstrom, current OE dev branch):
>
> starting mountd: /usr/sbin/mountd: line 148: /usr/bin/sed: not found
> /usr/sbin/mountd: line 148: /usr/bin/sed: not found
> /usr/sbin/mountd: cd: line 1: can't cd to /home/DRESEARCH/production/METABUILD/20090826190001-hydraip-build-1978/OE/tmp.3/wor
> k/armv5te-angstrom-linux-gnueabi/nfs-utils-1.1.2-r4/nfs-utils-1.1.2/utils/mountd
> arm-angstrom-linux-gnueabi-gcc: mountd-mountd.o: No such file or directory
> arm-angstrom-linux-gnueabi-gcc: mountd-mount_dispatch.o: No such file or directory
> arm-angstrom-linux-gnueabi-gcc: mountd-auth.o: No such file or directory
> ...
>
> The first problem is that /usr/sbin/mountd uses /usr/bin/sed but sed is installed under /bin/sed.
>
> The second one is that /usr/sbin/mountd contains a relink_command which uses pathes from the build host:
>
> relink_command="(cd /home/DRESEARCH/sledz/work/HydraIP/OE/tmp.3/work/armv5te-angstrom-linux-gnueabi/nfs-utils-1.1.2-r4/nfs-utils-1.1.2/utils/mountd;  ...
>
> Could someone please have a look at this.
>
> Thx,
> Steffen
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: nfs-utils-1.1.2 problem

[Steffen Sledz]

Chris Larson wrote:
> That sounds like a case of someone installing the libtool wrapper
> script into the rootfs instead of the real binary.  The do_install may
> be directly using 'install' to install it.  It should be changed to
> use a normal make install, or call out ${S}/${HOST_SYS}-libtool
> --mode=install install <rest of install command>.  NOTE: This is
> conjecture, I haven't read the recipe, or tested, but it's similar to
> an issue I hit last week.

Would be nice, if you can take a look at the recipe. I'm not that familiar with this libtool stuff.

Steffen

Re: nfs-utils-1.1.2 problem

[Steffen Sledz]

> Chris Larson wrote:
>> That sounds like a case of someone installing the libtool wrapper
>> script into the rootfs instead of the real binary.  The do_install may
>> be directly using 'install' to install it.  It should be changed to
>> use a normal make install, or call out ${S}/${HOST_SYS}-libtool
>> --mode=install install <rest of install command>.  NOTE: This is
>> conjecture, I haven't read the recipe, or tested, but it's similar to
>> an issue I hit last week.
> 
> Would be nice, if you can take a look at the recipe. I'm not that familiar with this libtool stuff.

Ping