Greg Schafer wrote:
Ryan Oliver wrote:It would take 5 minutes to generate a simple patch to do this (even byYep, 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]
gcc-4.3.2-add_multilib_b_option-1.patch
Description: Binary data
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
