[oe] coreutils-native-7.2-r0 dependencies not checked

Alexander Stohr Alexander.Stohr at gmx.de
Tue Sep 28 15:10:21 UTC 2010


hello,

to me the mentioned package seems to be very picky
on having the right build environment in place.

the downloaded zip file comes with a ./configure file
that was seemingly built with autoconf 2.63b. (where does
those "b" version originate from? is it some distribution?)
on the official download location (ftp://ftp.gnu.org/gnu/autoconf/)
there is only autoconf 2.63 - so i used that for the build.

the zip file further contains a "GNUmakefile" of unknown origin.


for informational purposes, i used bitbake 1.8.18 as the outermost tooling
and the openembedded platform used was based on files using this command:

  git checkout -b stable/2009 6be05ba2dd55508addf5a21408f6dbbf5a62c3aa

when doing a build from scratch on that file
there were only two recipes built in front of coreutils-native.
that were shasum-native and stagemanager-native


the build failed at beginning of coreutils-native "compile" for this reason:

| NOTE: make -j2
| make: GNUmakefile: Too many levels of symbolic links
| make: stat: GNUmakefile: Too many levels of symbolic links
| make: *** No rule to make target `GNUmakefile'.  Stop.
| FATAL: oe_runmake failed

Inspection of the work dir showed a cyclical symlink of that form:

  GNUmakefile -> GNUmakefile

Further there was a newly generated Makefile bearing that headline
(that seemingly resembles the freshly unpacked Makefile.in):

  # Makefile.in generated by automake 1.10c from Makefile.am.

the file ./configure was still unaltered. it contained a line:

  GNUmakefile=GNUmakefile


i later on tried to improve the situation with a
"make distclean" and further steps but without success.
i tried autoconf 2.68 but again no success for the build.

If it would have been simply related to the used version of autoconf
i would have said, add a version check for it into the build.
right now i am not sure at all whats wrong there.


seemingly that single line in configure is responsible
for the symlink that kills the build in the end.
but if several others can build that why should it fail for me?
whats running odd for me in the beginning? how is it resolved best?

regards, Alex.
-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl




More information about the Openembedded-devel mailing list