Hi Natanael,
On Wed, Aug 29, 2012 at 09:18:57AM +, Natanael Copa wrote:
> I previously sent a bug report for pread/pwrite with a link to a
> patch that i hacked up quick and dirty. This showed up to be severly
> broken on x86_64 and corrupted several qemu disks images for me.
>
> I see that t
On Tue, Mar 27, 2012 at 05:12:49PM +0200, Johannes Stezenbach wrote:
> On Mon, Mar 26, 2012 at 02:11:41PM +0200, Bernhard Reutner-Fischer wrote:
> > On Tue, Feb 21, 2012 at 12:34:06PM +0100, Johannes Stezenbach wrote:
> > >On Mon, Feb 20, 2012 at 11:00:44PM +0100, Johanne
On Mon, Mar 26, 2012 at 02:11:41PM +0200, Bernhard Reutner-Fischer wrote:
> On Tue, Feb 21, 2012 at 12:34:06PM +0100, Johannes Stezenbach wrote:
> >On Mon, Feb 20, 2012 at 11:00:44PM +0100, Johannes Stezenbach wrote:
> >> On Tue, Feb 21, 2012 at 12:11:37AM +0800, Tony Wu wrote:
On Tue, Mar 13, 2012 at 10:58:33AM -0400, Rich Felker wrote:
> On Tue, Mar 13, 2012 at 10:30:10AM +0100, Laurent Bercot wrote:
>
> > Why not simply let the user set SA_RESTART in the sigaction() call?
> > see http://www.skarnet.org/software/skalibs/libstddjb/safewrappers.html
>
> I know of no mo
On Mon, Feb 20, 2012 at 11:00:44PM +0100, Johannes Stezenbach wrote:
> On Tue, Feb 21, 2012 at 12:11:37AM +0800, Tony Wu wrote:
> >
> > The sigaction, sigprocmask, and sigfillset static link issue has
> > already been addressed in the future branch back in Apr. 2011, but the
On Tue, Feb 21, 2012 at 12:11:37AM +0800, Tony Wu wrote:
>
> The sigaction, sigprocmask, and sigfillset static link issue has
> already been addressed in the future branch back in Apr. 2011, but the
> future branch is not merged yet.
>
> Until then, you can try to cherry-pick the following patche
Hi,
while my simple test cases all worked a more complicated application
fails to link. I distilled this small test case:
#include
#include
#include
int main()
{
sigset_t set;
jmp_buf env;
sigemptyset(&set);
sigprocmask(SIG_BLOCK, &set, NULL);
setjmp(e
On Sun, Jan 29, 2012 at 07:55:10PM +0100, Johannes Stezenbach wrote:
> On Sat, Jan 28, 2012 at 10:35:43PM +0100, Bernhard Reutner-Fischer wrote:
> > >
> > Can you try attached two patches please?
>
> I built a new toolchain with these patches applied on
> top of current
On Sat, Jan 28, 2012 at 10:35:43PM +0100, Bernhard Reutner-Fischer wrote:
> >
> Can you try attached two patches please?
I built a new toolchain with these patches applied on
top of current git (219aa9c), and built a statically
linked iperf with it. That worked fine.
I'll let you know tomorrow if
On Fri, Jan 27, 2012 at 02:17:25PM +0100, Carmelo AMOROSO wrote:
> Well,
> what I'd expect to have for sigaction is:
>
> libc.{so,a}
> ---> __libc_sigaction (global)
> ---> sigaction (weak alias of __libc_sigaction)
> ---> __GI_sigaction (hidden alias for internal use, if any)
>
> and
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
> On 16/12/2011 18.36, Johannes Stezenbach wrote:
> > On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
> >> On 16/12/11 15:57, Johannes Stezenbach wrote:
> >>> I was a
On Thu, Jan 19, 2012 at 10:20:12AM +0100, stl wrote:
> I am porting Linux for a new architecture, and I chose to build a
> cross compiler link against uClibc in order to build my linux system.
Do you mean architecture as in ARM, MIPS, etc. or just new board?
> I have ported uClibc-0.9.31 (I have
On Fri, Jan 13, 2012 at 03:00:08PM +0100, Johannes Stezenbach wrote:
> On Fri, Jan 13, 2012 at 12:58:45PM +0100, Carmelo AMOROSO wrote:
> > On 29/11/2011 17.05, Johannes Stezenbach wrote:
> > >
> > > static linking on ARM with NPTL causes duplicate symbol
> > &g
On Fri, Jan 13, 2012 at 12:58:45PM +0100, Carmelo AMOROSO wrote:
> On 29/11/2011 17.05, Johannes Stezenbach wrote:
> >
> > static linking on ARM with NPTL causes duplicate symbol
> > errors for __aeabi_unwind_cpp_pr0. I think it is
> > both gcc and uClibc issue.
Hi,
On Fri, Dec 16, 2011 at 06:36:35PM +0100, Johannes Stezenbach wrote:
> On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
> > On 16/12/11 15:57, Johannes Stezenbach wrote:
> > > I was able to fix the issue like this:
> > >
> > > --- uClibc-0.
On Mon, Dec 12, 2011 at 12:13:49PM +0100, Johannes Stezenbach wrote:
> On Thu, Dec 01, 2011 at 08:58:24AM +0100, Carmelo AMOROSO wrote:
> > On 01/12/2011 6.29, Khem Raj wrote:
> > > On (29/11/11 17:05), Johannes Stezenbach wrote:
> > >>
> > >> static
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
> On 16/12/11 15:57, Johannes Stezenbach wrote:
> > I was able to fix the issue like this:
> >
> > --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
> > 2011-12-03 18:55:45.0
On Tue, Nov 29, 2011 at 04:51:35PM +0100, Johannes Stezenbach wrote:
> On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
> > On Nov 28, 2011 6:43 PM, "Johannes Stezenbach" wrote:
> > >
> > > I'm in the process of building a tool
Hi Carmelo,
On Thu, Dec 01, 2011 at 08:58:24AM +0100, Carmelo AMOROSO wrote:
> On 01/12/2011 6.29, Khem Raj wrote:
> > On (29/11/11 17:05), Johannes Stezenbach wrote:
> >>
> >> static linking on ARM with NPTL causes duplicate symbol
> >> errors for __aeabi_unwi
Hi,
static linking on ARM with NPTL causes duplicate symbol
errors for __aeabi_unwind_cpp_pr0. I think it is
both gcc and uClibc issue.
See also
https://bugs.busybox.net/show_bug.cgi?id=4117
gcc version 4.6.2 20111004 (prerelease) (linaro version)
uClibc-0.9.32 or git master
- gcc defines __ae
On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
> On Nov 28, 2011 6:43 PM, "Johannes Stezenbach" wrote:
> >
> > I'm in the process of building a toolchain with crosstool-ng,
> > with uClibc-0.9.32 + NPTL for ARM926EJ-S.
> >
>
Hi,
I'm in the process of building a toolchain with crosstool-ng,
with uClibc-0.9.32 + NPTL for ARM926EJ-S.
Trying to statically link a simple testcase with NPTL fails:
$ cat t.c
#include
int main(int argc, char *argv[])
{
return (int)pthread_create;
}
$ arm-linux-gcc -Wall -Os t.c -lp
Hi,
I've built an ARM EABI toolchain with uClibc compiled as
Thumb code using buildroot (BR2_TARGET_OPTIMIZATION="-Os -mthumb").
This works fine except that in gdb (6.8), if you stop your program
with some threads blocked in syscalls, gdb is unable to display
a call stack for those threads.
The
23 matches
Mail list logo
