All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander Stohr" <Alexander.Stohr@gmx.de>
To: openembedded-devel@lists.openembedded.org
Subject: coreutils-native-7.2-r0 dependencies not checked
Date: Tue, 28 Sep 2010 17:10:21 +0200	[thread overview]
Message-ID: <20100928151021.271550@gmx.net> (raw)

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



             reply	other threads:[~2010-09-28 15:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28 15:10 Alexander Stohr [this message]
2010-09-28 16:09 ` coreutils-native-7.2-r0 dependencies not checked Denys Dmytriyenko
  -- strict thread matches above, loose matches on Subject: below --
2010-09-28 17:29 Alexander Stohr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100928151021.271550@gmx.net \
    --to=alexander.stohr@gmx.de \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.