#1990 closed task (wontfix)
Coreutils uname patch
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | lowest | Milestone: | |
| Component: | Book | Version: | SVN |
| Severity: | minor | Keywords: | |
| Cc: |
Description
I would like LFS to start using the Coreutils uname_PIC patch so all the books can use the same patch. The PIC patch uses position independent assembly, so uname.c can compile with -fpie. It was adopted by Slackware (coreutils.uname.diff.gz) a while back and has since undergone use/testing by plenty of people. I can't see any reason why LFS shouldn't be using it.
Attachments (1)
Change History (5)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
I didn't know non-x86 had a patch for this. I blended the two patches together, and attached it. I'm not certain the x86_64 bit works, but the rest should. I tested it on my prescott and quantum's pentium4.
Both patches are insane, but there's no other standard way to detect the cpuid, so xorg and ffmpeg use assembly build-time tests, similar to this uname patch.
In my opinion, at the moment, I think the ideal fix for this is a kernel sysctl to identify the cpu and sub-arch.
I can't think of any reason a non-hlfs user would build uname.c with -fpie; but now that these patches are together lfs/clfs/hlfs can use the same patch... why not?
comment:3 by , 18 years ago
| Milestone: | → 6.3 |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
Let's leave this as-is for the moment. As others have pointed out, dropping the patch completely would be a functionality regression.
I've no objection to PIC code in itself, but this is an unusual use of all - If you care about other than x86, please check the clfs patch some time (just be careful not to overwrite any other patches of a similar name) - there are rather more architectures than just x86 and x86_64.
If you want LFS to use the patch, it might be more persuasive if you could explain why passing -fpie to coreutils is a useful thing to do in LFS, remembering that unlike HLFS we don't usually go out of our way to change how things are compiled.