On 27/06/2011 21.53, Khem Raj wrote: > On Mon, Jun 27, 2011 at 8:01 AM, Carmelo AMOROSO <[email protected]> > wrote: >> On 27/06/2011 10.25, Carmelo AMOROSO wrote: >>> On 24/06/2011 16.37, Carmelo AMOROSO wrote: >>>> On 13/06/2011 22.17, Khem Raj wrote: >>>>> On Mon, Jun 13, 2011 at 12:40 PM, Carmelo AMOROSO >>>>> <[email protected]> wrote: >>>>>> On 08/06/2011 23.22, Khem Raj wrote: >>>>>>> On Wed, Jun 8, 2011 at 2:17 PM, Bernhard Reutner-Fischer >>>>>>> <[email protected]> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> master is now potentially open to >>>>>>>> - merge future into master >>>>>>>> - merge prelink into master >>>>>>>> - merge ldso-future into master >>>>>>>> (in this order). >>>>>>>> >>>>>>>> To do this, ideally one would bring future up to date, then merge it >>>>>>>> back into master etc. >>>>>>>> >>>>>>>> Peter, do you see fit to >>>>>>>> $ git checkout future >>>>>>>> $ git pull --rebase (provided future is a proper tracking branch) >>>>>>>> $ git push -v >>>>>>>> $ git checkout master >>>>>>>> $ git merge origin/future >>>>>>>> # edit >>>>>>>> $ git add some/thing >>>>>>>> $ git commit -s some/thing >>>>>>>> etc, etc? >>>>>>>> >>>>>>>> Current future would most likely conflict in e.g. longjmp impl i.e. >>>>>>>> would need to be resolved after such merge (and i didn't look, TBH). >>>>>>>> >>>>>>>> Any takers? Khem, do you have time to explain and resolve that with >>>>>>>> peter? Anybody else? >>>>>>> >>>>>>> I can merge the future branch into master carefully >>>>>>> and also some patches that are on hold. >>>>>>> >>>>>>> Carmelo >>>>>>> >>>>>>> I think prelink branch should probably be merged in first. >>>>>>> >>>>>>> Thanks >>>>>>> -Khem >>>>>> >>>>>> Hi guys, >>>>>> sorry I was off from uClibc dev for a while... yes I'd prefer to merge >>>>>> prelink before, because it's just touch ldso stuff. >>>>>> >>>>>> Prelink has been merge with master multiple times, so it is almost >>>>>> up-to-date. I'll re-merge again, and if you agree, I can merge it back >>>>>> to master. >>>>>> >>>>> >>>>> Carmelo >>>>> >>>>> Yes thats my preference too. So please go ahead and I will wait >>>>> >>>> >>>> Hi, >>>> I've merge prelink with master, solved few conflicts and tested. >>>> I'm going to push prelink. Then I'll take care of merging it back to >>>> master. >>>> >>>> ok to proceed ? >>>> >>>> Cheers, >>>> Carmelo >>>> >>> >> >> Hi, >> >>> I've merged it and booted on SH4 board. Run C lib suite and prelink >>> suite without regression. >>> >> >> this the output on the target, showing the stand-alone mode capability. >> >> root@amorosoc:~# /lib/ld-uClibc.so.0 >> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] >> You have invoked `ld.so', the helper program for shared library executables. >> This program usually lives in the file `/lib/ld.so', and special directives >> in executable files using ELF shared libraries tell the system's program >> loader to load the helper program from this file. This helper program loads >> the shared libraries needed by the program executable, prepares the program >> to run, and runs it. You may invoke this helper program directly from the >> command line to load and run an ELF executable file; this is like executing >> that file itself, but always uses this helper program from the file you >> specified, instead of the helper program file specified in the executable >> file you run. This is mostly of use for maintainers to test new versions >> of this helper program; chances are you did not intend to run this program. >> >> --library-path PATH use given PATH instead of content of the environment >> variable LD_LIBRARY_PATH >> root@amorosoc:~# >> root@amorosoc:~# >> root@amorosoc:~# /lib/ld-uClibc.so.0 /bin/cat /proc/cpuinfo >> machine : hdk7106 >> processor : 0 >> cpu family : sh4 >> cpu type : STx7106 >> cut : 1.x >> cpu flags : fpu icbi synco fpchg >> cache type : split (harvard) >> icache size : 32KiB (2-way) >> dcache size : 32KiB (2-way) >> address sizes : 32 bits physical >> bogomips : 450.00 >> >> >> >>> Now testing on ARM CA9 (and probably on ARM9 if I get a booting kernel) >>> and let you now. >>> >> >> I've successfully booted a ARM CA9 core, and this is some outputs: >> >> ------------ >> root@amorosoc:~# /lib/ld-uClibc.so.0 >> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] >> You have invoked `ld.so', the helper program for shared library executables. >> This program usually lives in the file `/lib/ld.so', and special directives >> in executable files using ELF shared libraries tell the system's program >> loader to load the helper program from this file. This helper program loads >> the shared libraries needed by the program executable, prepares the program >> to run, and runs it. You may invoke this helper program directly from the >> command line to load and run an ELF executable file; this is like executing >> that file itself, but always uses this helper program from the file you >> specified, instead of the helper program file specified in the executable >> file you run. This is mostly of use for maintainers to test new versions >> of this helper program; chances are you did not intend to run this program. >> >> --library-path PATH use given PATH instead of content of the environment >> variable LD_LIBRARY_PATH >> root@amorosoc:~# >> root@amorosoc:~# >> root@amorosoc:~# /lib/ld-uClibc.so.0 /bin/cat /proc/cpuinfo >> machine : hdk7106 >> processor : 0 >> cpu family : sh4 >> cpu type : STx7106 >> cut : 1.x >> cpu flags : fpu icbi synco fpchg >> cache type : split (harvard) >> icache size : 32KiB (2-way) >> dcache size : 32KiB (2-way) >> address sizes : 32 bits physical >> bogomips : 450.00 >> ---------------------- >> >> I've got some problem on few tests referencing h_errno due to >> unsupported ARM relocations. This is due to the version of binutils I'm >> using (indeed I get the same errors on a vanilla master branch). >> >> I'll work to the ARM ld.so to include this support also. >> >> I think we are in the position to push it now. If you guys prefer to >> have a look before I push, I can create a temporary branch. Let me know. > > If you want to get the patches a final look then its ok. I am ok with pushing > it as it is. Since I will then test it on mips ppc and x86 soon after and any > breakage can be figured out. >
Hi khem, yes indeed I've liked that others have had a look at the prelink changes due to the huge impact on the ld.so, so I've pushed a branch 'integration/prelink_on_master' on ST git. http://git.stlinux.com/?p=stm/uclibc.git;a=shortlog;h=integration/prelink_on_master git clone git://git.stlinux.com/stm/uclibc.git integration/prelink_on_master I'll hold on other few days for other feedback, and then I'll push. Thanks, Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
