| Summary: | cut -f1 does not work when built with -Os | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stefan Rystedt <ryz> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | bskerlecz, john, m.debruijne, manuel, pam-bugs+disabled, sandbox |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 74803 | ||
| Bug Blocks: | |||
|
Description
Stefan Rystedt
2005-02-06 15:03:40 UTC
Different issue then bug #74803 - yours can find cut, but cut -f1 seems to be hosed. I checked the cut sources, and also traced it, etc - it does not seem to use getenv at least, so I do not know about env variables influencing it. I have done some more testing and found out that 'cut -f 1 file' works. Here is the result from my new tests. sh-3.00# echo '1/2/3/4' | cut -f1 -d/ sh-3.00# echo '1/2/3/4' > file sh-3.00# cut -f1 -d/ file 1 sh-3.00# cut -f1 -d/ < file sh-3.00# As you can see if given cut a file as an argument everething works just fine but not if i redirect stdin. I am using bash 3.0-r7 and readline 5.0-r1 since i read some where that they had better suport for utf8 wich I use as default language. I would have made more sense if cut missbehaved all the time but it is only under emerge or ebuild. Why does these things allways happen to me :( Maby becasue I just can't keep my fingers of all the nice extra features I just have to have :-) does `echo '1/2/3/4' | cut -f1 -d/ -` work ? Nope that does not work. Should the last - really be there? I did not work ithere way. I am trying to run cut with ddd but I have a hard time to get ddd to find the sources of cut. I recompiling corutils with USE=debug FEATURES="noclean nostrip" emerge -v coreutils that should do it shouldn't it? yes, '-' tells cut that it should read stdin Oh I see. Whell I foud out why I could not get ddd to find the sources I had to give the -g flag to the compiler. I thought that the USE flag debug would do that. Any way after recompiling with the same comand as before except adding CFLAGS='-g -O0' cut started to work. So it does not only have to do with the enviroment it allso has to do with how it is compiled. The horriable flags I have set in the make.conf is CFLAGS="-Os -march=athlon-xp -pipe" not to much to brag about. Im going to do some testing to see what flags seems to break things. Well the cflag was -Os I though that this should be a safe flag. To sum everything up. If compiling coreutils with the optimazation flag -Os with gcc 3.3.5 cut with the flag -f1 will not work when runing under portage if the input comes from a redirected stdin. I just have to reapet myself why are these things happening to me. Let me now if you want to look into this bug more so that you want more info. I my self is now going to change the -Os flag to good old -O2 in my make.conf and hopfully live happy ever after:) You are free to close this bug if you want. -Os by itself is normally 'safe' ... it's when you add in -march / -mcpu that things get funky Whell in this case it is only the -Os flag since it breakes when I set the CFLAG='-Os -pipe' and nothing else. I have some more info if you are intrested. I read in the gentoo forums that some one else had a simulare problem and he had solved it with FEATURES="-sandbox" ebuild pam-0.77-r6.ebuild install So it looks like it is the -Os flag in combination with sandbox that breaks cut. I have not tested this myself. I could if you really want me to. Would be nice if you can manage it. I have tested with the FEATURES="-sandbox" and then it works. So it is only when coreutils is compiled with -Os and using sandbox this bugg appear. I am runnig portage as the root user. This bug seems to have many ramifications. Doing an emerge -e world with gcc 3.4.3 the I had problems with the following: pam: ebuild uses cut sun-jdk: ebuild uses cut tightvnc: uses gcc.class (that uses cut) to apply a patch libmpeg3: uses gcc.class ... piave: uses gcc.class ... kdenlive: uses gcc.class ... I assume that every build checking the gcc version to apply a patch conditionally is affected. I am happy using -Os in make.conf, so I think is better forcing the cflags just for the coreutils ebuild in case -Os is configured, adding to the ebuild replace-flags -Os -O2 && ewarn "Replacing -Os with -O2" In a quick test, coreutils-5.2.1-r4 now compiles with -O2 and piave get patched using gcc.class *** Bug 83338 has been marked as a duplicate of this bug. *** In my experience (bug 74803) I've found that it's a combination of -Os, LANG=XXX.UTF-8 and the sandbox. Any of those can be different and the problem will not occur. *** Bug 88420 has been marked as a duplicate of this bug. *** Can anybody try sandbox-1.2.10 with unstable portage and see if recompiling coreutils with -Os still causes this? Reopen if new info. |
