future merge

Carmelo AMOROSO carmelo.amoroso at st.com
Fri Jul 1 07:29:59 UTC 2011


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 <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.
>>
> 
> 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
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 



More information about the uClibc mailing list