On 28/06/2011 9.30, Carmelo AMOROSO wrote: > 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
count down started before pushing prelink changes into master... 10..9..8.. cheers, carmelo > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
