On Mon, Jun 27, 2011 at 8:01 AM, Carmelo AMOROSO <carmelo.amor...@st.com> 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 >>>> <carmelo.amor...@st.com> wrote: >>>>> On 08/06/2011 23.22, Khem Raj wrote: >>>>>> On Wed, Jun 8, 2011 at 2:17 PM, Bernhard Reutner-Fischer >>>>>> <rep.dot....@gmail.com> 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. > > Cheers, > Carmelo > > >> >>>>> Carmelo >>>>> >>>>> >>>>>> ________ >>>>> >>>>> >>>>> _______________________________________ >>>>>> uClibc mailing list >>>>>> uClibc@uclibc.org >>>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>>> >>>>> >>>>> _______________________________________________ >>>>> uClibc mailing list >>>>> uClibc@uclibc.org >>>>> http://lists.busybox.net/mailman/listinfo/uclibc >>>>> >>>> >>> >>> _______________________________________________ >>> uClibc mailing list >>> uClibc@uclibc.org >>> http://lists.busybox.net/mailman/listinfo/uclibc >>> >> >> _______________________________________________ >> uClibc mailing list >> uClibc@uclibc.org >> http://lists.busybox.net/mailman/listinfo/uclibc >> > > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc