Re: [PATCH] libm: Export bessel functions
On Fri, Jan 20, 2012 at 7:52 AM, Khem Raj wrote: > > > On Thursday, January 19, 2012, Bernhard Reutner-Fischer > wrote: >> On 20 January 2012 08:05, Khem Raj wrote: >>> Currently j0,j1,jn and y0,y1 and yn >>> are defined but with hidden visibility >>> With this patch we export them and also >>> keep a hidden alias for internal use >> >> They are visible for me: >> $ nm -D --def lib/libm-0.9.33-rc1-git.so | grep jn >> a1fc T jn >> > I am using gcc4.6 and bin utile 2.22 > I dont see them discard this patch, I think I was looking at wrong outputs > > >> Do you have DO_XSI_MATH=y ? > > Yes > >> ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libm: Export bessel functions
On Thursday, January 19, 2012, Bernhard Reutner-Fischer < rep.dot@gmail.com> wrote: > On 20 January 2012 08:05, Khem Raj wrote: >> Currently j0,j1,jn and y0,y1 and yn >> are defined but with hidden visibility >> With this patch we export them and also >> keep a hidden alias for internal use > > They are visible for me: > $ nm -D --def lib/libm-0.9.33-rc1-git.so | grep jn > a1fc T jn > I am using gcc4.6 and bin utile 2.22 I dont see them > Do you have DO_XSI_MATH=y ? Yes > ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: fix signal handling in system()
On Tue, Jan 17, 2012 at 10:33:10AM +0100, Richard Braun wrote: > When built without NPTL support (or for a sparc target), the system() > function doesn't conform to its specification. Namely, it uses signal() > to install/save/restore signal handlers, which may break applications > using custom handlers installed with sigaction(). In addition, it resets > the SIGCHLD handler to SIG_DFL instead of blocking the signal, which may > result in "lost" signals if a custom handler was installed. > > Fix system() by replacing uses of signal() with appropriate calls to > sigaction() and sigprocmask(). > > Signed-off-by: Richard Braun Quick reminder to apply this patch, as the thread has now been quiet for a few days. -- Richard Braun ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations
On 20/01/2012 7.55, Khem Raj wrote:
> On Thu, Jan 19, 2012 at 6:42 AM, Carmelo AMOROSO
> wrote:
>> On 19/01/2012 15.28, Carmelo AMOROSO wrote:
>>> Fill properly the sym_ref fields when invoking _dl_find_hash to lookup
>>> symbols
>
> this did not make the segfault go away. Although this patch is ok.
> this problem is a crash in libstdc++ I did not have debug info to
> get more info but I am building an image with debug info
>
I can't help with mips. As soon as you have some debug out, I can try to
figure out where the problem is.
I've looked at the change history of mips/elfinterp.c, I'm not seeing
currently other fix than this one, but I'll keep on looking at this.
Carmelo
>>>
>>> Signed-off-by: Carmelo Amoroso
>>> ---
>>> ldso/ldso/mips/elfinterp.c |4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c
>>> index b748839..5d0eff5 100644
>>> --- a/ldso/ldso/mips/elfinterp.c
>>> +++ b/ldso/ldso/mips/elfinterp.c
>>> @@ -161,7 +161,7 @@ int _dl_parse_relocation_information(struct dyn_elf
>>> *xpnt,
>>> unsigned long old_val=0;
>>> #endif
>>>
>>> - struct symbol_ref sym_ref = { NULL, NULL };
>>> + struct symbol_ref sym_ref;
>>> /* Now parse the relocation information */
>>> rel_size = rel_size / sizeof(ElfW(Rel));
>>> rpnt = (ELF_RELOC *) rel_addr;
>>> @@ -187,6 +187,8 @@ int _dl_parse_relocation_information(struct dyn_elf
>>> *xpnt,
>>> #endif
>>>
>>> if (reloc_type == R_MIPS_JUMP_SLOT || reloc_type ==
>>> R_MIPS_COPY) {
>>> + sym_ref.tpnt = NULL;
>>> + sym_ref.sym = &symtab[symtab_index];
>>> symbol_addr = (unsigned long)_dl_find_hash(symname,
>>> scope,
>>> tpnt,
>>
>> Khem,
>> not sure, but this could be a problem. Unfortunately the code that
>> handle relocations for mips is enough different from all other
>> architectures.
>> The symbol scope redesign was mixed with another big change to handle
>> protected symbols, so the risk of breakage on some archs were high.
>>
>> Please let me know if it helps.
>>
>> Thanks,
>> 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
