coreutils-native-7.2-r0 dependencies not checked

coreutils-native-7.2-r0 dependencies not checked

[Alexander Stohr]

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

Re: coreutils-native-7.2-r0 dependencies not checked

[Denys Dmytriyenko]

On Tue, Sep 28, 2010 at 05:10:21PM +0200, Alexander Stohr wrote:
> hello,

Hi,

Sorry for top-posting...

> | make: GNUmakefile: Too many levels of symbolic links

This is a known issue - please make sure you don't have simlinks in your 
TMPDIR. If you need to offload portions of your TMPDIR to another partition 
or other place, adjust the corresponding variables instead of symlinking...

-- 
Denys


> 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
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: coreutils-native-7.2-r0 dependencies not checked

[Alexander Stohr]

>> | make: GNUmakefile: Too many levels of symbolic links
>
>This is a known issue - please make sure you don't have simlinks in your 
>TMPDIR. If you need to offload portions of your TMPDIR to another partition 
>or other place, adjust the corresponding variables instead of symlinking...
>--
>Denys

Hello Denys,
Thanks for that reply.

My whole build dir got symlinked into the home dir due to disk space issues.
But there are no symlinks in the temp dir area as far as i can say.
A somewhat strange behavior. I never noticed tools stumbling across such.


My not that deeply tested, first shot, cheap cheat is that:

do_compile_prepend() {
        cd ${S}
        if [ -L GNUmakefile ]
        then
                rm -f GNUmakefile
                ln -s Makefile GNUmakefile
        fi
}

i've added that to the non-native recipes of the coreutils, m4 and autoconf.
lets see how far that will work for me in my setup.
the build has already flawlessly proceeded to task 181 containing the binutils-cross compilation...

regards, Alex.

PS:
later on i found those discussion mentioning three recipe names from above:
http://old.nabble.com/failing-to-make-u-boot-omap3,-Too-many-levels-of-symbolic-links-td27315933.html

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail