"as" has gone missing.

"as" has gone missing.

[Mike (mwester)]

Alas!  Sometime in the past - nobody here knows exactly when - "as" (the
assembler) has gone missing from the packages.  The "gcc" bitbake recipe
provides all manner of other packages, all of which can be installed, and
seem to provide the necessary compilation tools to build stuff on the target
device.  Except that the toolchain can't find "as" -- and as I peruse the
recipes, neither can I!

The assembler is built and placed on the buildhost (in the cross directory,
as one would expect), so clearly it's handled by something - just not the
"gcc" bb recipe.  The "gcc" recipe does not seem to build "as", and
certainly doesn't have any support for packaging it.

I am need of a clue, if anyone can offer some direction.  Might this be as
simple as a configuration option missing when gcc is built (and "as" should
be part of the "gcc" package), or is this a case where I'll have to add
support for a separate "as" package to the recipe?

Thanks,
Mike (~mwester)

Re: "as" has gone missing.

[pHilipp Zabel]

On Jan 2, 2008 4:18 PM, Mike (mwester) <mwester@dls.net> wrote:
> Alas!  Sometime in the past - nobody here knows exactly when - "as" (the
> assembler) has gone missing from the packages.  The "gcc" bitbake recipe
> provides all manner of other packages, all of which can be installed, and
> seem to provide the necessary compilation tools to build stuff on the target
> device.  Except that the toolchain can't find "as" -- and as I peruse the
> recipes, neither can I!
>
> The assembler is built and placed on the buildhost (in the cross directory,
> as one would expect), so clearly it's handled by something - just not the
> "gcc" bb recipe.  The "gcc" recipe does not seem to build "as", and
> certainly doesn't have any support for packaging it.
>
> I am need of a clue, if anyone can offer some direction.  Might this be as
> simple as a configuration option missing when gcc is built (and "as" should
> be part of the "gcc" package), or is this a case where I'll have to add
> support for a separate "as" package to the recipe?
>
> Thanks,
> Mike (~mwester)

binutils, binutils-symlinks

cheers
Philipp

Re: "as" has gone missing.

[Mike (mwester)]

"pHilipp Zabel" <philipp.zabel@gmail.com> writes:
...
> > I am need of a clue, if anyone can offer some direction.  Might this be
as
> > simple as a configuration option missing when gcc is built (and "as"
should
> > be part of the "gcc" package), or is this a case where I'll have to add
> > support for a separate "as" package to the recipe?
> >
> > Thanks,
> > Mike (~mwester)
>
> binutils, binutils-symlinks

Excellent, that (mostly) works.  So what's missing is the dependency in the
gcc package.  Does anyone have any particular heartburn if I add a RDEPENDS
= binutils to the gcc recipe?

(As for "mostly", it works, but there's a mismatch that might be important:
    $ gcc hello.c
    /usr/lib/gcc/armeb-linux/4.1.2/../../../../armeb-linux/bin/ld: Warning:
/tmp/cceIGUyh.o does not support interworking,
    whereas a.out does
    $
)

Mike (~mwester)

Re: "as" has gone missing.

[Richard Purdie]

On Wed, 2008-01-02 at 10:12 -0600, Mike (mwester) wrote:
> "pHilipp Zabel" <philipp.zabel@gmail.com> writes:
> ...
> > > I am need of a clue, if anyone can offer some direction.  Might this be
> as
> > > simple as a configuration option missing when gcc is built (and "as"
> should
> > > be part of the "gcc" package), or is this a case where I'll have to add
> > > support for a separate "as" package to the recipe?
> > >
> > > Thanks,
> > > Mike (~mwester)
> >
> > binutils, binutils-symlinks
> 
> Excellent, that (mostly) works.  So what's missing is the dependency in the
> gcc package.  Does anyone have any particular heartburn if I add a RDEPENDS
> = binutils to the gcc recipe?

Its not strictly an RDEPENDS. You would for example use odcctools+gcc if
you were on arm-darwin (this isn't a hypothetical example). This comes
back to the virtual and RPROVIDER mess I've commented on in the past. 

The thread was "[RFC] Handling of virtual/* namespace in packages" and I
proposed a VIRTUAL-RUNTIME namespace. In this case it would be a:

VIRTUAL_RUNTIME_binutils = "binutils"

and hence:

RDEPENDS = "${VIRTUAL_RUNTIME_binutils}

> (As for "mostly", it works, but there's a mismatch that might be important:
>     $ gcc hello.c
>     /usr/lib/gcc/armeb-linux/4.1.2/../../../../armeb-linux/bin/ld: Warning:
> /tmp/cceIGUyh.o does not support interworking,
>     whereas a.out does

Probably your libc was compiled with thumb interworking and your hello.c
was not. Using the correct gcc flags should remove the warning.

Cheers,

Richard

problem with nfs-kernel-server

[ohviey1]

Hi all.
I have a problem about server ethern on Arm MX21.
I try to mount file system with nfs and i ghave same error:
nfs: server 10.193.101.100 not responding, still 
trying                        
nfs: server 10.193.101.100 not responding, still 
trying                        
nfs: server 10.193.101.100 not responding, still 
trying                        
nfs: server 10.193.101.100 not responding, still 
trying                        
nfs: server 10.193.101.100 not responding, still 
trying                        
nfs: server 10.193.101.100 
OK                                                  
nfs: server 10.193.101.100 
OK                                                  
nfs: server 10.193.101.100 OK                             

I have a Gigabyte ethernet.
Anyone know why.

Thanks a lot.