On Thu, Dec 29, 2016 at 12:59 AM, Hazel Russman <[email protected]> wrote:
> On Wed, 28 Dec 2016 23:47:45 +0100 > Frans de Boer <[email protected]> wrote: > > > I have said that I will forward some patches to get rid of the > > [...]/lib64 notions after I have tested my older patches against the > > newest sources. > > > > I have created several source code changes and tested them, only to find > > out that glibc, gcc, libcap and perl have at some places hard coded the > > path to [...]/lib64 if an x86_64 machine is detected. I can change most > > of it with good result. > > > > Still I do not send the changes yet because I am more and more convinced > > that on machines with multiarch capabilities one should always use a > > qualifier in the directory name for libraries. > > Now, LFS is about teaching others how to start building your own > > operating system and minimal support utilities. The project started out > > in the era of 32-bit machines, adopted the 64-bit machine on the fly by > > use of links to legacy library directories who's naming is no longer > > discriminatory any more. What if we slip into the 128-bit (or +64-bit) > > era? Still using the legacy [...]/lib notion? > > The mail list has already many questions about the naming, maybe time to > > step into the current reality? > > > > Looking at production machines, with current UNIX and Linux > > distributions, many of them are already using a schema which > > differentiate already between bit sizes. > > Currently, I have a conversation on the FHS mailing list of due to the > > ambiguous nature of qualifiers. > > > > A snippet from the latest mail exchange: > > That said, I can appreciate also the idea that on hardware capable of > > handling multiple architectures - read size of data paths - you always > > use qualifiers, regardless if only one or multiple library directories > > are used. So my previous second proposal is then augmented into: > > > > [/usr[/local]]/lib<qualifier> for each different set of libraries > > > > For compatibility one should also add > > [/usr/[/local]]/lib -> [/usr[/local]]/lib<qualifier> > > Where .../lib links to the library directory supporting the native bit > > size. > > > > This implies that on 32-bit intel like systems, you always have a > > [...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link > > to [...]/lib32. > > On 64-bit Intel like systems you have [...]/lib64, an optional > > [...]/lib<32|16> and [...]/lib is a link to [...]/lib64. > > > > The above schema is already in widespread use on 64-bit machines, with > > the exception of the legacy use of [...]/lib for 32-bit library > directories. > > Also, modification of sources for glibc, gcc, libcap, perl etc, are not > > needed anymore. Due to the fact that some of these packages are core > > packages and it would require a lot of effort for the maintainers to > > change their current hard coded assumptions into more flexible code. > > ------------------- > > > > I wait to see where this all is going before I decide what to do with > > the current patches. Note that there are more patches required then > > currently given in the LFS development branch. > > > > Regards, Frans. > > > Will this change do away with the very annoying screens of warning > messages from package libtool scripts about libraries seemingly having > moved? I'm sure I'm not the only person who finds them off-putting. > -- Our current setup (thanks to DJ) gets rid of them entirely. I haven't seen a single one
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
