| Summary: | gcc-config (1) fails the first update with catalyst on system where libgcc_s.so.1 is needed by 'mv' | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | FreeBSD | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bsd+disabled, catalyst, uberlord |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | FreeBSD | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | gcc-config-patch | ||
Created attachment 98931 [details, diff]
gcc-config-patch
catalyst should be running gcc-config automatically on $ROOT so stage1 should have libgcc_s.so.1 in the proper place I'll look at what catalyst is doing once we've gotten it moved to SVN, which is going on now. 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 :) fixed in cvs by not removing the file anymore; let the `mv` handle it |
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