<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 29, 2017 at 8:21 PM, Martin Ward <span dir="ltr"><<a href="mailto:macros_the_black@ntlworld.com" target="_blank">macros_the_black@ntlworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 29/01/17 14:29, Ivan Kabaivanov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I've been an LFS user since 2000.  I have been building a pure 64bit LFS for a number of years, but now I'd like to start building a multilib one.<br>
<br>
I like how Debian and Arch are doing it:<br>
/lib and /usr/lib contain the 64bit libraries<br>
/lib64 is a link to /lib<br>
/usr/lib64 is a link to /usr/lib64<br>
/lib32 and /usr/lib32 contain the 32bit libraries.<br>
<br>
Ideally I would prefer *not* to have the lib64 link and just to have /lib and /usr/lib for 64bit and /lib32 /usr/lib32 for 32bit.<br>
<br>
This makes sense, is convenient as I build just a fraction of the packages for 32bitness and I don't want to specify --libdir=/usr/lib64 for the default build of 64bit packages.  A number of commercial software also seems to expect /lib and /usr/lib to be 64bit and /lib32 /usr/lib32 to be 32bit.<br>
<br>
So far I have a working set of commands to build the base system according to your convention (/lib and /usr/lib are 32bit, /lib64 and /usr/lib64 are 64bit), but I'd like the other way around.<br>
<br>
I've tried to modify the instructions and the gcc specs patch as needed (both gcc/config/i386/linux64 and gcc/config/i386/t-linux64) but I end up with a failure in <a href="http://test-installation.pl" rel="noreferrer" target="_blank">test-installation.pl</a> for the 64bit glibc.  gcc -m64 produces working binaries as once run the test prog prints 'Your new glibc installation seems to be ok.' but ldd reports a non-dynamic executable.  I'm guessing it can't find the linker, even though I did specify it with the sed command<br>
<br>
sed -i "s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=/lib/ld-li<wbr>nux-x86-64.so.2 -o|" scripts/<a href="http://test-installation.pl" rel="noreferrer" target="_blank">test-installation.pl</a><br>
<br>
If I patch glibc to skip <a href="http://test-installation.pl" rel="noreferrer" target="_blank">test-installation.pl</a> (I know, bad idea, but just for debugging), libgcc fails to find /lib/cpp and there goes my final gcc.<br>
<br>
I would appreciate any tips you have.  I will provide patches for the book commands so you can better understand what I'm modifying.<br>
<br>
And a suggestion.  Now that pure 32bit is being dropped left and right by the major distros, isn't it time to revisit the whole /lib, lib32, lib64 structure?  It makes so much more sense to me to treat 64bit as the "native" bitness and therefore use /lib and /usr/lib for it.  The extra arch is 32bit so treat it as the exception with /lib32 and /usr/lib32.<br>
<br>
Thanks,<br>
IvanK.<br>
<br>
<br>
</blockquote></div></div>
Hi<br>
<br>
The patch(es) that i sent earlier for adjusting the specs file should support multi-lib setup, as i went through and set the default lib dir to lib and the 32 bit to lib32 in tools and final system respectively<br>
<br>
here they are again, these are for gcc-6.x.0, if need other versions I think I  have them<br>
<br>
hope that helps<span class="HOEnZb"><font color="#888888"><br>
<br>
Martin<br>
<br>
<br><br></font></span></blockquote><div> <br></div><div>Thanks, Martin.</div><div><br></div><div>Your patches are exactly how I modified mine too.  Unfortunately, where I think I fail is in the actual parameters to binutils/glibc/gcc autoconf.  I mean --libdir, etc.</div><div><br></div><div>While the spec patches are an important part of it, they are not sufficient.  Looks like I have to read about all the slib rtldlib, etc params and try harder :-)</div><div><br></div><div>Thanks,</div><div>IvanK.</div></div><br></div></div>