Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#1990 closed task (wontfix)

Coreutils uname patch

Reported by: robert@… Owned by: lfs-book@…
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)

coreutils-6.9-insane_uname.diff3 (8.1 KB ) - added by robert@… 17 years ago.
multi-arch uname patch

Download all attachments as: .zip

Change History (5)

comment:1 by ken@…, 17 years ago

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.

by robert@…, 17 years ago

multi-arch uname patch

comment:2 by robert@…, 17 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 Matthew Burgess, 17 years ago

Milestone: 6.3
Resolution: wontfix
Status: newclosed

Let's leave this as-is for the moment. As others have pointed out, dropping the patch completely would be a functionality regression.

comment:4 by Jeremy Huntwork, 17 years ago

Milestone: 6.3

Milestone 6.3 deleted

Note: See TracTickets for help on using tickets.