even "stable" branch of OE for angstrom fails on module-init-tools

even after i switched back to the stable/2009 branch, "bitbake
base-image" generates the following build error:

ccache gcc
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-O2 -Wunused -Wall -static
-L/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-O1 -o insmod.static insmod.o
mv -f .deps/tables.Tpo .deps/tables.Po
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [insmod.static] Error 1
make: *** Waiting for unfinished jobs....
modinfo.c: In function 'main':
modinfo.c:338: warning: 'infosize' may be used uninitialized in this
function
mv -f .deps/modinfo.Tpo .deps/modinfo.Po
make: *** wait: No child processes. Stop.
FATAL: oe_runmake failed

  this was from the log file
work/armv7a-angstrom-linux-gnueabi/module-init-tools-cross-3.2.2-r5/temp/log.do_compile.23204

rday

This is specific to OE, not beagleboard, please use OE mailing list.

How have you switched branch? Have you purged tmp/ directory before
recompilation?

and this is where i'm going to respectfully disagree. there's been
quite the discussion lately about the pros and cons of using OE to
build a working image as opposed to doing all that work yourself. and
in all that discussion, the one major point that's been made about OE
is that it takes all the work out of it, and it allows relative
beginners to build and test an image.

  what that suggests is that, if i follow the instructions (and i
think i have) for building an angstrom image, it should just *work*.
and it doesn't.

  now, it may very well be an OE issue, but that's not *my* problem.
if i follow the instructions on how to build angstrom, and those
instructions fail, then i submit that it's the *angstrom* maintainer's
responsibility to provide a fix. if the online directions claim to
provide a recipe for doing something, and those directions don't work,
then the person responsible for those directions should take care of
it.

  put another (and admittedly more blunt way), if the online
instructions don't work, they should be fixed, or a disclaimer should
be added that they don't work.

rday

>
> even after i switched back to the stable/2009 branch, "bitbake
> base-image" generates the following build error:

This is specific to OE, not beagleboard, please use OE mailing list.

and this is where i'm going to respectfully disagree. there's been
quite the discussion lately about the pros and cons of using OE to
build a working image as opposed to doing all that work yourself. and
in all that discussion, the one major point that's been made about OE
is that it takes all the work out of it, and it allows relative
beginners to build and test an image.

what that suggests is that, if i follow the instructions (and i
think i have) for building an angstrom image, it should just *work*.
and it doesn't.

now, it may very well be an OE issue, but that's not *my* problem.
if i follow the instructions on how to build angstrom, and those
instructions fail, then i submit that it's the *angstrom* maintainer's
responsibility to provide a fix. if the online directions claim to
provide a recipe for doing something, and those directions don't work,
then the person responsible for those directions should take care of
it.

put another (and admittedly more blunt way), if the online
instructions don't work, they should be fixed, or a disclaimer should
be added that they don't work.

You wrote lots of words with no much sense. Just answer - have you
tried to setup *new* build environment for stable/2009 or *reuse* old
one? If the second is what you've done then don't blame OE that it
doesn't work for you - you made mistake while setup build system.

As an OE guy, I do not mind the occasional post of a beagle build
issue here. Obviously, the more complex issues should be discussed on
the OE list, since there is a larger pool of OE knowledge there.

To Robert's problem, I had built console-image from stable, and just
built base-image successfully.

Can you try console-image and see what happens? Also, are you cleaning
tmp after switching branches?

Philip

>
> even after i switched back to the stable/2009 branch, "bitbake
> base-image" generates the following build error:

This is specific to OE, not beagleboard, please use OE mailing list.

and this is where i'm going to respectfully disagree. there's been
quite the discussion lately about the pros and cons of using OE to
build a working image as opposed to doing all that work yourself. and
in all that discussion, the one major point that's been made about OE
is that it takes all the work out of it, and it allows relative
beginners to build and test an image.

I'm not arguing about the usefulness of OE, there's a place to discuss
OE issues, and this ml is not it.

what that suggests is that, if i follow the instructions (and i
think i have) for building an angstrom image, it should just *work*.
and it doesn't.

