Hi,

First of all I am aware that LFS-6.8 and 7.0 RC1 expicitly state that they do not support multilib at present.

However, I am between a rock and a hard place called multilib.

the rock is a big application that controls hardware in real-time. it was written with the principle that a long is always 32bit, and Int could be anything so don't use it!

the OS must be upgraded from 32bit to 64bit, and currently it is based on pure 64bit compilation of LFS-6.8.

So now that 32bit long looks somewhat more like 64bit!

we could have looked to port our application into 64bit realm, which would have been someone else's problem. Unfortunately I must have drawn the short straw, as it is my problem that I must now produce a multilib version of LFS-6.8 instead (apparently a lesser task).

what I have done so far is:

binutils pass 1:
configure line now has --enable-multilib
I still create the symlink for /tools/lib64

gcc-pass1
removed --disable-multilib from configure line

adjusting
added a new part to the sed command in the SPECS file to make the following change:
*multilib:
. !m64 !m32;64:../lib64 m64 !m32;32:../lib !m64 m32;
to:
*multilib:
. !m64 !m32;.:../lib64 m64 !m32;../lib !m64 m32;
REFERENCE: http://connie.slackware.com/~alien/m.../source/README

binutils pass 2:
configure line now has --enable-multilib

gcc-pass 2
removed the sed command that deleted MULTILIB_OSDIRNAMES
removed --disable-multilib from configure line

From what I understand if I have installed binutils and gcc correctly in the first pass then when glibc is installed it will install appropriately in multilib. However, I still do not get a stub-32.h in /tools/include/gnu which is the compile error for gcc-pass 2.

and so that is my problem, where is stub-32.h?

how far off track am I? I'm obviously missing something.

Would greatly appreciate some advice,

thanks in advance,

Andy

after reading the following thread:
http://www.linuxquestions.org/questi...923/page2.html

which at first I dismissed, but since read to the end I have found that one poster weibullguy indicates that glibc would need to be compiled for each arch type (in my case, 32 and 64) using the host= parameter.

However, I am still quite unsure how this would work. Would I not just be overwritting the 64 support with 32 and vice/versa?

I need both at the same time.

has anyone does this before? My google searches are cluttered with peoples experiences on package managed distro's such as ubuntu where the thread concludes with install the dev package! Which makes it hard to find proper linux help

Take a look at CLFS... it does support multilib configurations.

Hi magiknight,

thanks for your response. Sorry it has taken me so long to reply.

I have indeed been looking at CLFS, I hadn't updated my progress because I was hoping for an alternative.


So CLFS adds a new chapter for the cross compile tools. Do I need this? It makes sense if you are compiling on two very different architectures such as PowerPC from X86. However I am compiling from x86_64 to x86_64 just with 32bit multi-lib.
CLFS uses cross-tools to compile temporary tools to compile basic system to avoid using the host compiler. However as my host and target architectures are the same. Surely I can use the host compiler to compile the temporary tools to compile the basic system as per LFS?

From my current understanding all I need to do is compile most of the basic system in both 32bit and 64 bit. To do this requries a multi-lib compatible tool chain. To do that I think (please correct me) I need a multi-lib compatible temporary tool chain.

but if that is true then it really becomes chicken and the egg. How do you create a multi-lib tool chain without a multi-lib tool chain?

----

furthermore I have some reason to believe CLFS approach may not be the best for my scenario because I have read from slackware to use --enable-multilib in the binutils. However this is not used in CLFS.


thanks in advance

Yes you do, the current LFS doesnt support multilib yet, this is being worked on. CLFS's book gives you an option to compile a multilib CLFS for the x86_64 and i686 builds.

Yes this is correct, and also a wrapper for certain packages like perl, so apps can invoke it in either 32 it 64 bit versions.

By creating cross-tools first then constructing a temporary system.


----

This is because Slackware miltilib support is a hack, also their are different ways to do things as well, if you look at Slackware's Ada support it's compiled last yet the shared ada libs are compiled the first time around...