Bug 150257 – gcc-config (1) fails the first update with catalyst on system where libgcc_s.so.1 is needed by 'mv'

• Status: RESOLVED FIXED
• Product: Gentoo/Alt

[Description Diego Elio Pettenò (RETIRED) 2006-10-06 05:33:39 UTC]

As per summary, currently the way to update libgcc_s.so.1 make impossible for catalyst to update the gcc profile the first time when the linker does not know to look into gcc's own directories and libgcc_s.so.1 is needed by the mv command.

${MV} -f "${ROOT}/${libdir}"/.gcc.config.new/* "${ROOT}/${libdir}"/

will fail if mv tries to load the just-removed libgcc_s.so.1 library.
This affects Gentoo/FreeBSD but might affect also Gentoo Linux on some architectures.

The attached patch makes sure that a copy of libgcc_s.so.1 is always found in the process.

Thanks,
Diego

[Comment 1 Diego Elio Pettenò (RETIRED) 2006-10-06 05:34:15 UTC]

Created attachment 98931 [details, diff]
gcc-config-patch

[Comment 2 SpanKY 2006-10-06 13:04:07 UTC]

catalyst should be running gcc-config automatically on $ROOT so stage1 should have libgcc_s.so.1 in the proper place

[Comment 3 Chris Gianelloni (RETIRED) 2006-10-11 06:02:24 UTC]

I'll look at what catalyst is doing once we've gotten it moved to SVN, which is going on now.

[Comment 4 Roy Marples (RETIRED) 2006-10-15 08:37:34 UTC]

I'm not sure this is a catalyst issue as I ran into the same thing just doing

ROOT=/stage3 emerge -e system
Diegos patch fixes this on my Gentoo/FreeBSD/Sparc64 :)

[Comment 5 SpanKY 2006-10-18 21:01:23 UTC]

fixed in cvs by not removing the file anymore; let the `mv` handle it