now, it may very well be an OE issue, but that's not *my* problem.
if i follow the instructions on how to build angstrom, and those
instructions fail, then i submit that it's the *angstrom* maintainer's
responsibility to provide a fix. if the online directions claim to
provide a recipe for doing something, and those directions don't work,
then the person responsible for those directions should take care of
it.

put another (and admittedly more blunt way), if the online
instructions don't work, they should be fixed, or a disclaimer should
be added that they don't work.

Which instructions?

This seems to the an appropriate place to discuss your issues:
http://www.angstrom-distribution.org/contact

Why only the complex issues? I'd say all the issues should be discussed there.

>
>
>> >
>> > even after i switched back to the stable/2009 branch, "bitbake
>> > base-image" generates the following build error:
>>
>> This is specific to OE, not beagleboard, please use OE mailing
>> list.
>
> and this is where i'm going to respectfully disagree. there's
> been quite the discussion lately about the pros and cons of using
> OE to build a working image as opposed to doing all that work
> yourself. and in all that discussion, the one major point that's
> been made about OE is that it takes all the work out of it, and it
> allows relative beginners to build and test an image.
>
> what that suggests is that, if i follow the instructions (and i
> think i have) for building an angstrom image, it should just
> *work*. and it doesn't.

As an OE guy, I do not mind the occasional post of a beagle build
issue here. Obviously, the more complex issues should be discussed
on the OE list, since there is a larger pool of OE knowledge there.

  absolutely, but at the risk of beating on this just a bit more, the
overwhelming value of OE for building these images is that one
*doesn't* need to become an OE expert to use it. quite simply, if one
has a step-by-step recipe in front of them, that leaves one to just
blindly follow those steps, which allows one to quickly get into
mucking around with angstrom, and that's the goal here, right? the
main claim for OE is that it just *works*, so if it doesn't, that's a
problem.

To Robert's problem, I had built console-image from stable, and just
built base-image successfully.

  so what that suggests is that there's something about *my* setup
that's not quite right, but it has to be something subtle since i keep
hitting that same error *every* *time*. as you can see, a *huge*
amount of the build works, but it's that package that fails each time.
so now we try to isolate what's so different about my setup related to
that specific package.

Can you try console-image and see what happens? Also, are you
cleaning tmp after switching branches?

  i'll try console-image right away. and as far as cleaning, what i
do is "rm" the entire angstrom-dev/ directory. can i assume that that
represents as ruthless a clean as i can get?

rday

p.s. for what it's worth, i'm testing this on a fully-updated fedora
11 x86_64 preview system, so this is not what you'd call an obscure
setup. if this fails for me, it's going to fail for a lot of other
folks running fedora.

yes, i agree -- it's technically an angstrom issue, not a BB issue.
the reason i posted here is that, from what i've seen, angstrom is not
just one of the possibilities for the beagleboard, it's a *major*
choice for people who want to jump into playing with a BB. so i
figured there would be enough people around who might have seen what i
ran across and could say, "rob, you idiot, you forgot to felch the
frotting pin." or something.

  anyway, i'm taking a crack at building the console-image to see if i
get a different result. perhaps there's something related to my
version of gcc -- gcc-4.4.0-4.x86_64 -- that's mucking with building
the module-init-tools package.

rday

p.s. speaking of felching the frotting pin, and for no good reason
whatsoever:

http://www.youtube.com/watch?v=VcnbfHGPxT0

enjoy.

Anything that is a 'preview' is obscure *by definition*, that said, people have reported success with F11 preview and OE.

regards,

Koen

given that F11 is pretty much in lockdown with general release only
a few days away, if something doesn't work now, it's almost certainly
still going to be broken with the official release. but i take your
point that others seem to have it working. how odd.

  i wonder if my running x86_64 has anything to do with it. i'll keep
testing.

rday

And incase anyone of a nervous disposition decides to google “define: feltching” I’d have to recommend they don’t…

same error building console-iamge:

ccache gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\"
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE=\"module-init-tools\" -DVERSION=\"3.2.2\" -I.
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-O2 -Wunused -Wall -MT modinfo.o -MD -MP -MF .deps/modinfo.Tpo -c -o
modinfo.o modinfo.c
mv -f .deps/tables.Tpo .deps/tables.Po
ccache gcc
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-O2 -Wunused -Wall -static
-L/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-O1 -o insmod.static insmod.o
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [insmod.static] Error 1
make: *** Waiting for unfinished jobs....
modinfo.c: In function 'main':
modinfo.c:338: warning: 'infosize' may be used uninitialized in this
function

  frankly, i didn't expect the result to be any different than when
building base-image, since i couldn't imagine why the build process
for a common package would differ.

  thoughts?

rday

p.s. this is running task 1064 of 2928 so, clearly, a lot of the
build has taken place before this failure. if i had something clearly
misconfigured, i would have expected build failure right off the bat.
the fact that it made it that far in before failing suggests an issue
with that package, but that's just a guess.

To Robert's problem, I had built console-image from stable, and just
built base-image successfully.

Can you try console-image and see what happens? Also, are you
cleaning tmp after switching branches?

same error building console-iamge:

ccache gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\"
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE=\"module-init-tools\" -DVERSION=\"3.2.2\" -I.
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-O2 -Wunused -Wall -MT modinfo.o -MD -MP -MF .deps/modinfo.Tpo -c -o
modinfo.o modinfo.c
mv -f .deps/tables.Tpo .deps/tables.Po
ccache gcc
-isystem/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/include
-O2 -Wunused -Wall -static
-L/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-rpath,/home/rpjday/oe/angstrom-dev/staging/x86_64-linux/usr/lib
-Wl,-O1 -o insmod.static insmod.o
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [insmod.static] Error 1
make: *** Waiting for unfinished jobs....
modinfo.c: In function 'main':
modinfo.c:338: warning: 'infosize' may be used uninitialized in this
function

frankly, i didn't expect the result to be any different than when
building base-image, since i couldn't imagine why the build process
for a common package would differ.

thoughts?

rday

p.s. this is running task 1064 of 2928 so, clearly, a lot of the
build has taken place before this failure. if i had something clearly
misconfigured, i would have expected build failure right off the bat.
the fact that it made it that far in before failing suggests an issue
with that package, but that's just a guess.

Don't make a monkey job trying to build different images. Just setup
your build environment properly and rebuild all from scratch as it was
already suggested, several times.

That error implies that the compiler on your host (the fedora gcc) can't find the c library of your host, so I suspect the fedora gcc doesn't have /lib/ in its searchpatch or something.

regards,

Koen

then i'm completely confused as to why gcc would have a problem with
module-init-tools when it built all of the other packages up to that
point. how odd. i'm starting to think it has to do with this being a
64-bit system, and gcc is somehow mixing up /lib vs /lib64 and
/usr/lib vs /usr/lib64. i can't think of anything else.

  i'll give it some more thought. thanks.

rday

> put another (and admittedly more blunt way), if the online
> instructions don't work, they should be fixed, or a disclaimer
> should be added that they don't work.

Which instructions?

This seems to the an appropriate place to discuss your issues:
http://www.angstrom-distribution.org/contact

yes, i agree -- it's technically an angstrom issue, not a BB issue.
the reason i posted here is that, from what i've seen, angstrom is not
just one of the possibilities for the beagleboard, it's a *major*
choice for people who want to jump into playing with a BB. so i
figured there would be enough people around who might have seen what i
ran across and could say, "rob, you idiot, you forgot to felch the
frotting pin." or something.

And there are not enough people on the angstrom mailing list?

anyway, i'm taking a crack at building the console-image to see if i
get a different result. perhaps there's something related to my
version of gcc -- gcc-4.4.0-4.x86_64 -- that's mucking with building
the module-init-tools package.

Please do, and report your further problems somewhere else.

Hello,

i think i already posted that the solution was to, on my fedora 11
system, install the "glibc-static" package. apparently, f11 is the
first version of fedora that split out that static component into a
separate package, which is why the build would have worked fine on
earlier versions of fedora but not f11. so:

  # yum install glibc-static

and all was well.

rday