| Summary: | uclibc fails second pass of bootstrap | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jory A. Pratt <geekypenguin> |
| Component: | [OLD] Core system | Assignee: | Embedded Gentoo Team <embedded> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | natanael.copa, yvasilev |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jory A. Pratt
2005-05-19 20:21:48 UTC
and if you try it with normal CFLAGS ? Even with normal CFLAGS it still fails same exact position. Can confirm this bug. It happened to me right after upgrading gcc form gcc-3.3.5-r1 to gcc-3.3.5.20050130-r2. With gcc-3.3.5-r1 I was able to emerge uclibc-0.9.27 just fine. Also i have to mention that this is with my modified gcc and uclibc ebuilds with soft vfp (see Bug #75585). But the behavior is just the same as the one exposed in Comment #1. My CFLAGS="-Os -march=armv4 -pipe -falign-functions=4 -falign-labels=4 -falign-loops=4 -falign-jumps=4" Yuri. Confirming that this also happens here with gcc version 3.4.4 (Gentoo Hardened 3.4.4, ssp-3.4.4-1.0, pie-8.7.8). Funny thing is that if I cd to the work dir and run make && ./vfork from command line, it seems to work. alpine-testing:/var/tmp/portage/uclibc-0.9.27/work/uClibc-0.9.27/test/unistd # ./vfork Hi. I'm the child process... Hello. I'm the parent process. total 196 drwxr-xr-x 2 root root 4096 Jun 3 07:15 ./ drwxr-xr-x 21 root root 4096 Jan 12 07:59 ../ -rw-r--r-- 1 root root 71 Jan 12 07:59 .cvsignore -rw-r--r-- 1 root root 3045 Jan 12 07:59 Makefile -rwxr-xr-x 1 root root 10208 Jun 3 07:04 fork* -rw-r--r-- 1 root root 2335 Jan 12 07:59 fork.c -rw-r--r-- 1 root root 5756 Jun 3 07:04 fork.o -rwxr-xr-x 1 root root 10208 Jun 3 07:04 fork_glibc* -rw-r--r-- 1 root root 5756 Jun 3 07:04 fork_glibc.o -rwxr-xr-x 1 root root 8375 Jun 3 07:15 getcwd* -rw-r--r-- 1 root root 1619 Jan 12 07:59 getcwd.c -rw-r--r-- 1 root root 3288 Jun 3 07:15 getcwd.o -rwxr-xr-x 1 root root 8698 Jun 3 07:15 getopt* -rw-r--r-- 1 root root 1104 Jan 12 07:59 getopt.c -rw-r--r-- 1 root root 4460 Jun 3 07:15 getopt.o -rwxr-xr-x 1 root root 8986 Jun 3 07:15 getopt_long* -rw-r--r-- 1 root root 1600 Jan 12 07:59 getopt_long.c -rw-r--r-- 1 root root 4632 Jun 3 07:15 getopt_long.o -rwxr-xr-x 1 root root 15042 Jun 3 07:15 preadwrite* -rw-r--r-- 1 root root 4004 Jan 12 07:59 preadwrite.c -rw-r--r-- 1 root root 8248 Jun 3 07:15 preadwrite.o -rwxr-xr-x 1 root root 8500 Jun 3 07:15 vfork* -rw-r--r-- 1 root root 1572 Jan 12 07:59 vfork.c -rw-r--r-- 1 root root 3216 Jun 3 07:15 vfork.o -rwxr-xr-x 1 root root 8500 Jun 3 07:15 vfork_glibc* -rw-r--r-- 1 root root 3216 Jun 3 07:15 vfork_glibc.o Child process exited. Goodbye. just for those of you who haven't found it yet, FEATURES="-sandbox" is a workaround until this gets fixed The work around that Brian suggest is *only* good if you are updating an already running system and/or if you do not pass build to emerge ... build however is automatically passed when bootstrap.sh is called. seems to be fixed as of late .. if it should re-occur later I will re-open |
