On Sun, Mar 25, 2012 at 12:42 PM, Joakim Tjernlund
<[email protected]> wrote:
>
>
> Khem Raj <[email protected]> wrote on 2012/03/25 20:23:04:
>
>> From: Khem Raj <[email protected]>
>> To: Joakim Tjernlund <[email protected]>
>> Cc: [email protected], [email protected], Mike Frysinger 
>> <[email protected]>
>> Date: 2012/03/25 20:23
>> Subject: Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option
>>
>> On Sun, Mar 25, 2012 at 10:30 AM, Joakim Tjernlund
>> <[email protected]> wrote:
>> >>
>> >> On Sun, Mar 25, 2012 at 12:58 AM, Mike Frysinger <[email protected]> 
>> >> wrote:
>> >> > On Sunday 25 March 2012 03:23:38 Khem Raj wrote:
>> >> >> On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger <[email protected]> 
>> >> >> wrote:
>> >> >> > The _start symbol is the default entry point for ELFs, so there 
>> >> >> > should be
>> >> >> > no need to manually specify this.  The background motivation is that 
>> >> >> > this
>> >> >> > causes issues for ports that have a symbol prefix (like Blackfin) 
>> >> >> > and so
>> >> >> > they don't have a "_start" symbol -- it's named "__start".
>> >> >>
>> >> >> on MIPS its also __start unlike others where it is _start
>> >> >
>> >> > ok, i'll ponder exposing __USER_LABEL_PREFIX__ to the build system 
>> >> > somehow
>> >> > then so it automatically selects the right "_start"
>> >>
>> >> if binutils/ld is configured for right emulation (which it should be)
>> >> that should take care of it automatically
>> >> though so your patch is ok.
>> >
>> > I think the problem is that ldso.c expects start to be named _start so
>> > you can't just rename it __start.
>> > You could define _start = __start in arch code that need it though.
>> >
>>
>> isnt it arch specific function in ldso/<arch>/dl-startup.h ?
>
> It is in ldso/ldso/ldso.c last I checked.
>

right thats the consumer of the definition so I think adding alias for __start
in the definition will fix this problem.

>  Jocke
>
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to