Re: restoring spec docs
i've started a page: http://uclibc.org/specs.html and pushed out the files: http://uclibc.org/docs/ hopefully people find these useful :) -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libdl: rudimentary locking for dlopen/dlsym/dlclose
On Fri, 4 May 2012 12:52:12 -0400 Mike Frysinger wrote: > On Friday 04 May 2012 06:10:02 HeinBali wrote: > > > This implements big-dlfcn lock to allow multithreaded usage of > > > dlopen/dlsym/dlclose. We should really clean up the dl code so > > > we can use more fine grained locking or even RCU where > > > appropriate. > > > > Maybe it would be a good idea to check within libdl.c : > > > > #ifndef PTHREADS_NATIVE > > #error ... > > #endif > > > > I just spent a long time wondering why all of the ALSA utilities > > crashed right after start-up: Buildroot had selected the standard > > Linux thread type (PTHREADS_OLD) > > the locking code is pthread-implementation independent. there's no > reason i can see that this would require NPTL. > -mike Sounds like linking order issue, or the fact that the dlopen() loads a library requring libpthreads (but the main binary does not). Try linking explicitly the main app against libpthreads. This is still an issue with PTHREADS_OLD, but I fixed it earlier for NPTL. -Timo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: restoring spec docs
On Sat, May 5, 2012 at 9:50 AM, Mike Frysinger wrote: > i've started a page: > http://uclibc.org/specs.html > and pushed out the files: > http://uclibc.org/docs/ > > hopefully people find these useful :) Thanks for providing these docs! Unfortunately, many OSS project lacks of up2date ones. Are in uClibc sources tags (like in Linux-kernel sources) foreseen to create docs on request? - Sedat (dileks on IRC) - > -mike > > ___ > 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
ldd.host bug (32 vs. 64 bit)
Hi all. Almost 2 years passed by when I sent the below mail to this list. Unfortunately no one has responded. But ldd is still broken when cross-compiling for a different architecture (32 vs. 64 bit). As a workaround we use "-m32" in the Freetz Project to build the utils [1]. Unfortunately I don't have the knowledge to fix this. So help is appreciated. Regards Oliver [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/uclibc.mk#L152 -- Hi, I'm building a mipsel uclibc (0.9.31) toolchain (32-bit) on 64-bit Ubuntu. When trying to analyze a mipsel binary with ldd.host it fails with: "...not an ELF file." This is caused by the following test in http://git.uclibc.org/uClibc/tree/utils/ldd.c#n220: || ehdr->e_ident[EI_CLASS] != ELFCLASSM The first expression evaluates to ELFCLASS32 and the second one is defined as ELFCLASS64. Commenting out the check doesn't help because then it's throwing a segfault. Can anybody confirm this bug? Or even fix it? Should I open a ticket on bugzilla? Regards Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: restoring spec docs
On Saturday 05 May 2012 06:31:54 Sedat Dilek wrote: > Are in uClibc sources tags (like in Linux-kernel sources) foreseen to > create docs on request? i don't understand what you're asking -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: restoring spec docs
On Sat, May 5, 2012 at 8:39 PM, Mike Frysinger wrote: > On Saturday 05 May 2012 06:31:54 Sedat Dilek wrote: >> Are in uClibc sources tags (like in Linux-kernel sources) foreseen to >> create docs on request? > > i don't understand what you're asking > -mike By "tags" or "markers" - Sorry, don't know the English technical term - I mean something like in [0]. The goal should be something like in [1]. AFAICS the kernel-doc is created out of the source-tree and further converting into other formats like HTML etc.. Is that now a bit clearer? - Sedat - [0] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=net/mac80211/ieee80211_i.h;hb=HEAD#l202 [1] http://packages.debian.org/sid/all/linux-doc-3.2/filelist ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] Remove support for systems lacking vfork
i've added real details to the commit message and pushed. thanks! -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: restoring spec docs
On Saturday 05 May 2012 15:01:30 Sedat Dilek wrote: > On Sat, May 5, 2012 at 8:39 PM, Mike Frysinger wrote: > > On Saturday 05 May 2012 06:31:54 Sedat Dilek wrote: > >> Are in uClibc sources tags (like in Linux-kernel sources) foreseen to > >> create docs on request? > > > > i don't understand what you're asking > > -mike > > By "tags" or "markers" - Sorry, don't know the English technical term > - I mean something like in [0]. > > The goal should be something like in [1]. > AFAICS the kernel-doc is created out of the source-tree and further > converting into other formats like HTML etc.. i'm not sure that's going to happen, and if it did, if it'd be useful. the kernel doc case is different because all the APIs they develop are unique to the kernel. with uClibc, i don't think there's any functions specific to us. we implement standards (like POSIX) or functions that other import C libraries (i.e. glibc) implement. in either case, there is documentation for those already readily available on the internet. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
