future merge

Khem Raj raj.khem at gmail.com
Mon Jun 27 19:53:36 UTC 2011


On Mon, Jun 27, 2011 at 8:01 AM, Carmelo AMOROSO <carmelo.amoroso at 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.amoroso at 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.nop at 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 at 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 at amorosoc:~#
> root at amorosoc:~#
> root at 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 at 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 at amorosoc:~#
> root at amorosoc:~#
> root at 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 at uclibc.org
>>>>>> http://lists.busybox.net/mailman/listinfo/uclibc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> uClibc mailing list
>>>>> uClibc at uclibc.org
>>>>> http://lists.busybox.net/mailman/listinfo/uclibc
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> uClibc mailing list
>>> uClibc at uclibc.org
>>> http://lists.busybox.net/mailman/listinfo/uclibc
>>>
>>
>> _______________________________________________
>> uClibc mailing list
>> uClibc at uclibc.org
>> http://lists.busybox.net/mailman/listinfo/uclibc
>>
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>


More information about the uClibc mailing list