Adapting LFS SVN for multilib

[Ryan Oliver]

Greg Schafer wrote:
> Ryan Oliver wrote:
>
>   
>> It would take 5 minutes to generate a simple patch to do this (even by
>>     
>
> Yep, of course. But even blind Freddie can see it won't be accepted by
> upstream. Feel free to try.
>   

Very quick patch attached.

Patch is there for you to have a play around with as a starting point...

(for upstream they may want lib_str to be
#define static const char lib_str[]  { DIR_SEPARATOR, "lib", 
DIR_SEPARATOR, 0 }
somewhere at the top of gcc.c, possibly with "lib" replaced by a macro.
This dispenses with the xmalloc, concat and free.
Also they may not like the way I have done the strcmp, but hey, we 
aren't altering the contents of value...)

Getting anything accepted upstream generally has more chance when you 
have more than one person making the request...
If there isn't really an accepted need more voices can generally push it 
up the priority level...

If you come up with something better and want to push it upstream (you 
have more chance as the original requester), I'll happily add my voice 
to the list.

> Which reminds me, why has CLFS been carrying around the "Binutils Multilib
> Patch" for years without ever submitting upstream? Don't have the balls?
> Why hasn't anybody else needed it? Maybe the functionality isn't actually
> needed? It's disgraceful CLFS behavior. Please fix it.
>
>   

Yeah, my issue with sending it upstream is due to the fact that the way 
genscripts works you cannot do what is required sanely with regard to 
whatever is set as --libdir.

Each pass of genscripts.sh has no knowledge of any of the other 
emulations to be used by the ld being built.
That makes it hard to stop 64bit lib paths being set in the 32bit linker 
scripts in a sane manner if --libdir was set, say,  /tools/lib64 or 
/usr/lib64
This is listed in the patch comments.
( 
http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/binutils-2.19-genscripts_multilib-1.patch 
)

I've always meant to get back to this and look at how to handle it 
properly, but frankly genscripts.sh (well the whole genscripts process) 
makes my eyes bleed and I haven't had the time.


The need for the patch, well, perform the sanity check 32bit after 
readjusting the toolchain ch6 and see where it finds ld-linux.so.

Without the patch when setting --with-libpath or LIB_PATH you will get 
exactly what you ask for.
You will note in your 32bit ldscripts (and hence inbuilt linker scripts) 
that the search path is /tools/lib64,  or /lib64:/usr/lib64 for ld-new.

As for the ld-linux.so.2 found after adjustment, we both know this is 
probably just cosmetic (runtime it is stamped to use /lib/ld-linux.so as 
dynamic linker)
Patch is there to ensure if we fall through to ld's search paths for 
locating libraries etc which are needed but not explicitly defined 
during link time that ld will do the right thing.

No-one else uses the patch because no-one else uses --with-libpath or 
sets LIB_PATH during make.

Possibly it would be somewhat useful to split the patch up and send the 
sections dealing with LIB_PATH handling alone upstream...
As for --libdir handling, I am open to ideas...

> It's been a good discussion.
>   
Yeah it has been.

Maybe next time we can try to avoid making things personal...
We have different goals, but we should try to debate the differences 
without resorting to disparaging comments.or using loaded terms.
> Regards
> Greg
>   

Best Regards
[R]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-4.3.2-add_multilib_b_option-1.patch
Type: application/octet-stream
Size: 1230 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20090115/7e85354d/attachment.obj