apache upgraded to 2.4
i've finished upgrading apache to 2.4. all the active sites seem to still be working correctly. if you see anything wrong, please let me know asap via this thread, or file a bug if bugzilla is working :). https://bugs.busybox.net/ enabling http/2 is causing a weird crash i need to investigate more, so it's disabled for now. -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: apache upgraded to 2.4
On 01 Feb 2016 22:00, Mike Frysinger wrote: > enabling http/2 is causing a weird crash i need to investigate more, > so it's disabled for now. i've updated some of the build and config options, and http/2 seems to be running fine on all the domains. -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
bugzilla upgraded to 5.0
i've deployed the new bugzilla 5.0 to bugs.busybox.net. feel free to let me know of any issues, or just file bugs :). -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Mailing list Website certificate expired?
On 23 Dec 2015 10:18, Steve Ellcey wrote: > Is anyone else having problems accessing the uclibc mailing list > archives on the web. I.e. seeing https://lists.uclibc.org/pipermail/uclibc/ > > I get a "This Connection is Untrusted" warning and when I go to this > page (Ubuntu 12.04, firefox 43.0) and if I click on the 'Technical Details' > I see: > > > > lists.uclibc.org uses an invalid security certificate. > > The certificate is only valid for *.osuosl.org > > (Error code: ssl_error_bad_cert_domain) that's not an expiration error, that's a domain mismatch error. https on the lists domains have always been this way (incorrect). we're in talks to get them fixed since the lists.xxx boxes aren't controlled by us. there's a thread on the uclibc-admins@ list, but i don't think that list is archived. -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
official elf2flt homepage/repo updated
with the demise of the cvs repo, we've moved officially to github: https://github.com/uclinux-dev/elf2flt this is based on the git mirror i had been previously maintaining here: git://wh0rd.org/elf2flt.git https://github.com/vapier/elf2flt so if you happened to have a copy of that, you should be set to switch over to the new location. support will continue to use the uclinux-...@uclinux.org mailing list. but if people have changes they wish to merge, feel free to send pull requests to the new location. it even has travis build testing and a simple (for now) testsuite. i've cross-posted to a few lists which are all in bcc to try and keep the resulting thread on uclinux-dev. let's see how that goes ;). -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[psa] shutting down svn web services
i'm not sure how many people care since it seems to have been broken for a while, but i'm officially turning off svn access via the webserver, as well as the viewvcs instance. i'm leaving open the raw rsync and svn access as both are trivial to maintain and rely on other services we want to keep. -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[psa] various server software upgrades
the uclibc.org software has been languishing for quite a long time, so i gave it a strong kick today. just about every piece of software has been upgraded on the box including bugzilla. my various testing looks like it still works, but if you guys notice anything weird, feel free to let me know. -mike signature.asc Description: Digital signature ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] linux: posix_fadvise: restore implementation for xtensa
On Thursday 02 January 2014 05:16:14 Baruch Siach wrote: Commit ee84b8b400 (linux: posix_fadvise: use new SYSCALL_ALIGN_64BIT) removed posix_fadvise implementation for xtensa, since xtensa does not define __NR_fadvise64. Redefine __NR_fadvise64 as __NR_fadvise64_64 to restore posix_fadvise. --- a/libc/sysdeps/linux/common/posix_fadvise.c +++ b/libc/sysdeps/linux/common/posix_fadvise.c @@ -10,6 +10,10 @@ #include sys/syscall.h +#if !defined(__NR_fadvise64) defined(__NR_fadvise64_64) +#define __NR_fadvise64 __NR_fadvise64_64 +#endif + #ifdef __NR_fadvise64 # include fcntl.h # include endian.h NAK: fairly certain this doesn't actually work. the 64_64 version expects a 64bit argument (for 32bit arches like xtensa, that means 2 32bits), but this file only passes up on 32bit. -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] linux: posix_fadvise: restore implementation for xtensa
On Thursday 02 January 2014 05:16:14 Baruch Siach wrote:
Commit ee84b8b400 (linux: posix_fadvise: use new SYSCALL_ALIGN_64BIT)
removed posix_fadvise implementation for xtensa, since xtensa does not
define __NR_fadvise64. Redefine __NR_fadvise64 as __NR_fadvise64_64 to
restore posix_fadvise.
try this instead (i haven't compiled it, so might have errors :P)
-mike
diff --git a/libc/sysdeps/linux/common/posix_fadvise.c
b/libc/sysdeps/linux/common/posix_fadvise.c
index e102ce7..c84c387 100644
--- a/libc/sysdeps/linux/common/posix_fadvise.c
+++ b/libc/sysdeps/linux/common/posix_fadvise.c
@@ -10,18 +10,25 @@
#include sys/syscall.h
-#if defined(__NR_fadvise64) || defined(__NR_arm_fadvise64_64)
+#ifdef __NR_arm_fadvise64_64
+/* We handle the 64bit alignment issue which is why the arm guys renamed their
+ * syscall in the first place. So rename it back.
+ */
+# define __NR_fadvise64_64 __NR_arm_fadvise64_64
+#endif
+
+#if defined(__NR_fadvise64) || defined(__NR_fadvise64_64)
# include fcntl.h
# include endian.h
# include bits/wordsize.h
-# ifdef __NR_arm_fadvise64_64
+# ifdef __NR_fadvise64_64
int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
# endif
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
-# ifdef __NR_arm_fadvise64_64
+# ifdef __NR_fadvise64_64
return posix_fadvise64(fd, offset, len, advice);
# else
int ret;
@@ -41,7 +48,7 @@ int posix_fadvise(int fd, off_t offset, off_t len, int advice)
return 0;
# endif
}
-# if defined __UCLIBC_HAS_LFS__ ((!defined __NR_fadvise64_64 !defined
__NR_arm_fadvise64_64) ||
__WORDSIZE == 64)
+# if defined __UCLIBC_HAS_LFS__ ((!defined __NR_fadvise64_64 !defined
__NR_fadvise64_64) ||
__WORDSIZE == 64)
strong_alias(posix_fadvise,posix_fadvise64)
# endif
#endif
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-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
On Tuesday 15 October 2013 16:37:32 Peter Korsgaard wrote: Mike your e-mail client still sucks btw Sorry, in what way? the quoting style unreasonably mangles things -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: non-interactive build question
On Monday 14 October 2013 12:43:34 Steve Ellcey wrote: I am new to building uclibc, but have experience building glibc and newlib, and I have a question about the best way to build multiple versions of uclibc from a script without any user interaction. you have experience building the kernel though right ? uClibc largely behaves the same as that. Currently, I run 'make defconfig' to create a default .config file and then use grep to modify the .config file before each build (strip out some lines and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or I may pick a different MIPS ABI. But what I noticed is that when I run the normal 'make' command after modifying .config is that my .config changes are getting wiped out and .config is getting restored to a default state. try `make oldconfig` first (assuming you pass ARCH=/etc... on the command line) Can someone explain why this is happening and if there is a way to prevent it? Is there a better way to do multiple uclibc builds with different defaults and without requiring any user interaction? usually the simplest thing is to create the .config files by hand as you care about them, and then use those when building alternatively, we could update our kconfig snapshot to the latest kernel which would get use miniconfig support -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: Building uclibc for big-endian and little-endian target.
On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. -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: Building uclibc for big-endian and little-endian target.
On Wednesday 16 October 2013 04:23:17 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. that patch is exactly the sort of thing we are not adding more support for -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: Building uclibc for big-endian and little-endian target.
On Wednesday 16 October 2013 12:13:12 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 5:23 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 16 October 2013 04:23:17 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. that patch is exactly the sort of thing we are not adding more support for what had you in mind, how would you realize it? as Khem said, if you want to target a specific cpu (-march/-mtune/etc...), then update UCLIBC_EXTRA_CFLAGS accordingly. there's really no difference between a Kconfig option with hardcoded cpu name and the user adding the same name to the cflags. except the kconfig list is a constantly losing route. -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-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
On Friday 04 October 2013 17:45:20 Peter Korsgaard wrote: Peter == Peter Korsgaard pe...@korsgaard.com writes: Peter Some archs (avr32 in particular) still doesn't define __NR_pread64, so Peter we should fall back to __NR_pread if it isn't available. Peter The code nicely checks for it, but then ends up hard coding the syscall Peter to use __NR_pread64 afterwards, rendering the check useless. Fix it by Peter using the result of the test instead. I noticed another critical issue on ARM EABI. The use of __LONG_LONG_PAIR for the offset doesn't take alignment requirement of 64bit parameters on EABI into consideration, so the offset is off by one register :/ https://lkml.org/lkml/2006/1/12/175 How should that be handled? i introduced __UCLIBC_SYSCALL_ALIGN_64BIT__ to handle this case. and the pread/pwrite logic takes that into account. do you have information to indicate it isn't working ? your e-mail client still sucks btw -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-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
On Friday 04 October 2013 15:41:20 Peter Korsgaard wrote: Some archs (avr32 in particular) still doesn't define __NR_pread64, so we should fall back to __NR_pread if it isn't available. The code nicely checks for it, but then ends up hard coding the syscall to use __NR_pread64 afterwards, rendering the check useless. Fix it by using the result of the test instead. i think you should look at all the pread/pwrite changes in master. afaik, all issues are addressed there. -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-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
On Tuesday 15 October 2013 19:04:12 Khem Raj wrote: On Oct 15, 2013, at 1:41 PM, Peter Korsgaard pe...@korsgaard.com wrote: Mike == Mike Frysinger vap...@gentoo.org writes: Hi, The code nicely checks for it, but then ends up hard coding the syscall to use __NR_pread64 afterwards, rendering the check useless. Fix it by using the result of the test instead. Mike i think you should look at all the pread/pwrite changes in Mike master. afaik, all issues are addressed there. Yes, possible. I'm trying to test the 0.9.33 branch to hopefully speed up the 0.9.33.3 release as there's quite some fixes pending, but it looks like some more stuff should get backported. Anybody else testing the branch? I would be interested if you try out latest master. if master works, then we can cherry pick back the patches. but i'd like to know before we start that work :). -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 V2] libc: deal with aux vect inside __uClibc_main only if !SHARED
On Friday 14 December 2012 05:40:05 Filippo ARCIDIACONO wrote: --- a/libc/misc/elf/dl-support.c +++ b/libc/misc/elf/dl-support.c @@ -28,6 +28,7 @@ void (*_dl_init_static_tls) (struct link_map *) = _dl_nothread_init_static_tls; ElfW(Phdr) *_dl_phdr; size_t _dl_phnum; +size_t _dl_pagesize; void internal_function _dl_aux_init (ElfW(auxv_t) *av); void internal_function _dl_aux_init (ElfW(auxv_t) *av) @@ -37,6 +38,9 @@ void internal_function _dl_aux_init (ElfW(auxv_t) *av) /* Get the number of program headers from the aux vect */ _dl_phnum = (size_t) av[AT_PHNUM].a_un.a_val; + + /* Get the pagesize from the aux vect */ + _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; you cannot use PAGE_SIZE. pretty much every arch has long ago removed that from their kernel headers exported to userspace. and indeed, this breaks building for at least x86: libc/misc/elf/dl-support.c: In function '_dl_aux_init': libc/misc/elf/dl-support.c:43:68: error: 'PAGE_SIZE' undeclared (first use in this function) _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; ^ libc/misc/elf/dl-support.c:43:68: note: each undeclared identifier is reported only once for each function it appears in make: *** [libc/misc/elf/dl-support.os] Error 1 -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] eventfd.h: Use new bits/ scheme for arch-specific flags
On Thursday 18 April 2013 04:51:20 Hiroaki KAWAI wrote: As in timerfd.h, eventfd.h needs arch-specific definition files. alpha, mips and sparc needs separate file, all the other arch will use common definition. your patch is horribly line wrapped. please use `git send-email` to avoid that rather than pasting the patch into an e-mail. -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: O_NOFOLLOW is not a gnu extension, it's posix-2008.
On Thursday 14 March 2013 01:07:43 Rich Felker wrote: On Fri, Mar 08, 2013 at 09:57:37PM -0600, Rob Landley wrote: Files like libc/sysdeps/linux/powerpc/bits/fcntl.h have blobs like: #ifdef __USE_GNU # define O_DIRECT 040 /* Direct disk access. */ # define O_DIRECTORY 04 /* Must be a directory. */ # define O_NOFOLLOW 010 /* Do not follow links. */ # define O_NOATIME 0100 /* Do not set atime. */ # define O_CLOEXEC 0200 /* Set close_on_exec. */ #endif Meaning that if you don't #define GNU_DAMMIT you don't get symbols Posix-2008 has been requiring for several years now: file:///home/landley/reading/SUSv4/basedefs/fcntl.h.html Which is why you don't need the #define to use O_NOFOLLOW in glibc. This is hard to work around because the value of the symbol varies per-target. I think the cleanest fix would be for uClibc to just define them unconditionally. O_* is in the reserved namespace for fcntl.h so there's no requirement in POSIX that extended O_* flags be hidden by default. there's really no need to do either. uClibc copies these headers from glibc and we simply need to refresh things. they've even unified the duplicated bits ala bits/fcntl-linux.h. innovation in this space gains us nothing. copying the headers verbatim from glibc saves a lot of time. -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: Un-hidden function relocs
On Sunday 25 November 2012 00:24:26 Mike Frysinger wrote: On Fri, Nov 23, 2012 at 10:08 PM, Michael Deutschmann wrote: __unix_grantpt that one is a bug i pushed a fix for this -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: Un-hidden function relocs
On Fri, Nov 23, 2012 at 10:08 PM, Michael Deutschmann wrote: __errno_location __h_errno_location probably related to linuxthreads usage. seems to be fixed in nptl, but should be tracked down in linuxthreads too. certainly shouldn't exist if you have threading disabled. __unix_grantpt that one is a bug _dl_app_init_array _dl_app_fini_array these are normal as the symbols exist in the ldso My version of uClibc is heavily patched from 0.9.33.2, but these functions don't relate to my changes. Although __unix_grantpt is probably wrong because I'm the only one exercising the old PTYs available and new PTYs never available code path. file bugs please It appears the reason malloc and friends are exceptions to the general rule is to support applications that want to wholly replace the malloc engine with a custom one. But that feature is not often used. firefox uses it. people use it to debug. It would be nice if there was a configuration option to not treat malloc specially and also to make brk() and sbrk() invisible. file bugs if you don't want to send patches -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 00/46] Support for cut-down Linux syscalls
On Wed, Nov 21, 2012 at 10:51 AM, Markos Chandras wrote:
On Sat, Nov 17, 2012 at 8:23 PM, Mike Frysinger wrote:
On Tuesday 13 November 2012 06:31:09 Markos Chandras wrote:
The following patches prefer the old system call if both syscalls are
present. For example, if __NR_open and __NR_openat are defined, then
open() will use the __NR_open syscall. If the __NR_open syscall is not
defined, then open() will use __NR_openat internally. This way we protect
existing architectures and preserve old behavior.
a semi-quick scan shows that you're missing hidden symbol aliases
for example, in your chmod change, you call fchmodat (which is fine), but
there's no addition of libc_hidden_{proto,def} for fchmodat.
to check for this, you can run `readelf -r` on the libc.so file and look at
all
the function relocs. the only ones in that list you should see are malloc
related (malloc/free/calloc/etc...). if you see other symbols, they're most
likely missing the libc_hidden stuff.
If I understand correctly, these macros don't need to be between
#ifndef chmod/#endif clauses right? I mean, calls to fchmodat within
libc should always bypass the plt so adding libc_hidden_{proto,def}
unconditionally seems to correct approach. I am a bit confused on why
these macros are not already used for these functions but I guess
because until now they were not called within libc.
yes, have the proto in the header file be in the same condition as
fchmodat itself (the line right after the prototype), and have the def
live in the fchmodat file itself
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: building uClibc for ARM MMU-less
On Wednesday 01 August 2012 11:29:54 Christophe Lyon wrote: My uClibc build currently fails at libpthread/nptl/sysdeps/generic/dl-tls.o: ./ldso/include/dl-elf.h: In function '__dl_parse_dynamic_info': ./ldso/include/dl-elf.h:173:20: error: 'RTLD_NODELETE' undeclared (first use in this function) RTLD_NODELETE is defined via dlfcn.h, which is included by link.h only if __HAVE_SHARED__ is defined. dl-elf.h includes links.h. should be fixed in the current git tree now (b4725d8e2cf04ffbead7721b5b43151245679262) -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: mips64 problems
On Wednesday 26 September 2012 10:54:10 Waldemar Brodkorb wrote: The problem is this line in Rules.mak: ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x sparc64 x86_64 ),) UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 else UCLIBC_LDSO_NAME := ld-uClibc ARCH_NATIVE_BIT := 32 endif TARGET_ARCH can not be set to mips64 via make menuconfig or any .config. How is it supposed to work? Would be the use of TARGET_SUBARCH a solution? no, it should be using the ABI field for mips and ignoring the arch entirely looking at gcc, i see it using these paths: o32: /lib/ld-uClibc.so.0 n32: /lib32/ld-uClibc.so.0 n64: /lib/ld64-uClibc.so.0 you could try this patch: --- a/Rules.mak +++ b/Rules.mak @@ -118,12 +118,17 @@ LIBC := libc SHARED_LIBNAME := $(LIBC).so.$(ABI_VERSION) UBACKTRACE_DSO := libubacktrace.so.$(ABI_VERSION) -ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x sparc64 x86_64 ),) + +UCLIBC_LDSO_NAME := ld-uClibc +ARCH_NATIVE_BIT := 32 +ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 powerpc64 s390x sparc64 x86_64 ),) UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 else -UCLIBC_LDSO_NAME := ld-uClibc -ARCH_NATIVE_BIT := 32 +ifeq ($(CONFIG_MIPS_N64_ABI),y) +UCLIBC_LDSO_NAME := ld64-uClibc +ARCH_NATIVE_BIT := 64 +endif endif UCLIBC_LDSO := $(UCLIBC_LDSO_NAME).so.$(ABI_VERSION) NONSHARED_LIBNAME := uclibc_nonshared.a -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 3/9] AVR32: declare missing result variable.
merged, 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: [PATCH 4/9] libpthread/nptl: do not exceed architecture specific stack default size
On Friday 21 September 2012 11:29:14 Florian Fainelli wrote: --- a/libpthread/nptl/init.c +++ b/libpthread/nptl/init.c @@ -401,6 +401,10 @@ __pthread_initialize_minimal_internal (void) Use the minimal size acceptable. */ limit.rlim_cur = PTHREAD_STACK_MIN; + /* Do not exceed architecture specific default */ + if (limit.rlim_cur ARCH_STACK_DEFAULT_SIZE) +limit.rlim_cur = ARCH_STACK_DEFAULT_SIZE; + /* Make sure it meets the minimum size that allocate_stack (allocatestack.c) will demand, which depends on the page size. */ const uintptr_t pagesz = sysconf (_SC_PAGESIZE); glibc doesn't do this, so i don't think we should either. if you can convince glibc to take it, obviously we will too. but this patch has no information as to why this is correct or desirable. -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 6/9] string: turn SUSv3 legacy macros into inline functions.
On Friday 21 September 2012 11:29:16 Florian Fainelli wrote: From: Felix Fietkau n...@openwrt.org Avoids crazy build breakages in multiple packages. like what ? i've never noticed a problem w/Gentoo, nor has anyone reported an issue ... -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: [gentoo-embedded] eventfd.patch for gentoo-embedded
On Thursday 25 October 2012 15:13:07 Piotr Gluszenia Slawinski wrote: http://comments.gmane.org/gmane.comp.lib.uclibc.general/22411 describes problem which surfaces up when glib is upgraded. glib depends on elfutils btw. but somehow compiles fine with just libelf . i guess this is another bug/problem to work-around (i've simply edited glib ebuild) ofc. glib 2.32 apps hang into loop like described in the mentioned post, applying patch to uclibc solves the problem. ok ? the fixes have already been merged and released in Gentoo. -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 00/46] Support for cut-down Linux syscalls
On Tuesday 13 November 2012 06:31:09 Markos Chandras wrote:
The following patches prefer the old system call if both syscalls are
present. For example, if __NR_open and __NR_openat are defined, then
open() will use the __NR_open syscall. If the __NR_open syscall is not
defined, then open() will use __NR_openat internally. This way we protect
existing architectures and preserve old behavior.
a semi-quick scan shows that you're missing hidden symbol aliases
for example, in your chmod change, you call fchmodat (which is fine), but
there's no addition of libc_hidden_{proto,def} for fchmodat.
to check for this, you can run `readelf -r` on the libc.so file and look at all
the function relocs. the only ones in that list you should see are malloc
related (malloc/free/calloc/etc...). if you see other symbols, they're most
likely missing the libc_hidden stuff.
-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 01/46] chmod: Use fchmodat if arch does not have the chmod syscall
On Tuesday 13 November 2012 06:31:10 Markos Chandras wrote: +int chmod(const char* path, mode_t mode) const char *path, not const char* path. seems to apply to many patches in this series. -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 01/46] chmod: Use fchmodat if arch does not have the chmod syscall
On Tuesday 13 November 2012 06:31:10 Markos Chandras wrote: +#if defined(__NR_fchmodat) ! defined(__NR_chmod) also, !defined rather than ! defined -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 15/46] dup3: Add dup3 syscall
On Tuesday 13 November 2012 06:31:24 Markos Chandras wrote: --- /dev/null +++ b/libc/sysdeps/linux/common/dup3.c ah, i already added dup3 +#if defined(__NR_dup3) i forgot this though ... just added -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 22/46] fork: Use clone if arch does not have the fork syscall
On Tuesday 13 November 2012 06:31:31 Markos Chandras wrote:
+pid_t __libc_fork(void)
+{
+ pid_t pid;
+ pid = INLINE_SYSCALL(clone, 4, SIGCHLD, NULL, NULL, NULL);
merge the definition assignment
+ if (pid0) {
if (pid 0) {
+ __set_errno(-pid);
+ return -1;
+ }
although, is this really necessary ? seems to me that INLINE_SYSCAL() already
takes care of setting errno correctly ...
return INLINE_SYSCALL(clone, 4, SIGCHLD, NULL, NULL, NULL);
+weak_alias(__libc_fork,fork)
space after the comma
-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 33/46] ustat: Return ENOSYS if ustat syscall is not defined
On Tuesday 13 November 2012 06:31:42 Markos Chandras wrote:
+#if ! defined(__NR_ustat)
+/*
+ * ustat syscall is deprecated and statfs or fstatfs should
+ * be used instead. There is no way to provide a wrapper for the
+ * newer syscalls, so just mark this syscall as unimplemented
+ */
+int ustat(dev_t dev, struct ustat* ubuf)
+{
+ __set_errno (ENOSYS);
+ return -1;
+}
NAK: use libc/sysdeps/linux/common/stubs.c
-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 38/46] llseek: Use the llseek system call if defined
On Tuesday 13 November 2012 06:31:47 Markos Chandras wrote:
-#if defined __NR__llseek defined __UCLIBC_HAS_LFS__
+#if (defined __NR__llseek ||defined __NR_llseek) defined
needs a space after that ||
loff_t lseek64(int fd, loff_t offset, int whence)
{
loff_t result;
+#if defined(__NR_llseek)
+ return (loff_t)(INLINE_SYSCALL(llseek, 5, fd, (off_t)(offset 32),
+ (off_t)(offset 0x), result, whence) ? : result);
+#else
return (loff_t)(INLINE_SYSCALL(_llseek, 5, fd, (off_t) (offset 32),
(off_t) (offset 0x), result, whence)
?: result);
+#endif
}
only difference is first arg ? so rather than this, put above the func:
# ifndef __NR__llseek
# define __NR__llseek __NR_llseek
# endif
-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 46/46] Config.in: Introduce symbol for arches without deprecated syscalls
On Tuesday 13 November 2012 06:31:55 Markos Chandras wrote: --- a/extra/Configs/Config.in.arch +++ b/extra/Configs/Config.in.arch +config ARCH_HAS_NO_DEPRECATED_SYSCALLS where is this actually used ? i didn't see it in the patches posted. also, let's avoid xxx_NO_xxx from now on. it makes reading logic a pita since it's an implicit ! in the middle. just change the default to y. -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 45/46] libc/ipc: Don't pass IPC_64 to arches that don't need it
On Thursday 15 November 2012 22:56:58 Rich Felker wrote: On Tue, Nov 13, 2012 at 11:31:54AM +, Markos Chandras wrote: --- a/extra/Configs/Config.in.arch +++ b/extra/Configs/Config.in.arch +config ARCH_HAS_NO_OLD_IPC + bool Disable support for the old IPC interface + default n + help + New architectures do not define the ARCH_WANT_IPC_PARSE_VERSION + in their kernel, which means they have no support for the old IPC + interface. For these architectures, these symbol must be defined + in order to have functional semctl, shmctl and msgctl system calls + Why is this a configure option? It's constant for a given arch... correct. this is what uClibc_arch_features.h is for. -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] string/microblaze: Fix for little-endian
On Friday 21 September 2012 01:38:41 Steve Bennett wrote: --- a/libc/string/microblaze/memcpy.S +++ b/libc/string/microblaze/memcpy.S +#ifdef __MICROBLAZEEL__ + #define BSLLI bsrli + #define BSRLI bslli +#else + #define BSLLI bslli + #define BSRLI bsrli +#endif for future reference, we do not indent preprocessor tokens #ifdef foo # define cow moo #else # define cow woof #endif -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: utils/getconf.c on MacOS X
On Thursday 20 September 2012 04:38:20 Waldemar Brodkorb wrote: What might be the best solution to resolve this? don't bother building it ? i can't see why it would be 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 45/46] libc/ipc: Don't pass IPC_64 to arches that don't need it
On Saturday 17 November 2012 15:44:23 Markos Chandras wrote: On Sat, Nov 17, 2012 at 8:41 PM, Mike Frysinger vap...@gentoo.org wrote: On Thursday 15 November 2012 22:56:58 Rich Felker wrote: On Tue, Nov 13, 2012 at 11:31:54AM +, Markos Chandras wrote: --- a/extra/Configs/Config.in.arch +++ b/extra/Configs/Config.in.arch +config ARCH_HAS_NO_OLD_IPC + bool Disable support for the old IPC interface + default n + help + New architectures do not define the ARCH_WANT_IPC_PARSE_VERSION + in their kernel, which means they have no support for the old IPC + interface. For these architectures, these symbol must be defined + in order to have functional semctl, shmctl and msgctl system calls + Why is this a configure option? It's constant for a given arch... correct. this is what uClibc_arch_features.h is for. Right but the logic in libc/misc/sysvipc/ipc.h should change because currently it does not check whether this macro is already defined. I will do that in the next revision that's fine, but the point is that these defines should live in that arch header rather than in Config.in since the ability to turn it on/off doesn't make sense. -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] include/elf.h: update for ELFOSABI_* changes.
On Friday 02 November 2012 14:34:43 Bernhard Reutner-Fischer wrote: On 31 October 2012 20:41:50 Thomas Schwinge tho...@codesourcery.com wrote: ELFOSABI_GNU replaces ELFOSABI_LINUX, the latter is kept as a compatibility alias, and ELFOSABI_HURD is removed. See the table on http://www.sco.com/developers/gabi/latest/ch4.eheader.html#osabi for reference. SCO? Do we take that serious? regardless of SCO, that is the canonical site for ELF specs and where it's been maintained and continues to be so Are you sure this is compatible with our license? just sync it from glibc ? -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] libc/sysdeps: add {get,make,set,swap}context for x86_64
On Wednesday 31 October 2012 09:25:16 Natanael Copa wrote: +ifeq ($(UCLIBC_SUSV4_LEGACY),y) i don't think these are even SUSV4 legacy. they're part of SUSV3 and marked obsolete there and then removed from SUSV4. +ASFLAGS-setcontext.S := -D_LIBC_REENTRANT +ASFLAGS-getcontext.S := -D_LIBC_REENTRANT +ASFLAGS-swapcontext.S := -D_LIBC_REENTRANT not specific to your change, but this doesn't seem right. we add it to like ASFLAGS with every .S file ? +ifeq ($(UCLIBC_HAS_THREADS_NATIVE),y) +#Needed to use the correct SYSCALL_ERROR_HANDLER +ASFLAGS-setcontext.S += -DUSE___THREAD +ASFLAGS-getcontext.S += -DUSE___THREAD +ASFLAGS-swapcontext.S += -DUSE___THREAD +endif this is specific to your change. i don't think this is correct. this define is setup by tls.h and shouldn't be manually added to specific files. -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: Implementing {get,set,make,swap}context routines for ARM
On Monday 20 August 2012 08:34:24 Natanael Copa wrote: On Sun, Aug 19, 2012 at 1:51 AM, Mike Frysinger wrote: On Tuesday 26 June 2012 05:29:29 Timon ter Braak wrote: I am trying to build a gccgo (go language) cross compiler targetting an ARM system. Go uses the context control routines for coorperative multithreading. uClibc however does not implement them, so I am trying to port the functions to uClibc. The routines are available in glibc and eglibc, and for other architectures [1]. My port builds correctly, but segfaults while running. I noticed that (for example) the getcontext routine is quite different from the setjmp routine shipped with uClibc. Can anybody give me some pointers in what should be altered? A patch of my attempt is attached. you'll need to make them depend on UCLIBC_SUSV3_LEGACY as these functions have been removed from the latest POSIX spec and shouldn't be enabled/built by default I'd like to have this too for mongrel2 but I would actually prefer to see this implemented as a standalone library, similar to argp-standalone. the difference between these and argp is the former is part of the standard (albeit, the last one which we still currently support) while the latter is purely a GNU extension. -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: Implementing {get,set,make,swap}context routines for ARM
On Tuesday 26 June 2012 05:29:29 Timon ter Braak wrote: I am trying to build a gccgo (go language) cross compiler targetting an ARM system. Go uses the context control routines for coorperative multithreading. uClibc however does not implement them, so I am trying to port the functions to uClibc. The routines are available in glibc and eglibc, and for other architectures [1]. My port builds correctly, but segfaults while running. I noticed that (for example) the getcontext routine is quite different from the setjmp routine shipped with uClibc. Can anybody give me some pointers in what should be altered? A patch of my attempt is attached. you'll need to make them depend on UCLIBC_SUSV3_LEGACY as these functions have been removed from the latest POSIX spec and shouldn't be enabled/built by default -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] mmap()-sys_mmap2: do unsigned shift of offset
On Friday 18 May 2012 22:09:46 Mike Frysinger wrote: On Thursday 17 May 2012 07:47:11 James Hogan wrote: Is it always correct to cast __off_t to __u_long? I'm a bit unclear whether it's still correct on 64bit architectures or with long file support. this isn't mmap64 (which uses __off64_t), so it's fine. you can see that everyone defines __off_t to __SLONGWORD_TYPE regardless of bitsize. if no one else has feedback, i'll merge this in a bit i ended up applying the other one you sent since this resend is slightly corrupted 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: [PATCH 1/2] Revert Makerules: respect HARDWIRED_ABSPATH in interp.c
On Friday 18 May 2012 23:54:39 Mike Frysinger wrote: On Thursday 17 May 2012 09:18:29 Sedat Dilek wrote: This reverts commit 5dffed7dd1a413f3965af702fa7ecd79809d1988. This breaks ldd when HARDWIRED_ABSPATH=n. [1] http://lists.uclibc.org/pipermail/uclibc/2011-March/045048.html [2] http://lists.uclibc.org/pipermail/uclibc/2011-March/045054.html looks like it slipped off my radar if there's no feedback in a few days, i'll merge these. thanks! pushed! -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] mmap()-sys_mmap2: do unsigned shift of offset
On Thursday 17 May 2012 07:47:11 James Hogan wrote: Is it always correct to cast __off_t to __u_long? I'm a bit unclear whether it's still correct on 64bit architectures or with long file support. this isn't mmap64 (which uses __off64_t), so it's fine. you can see that everyone defines __off_t to __SLONGWORD_TYPE regardless of bitsize. if no one else has feedback, i'll merge this in a bit -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: Incorrect/incomplete eventfd implementation?
On Wednesday 16 May 2012 14:23:32 Khem Raj wrote: On Wed, May 16, 2012 at 11:00 AM, Eugene Rudoy wrote: After taking a look at what glibc does, I would suggest the following (not yet tested) fix (s. attached patch) Looks ok. send with sign-offs and preferably a testcase now that you have and use `git send-email` instead of attaching it -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: Has anybody actually tested x86-64 with NPTL in 0.9.33.1?
On Tuesday 15 May 2012 13:16:12 Bernhard Reutner-Fischer wrote: On Mon, May 14, 2012 at 06:04:41PM -0500, Rob Landley wrote: make[1]: Leaving directory `/home/perl/dist/threads-shared' LD_LIBRARY_PATH=/home/perl ./perl -f -Ilib pod/buildtoc --build-toc -q ./perl: Can't resolve symbol '__pthread_mutex_lock' IIRC that one comes from f69319d5a7d3a3ccb46b28ee2b0fd9053c6415ac so you might just revert it or have a closer look in order to suggest a fix (i don't remember offhand if this behaves in 0.9.33.2). already fixed in the 0.9.33 branch: 927fb4f856bb9eb11090be33d9bee20261be13b2 -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: [git commit] help: Document CROSS=
On Wednesday 09 May 2012 12:29:57 Rich Felker wrote: Would it be possible to head in the direction of not neeting CROSS_COMPILE/CROSS? That is, make it so the build system just works with cross compiling as long as CC is set to the right compiler? I can think of a few potential issues like the way stripping is performed that might need a cross-specific tool other than CC the current system uses ar and nm and ld directly. the first two could be moved to partial linking so there's only ld and cc, but i don't know if you can do partial linking with gcc easily. obviously stripping would still need to be sep, but i think stripping isn't done by default, so that isn't a big deal. feel free to post a patch to move in that direction. but perhaps there's a way to use -dumpmachine and determine if the results are native or cross, and automatically search out the rigth tools based on that. err, no, this would be a bad fragile system -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: [git commit] help: Document CROSS=
On Tuesday 08 May 2012 13:53:55 Bernhard Reutner-Fischer wrote: --- a/Makefile.help +++ b/Makefile.help - @echo ' CROSS_COMPILE= - Override CROSS_COMPILER_PREFIX from .config' + @echo ' CROSS_COMPILE= - Override CROSS_COMPILER_PREFIX from .config' + @echo ' CROSS= - Same as CROSS_COMPILE' we dropped all mention of CROSS were possible on purpose. the only reason CROSS_COMPILE defaults to CROSS is because we didn't want to break peoples build scripts. if we're going to start adding info again, i say scrub it completely. -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
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: gentoo once again
On Thursday 03 May 2012 04:08:12 Piotr Gluszenia Slawinski wrote: On Wed, 2 May 2012, Mike Frysinger wrote: On Wednesday 02 May 2012 14:15:54 Piotr Gluszenia Slawinski wrote: On Fri, 27 Apr 2012, Peter Korsgaard wrote: Mike == Mike Frysinger vap...@gentoo.org writes: is there still any problem with udev? try it out and let us know ;) Mike i just emerged it on my system and rebooted and it came back, so Mike sounds good enough for me ;) We also have udev 182 in Buildroot, and that afaik works ok without any patches (I don't use it myself though). just tried to emerge udev with uclibc 0.28 and it fails - with 'O_CLOEXEC' undeclared. i plan on pushing 0.9.33 to stable asap and dropping everything older. there's too much rot here to support. ok, upgraded and busybox compiled. now i have problem with lack of libnsl - it seems resolv is disabled by default in gentoo's ebuild and there is no USE flag to enable it both libnsl and libresolv are useless stub libraries in 0.9.33. rebuild anything linked against them. the ebuild provides USE=uclibc-compat to temporarily enable them ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
restoring spec docs
after moving from svn to git, the docs/ subdir of trunk/ wasn't migrated anywhere. any suggestions on where to restore these ? i'm not sure we can exclude subdirs when using `git archive`, so we can't add them to the main repo. maybe start a new toplevel git repo and add it to uClibc.git as a submodule ? the files in question are important to us: crt.txt elf-64-gen.pdf elf.pdf psABI-arm.pdf psABI-i386.pdf psABI-ia64.pdf psABI-m8-16.pdf psABI-mips.pdf psABI-parisc.pdf psABI-ppc64.pdf psABI-ppc.pdf psABI-s390.pdf psABI-s390x.pdf psABI-sh.txt psABI-sparc.pdf psABI-x86_64.pdf SysV-ABI.pdf SysV-Interface-vol1a.pdf SysV-Interface-vol1b.pdf SysV-Interface-vol2.pdf tls.pdf tls-ppc64.txt tls-ppc.txt -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: gentoo once again
On Wednesday 02 May 2012 14:15:54 Piotr Gluszenia Slawinski wrote: On Fri, 27 Apr 2012, Peter Korsgaard wrote: Mike == Mike Frysinger vap...@gentoo.org writes: is there still any problem with udev? try it out and let us know ;) Mike i just emerged it on my system and rebooted and it came back, so Mike sounds good enough for me ;) We also have udev 182 in Buildroot, and that afaik works ok without any patches (I don't use it myself though). just tried to emerge udev with uclibc 0.28 and it fails - with 'O_CLOEXEC' undeclared. i plan on pushing 0.9.33 to stable asap and dropping everything older. there's too much rot here to support. -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] support kernels without __ARCH_WANT_SYSCALL_OFF_T
On Monday 30 April 2012 07:27:15 Laurent Bercot wrote: If your static app does not use stdio then it will not be linked into the binary. If it is linked in, then you must be using a broken toolchain, so what versions of uClibc and GCC do you use? Hi Bernhard and list, I was curious so I did the most simple test there is. Unfortunately, I'm not savvy enough with ELF and objdump to correctly interpret the results, so I'll leave it to you guys. ld's -M (map) option tells a better story in showing where things get pulled from. so instead, run: $ gcc -o true -static true.c -Wl,-M -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: [PATCHv3] librt: Add posix_spawn support
On Friday 27 April 2012 14:48:11 Bernhard Reutner-Fischer wrote: On 3 March 2012 05:24, Ismael Luceno ismael.luc...@gmail.com wrote: Signed-off-by: Ismael Luceno ismael.luc...@gmail.com --- extra/Configs/Config.in|7 + include/spawn.h| 266 librt/Makefile.in librt/spawn.c | 251 librt/spawn_faction_addclose.c | librt/spawn_faction_adddup2.c | 52 librt/spawn_faction_addopen.c | 55 librt/spawn_faction_init.c | 42 +++ librt/spawn_int.h | 26 And what was the rational to add this to librt instead of libc? it's advanced realtime funcs, and librt is the realtime library. although i guess glibc sticks them in libc which is what you're asking about. -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: [PATCHv3] librt: Add posix_spawn support
On Friday 27 April 2012 19:59:34 Rich Felker wrote: On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote: On Friday 27 April 2012 18:33:08 Rich Felker wrote: But nowadays it's just really annoying and harmful. With shared libraries, it adds bloat and load time to every program which wants to use clock_gettime for getting system time, which is every modern program. i'd side with the clock_* funcs being better in libc because they are getting used more and more as people transition away from gettimeofday() And they are NOT part of any optional realtime option in POSIX; they're a mandatory part of POSIX base. afaik, POSIX doesn't cover library layout in any way. there is nothing requiring us to stick all mandatory interfaces into -lc. after all, much of the math support falls into this category yet lives in -lm. Is anybody really opposed to just making librt.a empty, librt.so nonexistent, and putting all the functions in libc.a/libc.so where they belong? it would be really cool if we could split lesser used and standalone code into standalone shared libraries and libc.so was a simple linker script that pulled in all the other objects AS_NEEDED(...). but alas, that'd play havoc with ABI/SONAMEs. I don't understand how this is all that useful. If you have binaries on your system that use standard functionality X, you'll have to have it _somewhere_ anyway, and it might as well be in libc.so. If you're worried about rare functions being spread out across lots of pages that might also contain widely-used functions and increasing average paged-in memory usage, it would be possible to add section attributes to all the rare stuff to put it all in one contiguous part of libc.so that would only be paged-in when stuff is actually using it. not everyone have virtual memory :p. ignoring that, larger single libraries means more reloc processing at init, and more string space to search when resolving symbols. -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: [PATCHv3] librt: Add posix_spawn support
On Saturday 28 April 2012 00:26:02 Rich Felker wrote: On Fri, Apr 27, 2012 at 11:57:38PM -0400, Mike Frysinger wrote: On Friday 27 April 2012 19:59:34 Rich Felker wrote: On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote: On Friday 27 April 2012 18:33:08 Rich Felker wrote: But nowadays it's just really annoying and harmful. With shared libraries, it adds bloat and load time to every program which wants to use clock_gettime for getting system time, which is every modern program. i'd side with the clock_* funcs being better in libc because they are getting used more and more as people transition away from gettimeofday() And they are NOT part of any optional realtime option in POSIX; they're a mandatory part of POSIX base. afaik, POSIX doesn't cover library layout in any way. there is nothing requiring us to stick all mandatory interfaces into -lc. after all, much of the math support falls into this category yet lives in -lm. Actually, to some extent it does. See the documentation for the c99 command: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html POSIX allows certain -l options (which need not exist as a physical library file in the filesystem) to be required for using certain features; a conformant application (i.e. build script) must use them, but the implementation is not required to hide the symbols from you if you don't include them, and in fact it's perfectly conformant for them all to be ignored (i.e. everything available in the default library/libraries). thanks. that page pretty clearly explains why -lrt exists in the first place, and why glibc places all the symbols that it does in there. it would be really cool if we could split lesser used and standalone code into standalone shared libraries and libc.so was a simple linker script that pulled in all the other objects AS_NEEDED(...). but alas, that'd play havoc with ABI/SONAMEs. I don't understand how this is all that useful. If you have binaries on your system that use standard functionality X, you'll have to have it _somewhere_ anyway, and it might as well be in libc.so. If you're worried about rare functions being spread out across lots of pages that might also contain widely-used functions and increasing average paged-in memory usage, it would be possible to add section attributes to all the rare stuff to put it all in one contiguous part of libc.so that would only be paged-in when stuff is actually using it. not everyone have virtual memory :p. ignoring that, larger single libraries means more reloc processing at init, and more string space to search when resolving symbols. I would suspect on a system without virtual memory, you'd decide to completely omit certain functionality from uClibc at config/build time if you don't need it for any of your bins. If you do need it for some of your bins, overall memory usage will almost surely be lower by having it in a common .so file rather than having another .so loaded in memory. fragmentation is a much bigger problem than total memory usage, so having smaller bits split apart vs a single large blob is almost always more desirable. As for reloc processing, that's essentially zero if you use visibility (or -Bsymbolic-functions, the big stick) to bind as much as possible at .so creation time. there are more relocs than just bypasing the PLT (which uClibc does heavily via hidden_xxx()) String space is possibly an argument against including too much hashing should mitigate much of the look-up costs not sure. I'll grant that there may be *some* arguments against integrating it all into either libc.so or libpthread.so, but I think those arguments are looking pretty weak compared to the arguments FOR doing it. the only things that may be merged into libpthread are pthread funcs and stuff that absolutely requires them (for the obvious useless overhead in single threaded processes scenario). i'm guessing librt links against libpthread because of the async api. without kernel support, userspace threads are the only recourse for implementing that stuff. and at that point, i don't see any real advantage to merging the pthread-dependent funcs from -lrt into - lpthread. they're not widely used, and POSIX allows us to say you must use - lrt if you want them. clock_gettime can sometimes call __pthread_clock_gettime when HP timing support is enabled, but that can handle the normal libc-pthread-forwarding logic, so moving that to libc is fine. that leaves timer_* stuff which doesn't need pthread and is small (like, less than 1k), so throwing in libc is fine. -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: gentoo once again
On Thursday 26 April 2012 16:17:11 Piotr Gluszenia Slawinski wrote: few more issues, package.mask in uclibc profile settings is blocking udev above 141 - this is prohibiting new Xorg to build. is there still any problem with udev? try it out and let us know ;) also glib is set hard masked in profile even though uclibc can have locale now, but this is minor compared to udev.. that's a much bigger can-o-worms -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] fix getpgrp handling
On Thursday 26 April 2012 10:14:01 Mark Salter wrote: The test for generating generating a stub for getpgrp was wrong generating to the max! and would result in duplicate symbols when building without __NR_getpgrp, but with __NR_getpgid and __NR_getpid. A closer look at the getpgrp implementation using getpgid showed that getpid was being called to pass the current pid to getpgid. This isn't necessary because passing 0 to getpgid returns the pgid of the current process. This patch cleans up the getpgrp implementation and the stub test. very cool --- a/libc/sysdeps/linux/common/stubs.c +++ b/libc/sysdeps/linux/common/stubs.c @@ -150,7 +150,7 @@ make_stub(get_kernel_syms) make_stub(getpeername) #endif -#if !defined(__NR_getpgrp) (defined(__NR_getpgid) (defined(__NR_getpid) || defined(__NR_getxpid))) +#if !defined __NR_getpgrp ! defined __NR_getpgid whitespace is slightly off, but i just fixed that, as well as the changelog and merged it -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] support kernels without __ARCH_WANT_SYSCALL_DEPRECATED
On Thursday 26 April 2012 10:16:53 Mark Salter wrote:
--- a/libc/sysdeps/linux/common/getdents.c
+++ b/libc/sysdeps/linux/common/getdents.c
ssize_t __getdents (int fd, char *buf, size_t nbytes) attribute_hidden;
+#ifdef __NR_getdents
#define __NR___syscall_getdents __NR_getdents
static __always_inline _syscall3(int, __syscall_getdents, int, fd,
unsigned char *, kdirp, size_t, count)
+#endif
-#if defined __ASSUME_GETDENTS32_D_TYPE
+#if defined __NR_getdents defined __ASSUME_GETDENTS32_D_TYPE
ssize_t __getdents (int fd, char *buf, size_t nbytes)
{
if __NR_getdents isn't defined, then we shouldn't define
__ASSUME_GETDENTS32_D_TYPE
-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] fix test for vfork function
On Thursday 26 April 2012 23:08:36 Rich Felker wrote: On Thu, Apr 26, 2012 at 10:50:57PM -0400, Mike Frysinger wrote: This patch adds a test for __UCLIBC_VFORK_USES_CLONE__ feature definition which an architecture may define if vfork is implemented using clone. err, if your kernel arch doesn't have vfork, why is it defining __NR_vfork ? i.e. the uClibc logic should not require __UCLIBC_VFORK_USES_CLONE__. it can deduce that itself by saying if !vfork !fork clone. I don't think !fork belongs in the test. Implementing vfork with clone is better than implementing it as just a duplicate of fork. But I'm not sure how having macros for this can be useful at all since, whatever syscall is used to implement vfork, it has to be written in asm unless it's just a duplicate of fork. if we've got a C-callable clone(), i think we can implement a C vfork() on top of that. it'd be a tail call, so the semantics of parallel stack usage should be the same. i know ia64 implements vfork() with clone(), but it does it in asm, so that doesn't make my case :p. (Providing returns-twice semantics in the same memory space is not possible without asm, except perhaps on some oddball architectures where the return address is stored in a register i don't think storing the return address in a register is that odd. a CALL in the Blackfin ISA stores the return address in the RETS register (return from subroutine) and it's up to the callee to save it if need be (via manual stack push or the LINK insn). makes leaf functions faster since there's no touching of the stack at all (assuming the code can fit in the scratch registers). and the compiler chooses not to use the stack to store anything in the syscall wrapper function... i think that's the point of INLINE_SYSCALL() vs INTERNAL_SYSCALL(). the latter expands into inline asm that only does the syscall and doesn't touch the stack. and relying on that is very unsafe since the compiler's behavior could change.) pray you don't look at _fork_parent() in libc/unistd/daemon.c then :p -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] fix test for vfork function
On Friday 27 April 2012 01:07:42 Rich Felker wrote: On Fri, Apr 27, 2012 at 12:58:33AM -0400, Mike Frysinger wrote: On Thursday 26 April 2012 23:08:36 Rich Felker wrote: On Thu, Apr 26, 2012 at 10:50:57PM -0400, Mike Frysinger wrote: This patch adds a test for __UCLIBC_VFORK_USES_CLONE__ feature definition which an architecture may define if vfork is implemented using clone. err, if your kernel arch doesn't have vfork, why is it defining __NR_vfork ? i.e. the uClibc logic should not require __UCLIBC_VFORK_USES_CLONE__. it can deduce that itself by saying if !vfork !fork clone. I don't think !fork belongs in the test. Implementing vfork with clone is better than implementing it as just a duplicate of fork. But I'm not sure how having macros for this can be useful at all since, whatever syscall is used to implement vfork, it has to be written in asm unless it's just a duplicate of fork. if we've got a C-callable clone(), i think we can implement a C vfork() on top of that. it'd be a tail call, so the semantics of parallel stack usage should be the same. i know ia64 implements vfork() with clone(), but it does it in asm, so that doesn't make my case :p. The standard libc wrapper API for the clone syscall does not return twice. It calls a function (function pointer argument) in the new thread/process. This makes it useless for implementing vfork. err, yeah, i was thinking it only took flags theory it could be designed to return in the child as well if the called function returns, but I think the usual behavior is for it to call SYS_exit (exit thread) in that case.. probably could be done with a bit of care in C and writing a dedicated clone func, but i don't think this would really gain anything, and would be hard to write in a way that didn't just end up bloating. since every arch has implemented vfork() and clone() in assembly anyways, requiring someone who doesn't have a __NR_vfork isn't anything new. as mentioned, ia64 already does this, and looking a little closer, seems that mips does as well. -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] fix test for vfork function
On Thursday 26 April 2012 10:14:30 Mark Salter wrote: A few places in the code check for existence of vfork by testing if __NR_vfork is defined. Newer kernels don't have a vfork syscall in which case, the library implements the vfork function using __NR_clone. This patch adds a test for __UCLIBC_VFORK_USES_CLONE__ feature definition which an architecture may define if vfork is implemented using clone. all these fall backs are for linux-2.0. i'm not sure we care (pretty sure we don't) let alone still compile, so i'd say just drop the logic (i.e. assume vfork() exists). if anyone turns up who does care about linux-2.0, we'll make them do the footwork for not screwing over linux-3.0+ users ;). -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] support kernels without __ARCH_WANT_SYSCALL_NO_AT
On Thursday 26 April 2012 10:18:54 Mark Salter wrote:
--- a/ldso/include/dl-syscall.h
+++ b/ldso/include/dl-syscall.h
+#if defined(__NR_open)
#define __NR__dl_open __NR_open
static __always_inline _syscall3(int, _dl_open, const char *, fn, int,
flags, __kernel_mode_t, mode)
+#elif defined(__NR_openat)
+#define __NR__dl_openat __NR_openat
+static __always_inline _syscall4(int, _dl_openat, int, dirfd, const char
*, fn, + int, flags, __kernel_mode_t, mode)
+static __always_inline ssize_t
+_dl_open(const char *fn, int flags, __kernel_mode_t mode)
+{
+ return _dl_openat(AT_FDCWD, fn, flags, mode);
+}
INLINE_SYSCALL() here and elsewhere please. i'll wait for a respin to look at
the rest ;).
-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: mmap64: use INLINE_SYSCALL() helper fails for ppc
On Thursday 12 April 2012 19:43:44 Mike Frysinger wrote:
On Thursday 12 April 2012 19:38:08 Khem Raj wrote:
I am seeing build failure on ppc
| libc/libc_so.a(mmap64.os): In function `mmap64':
|
| /home/kraj/work/openembedded-core/build/tmp-uclibc/work/ppc603e-oe-linu
| x-
uclibc/uclibc-0.9.33+gitra7c4e889e9c36fc19198654ada229aaa11955ee6-
r6.0/git/libc/sysdeps/linux/common/mmap64.c:60:
undefined reference to `__illegally_sized_syscall_arg6'
| collect2: error: ld returned 1 exit status
It could be related to
Author: Mike Frysinger vap...@gentoo.org
Date: Wed Apr 11 16:05:08 2012 -0400
mmap64: use INLINE_SYSCALL() helper
i was assuming INLINE_SYSCALL() would implicitly cast down the sizes, but i
guess this is kind of better ... it forces you to add casts when you know
it's ok, but errors out when you missed something.
i'll commit a fix shortly (just to case it down to 32bits).
how about this ? not sure if there is a native type laying around to do what
i want ...
-mike
--- a/libc/sysdeps/linux/common/mmap64.c
+++ b/libc/sysdeps/linux/common/mmap64.c
@@ -50,6 +50,16 @@ __ptr_t mmap64(__ptr_t addr, size_t len, int prot, int
flags, int fd, __off64_t
__ptr_t mmap64(__ptr_t addr, size_t len, int prot, int flags, int fd,
__off64_t offset)
{
+ /*
+* Some arches check the size in INLINE_SYSCALL() and barf if it's
+* too big (i.e. a 64bit value getting truncated to 32bit).
+*/
+# if __WORDSIZE == 32
+ uint32_t sys_offset;
+# else
+ uint64_t sys_offset;
+# endif
+
if (offset ((1 MMAP2_PAGE_SHIFT) - 1)) {
__set_errno(EINVAL);
return MAP_FAILED;
@@ -61,8 +71,10 @@ __ptr_t mmap64(__ptr_t addr, size_t len, int prot, int
flags, int fd, __off64_t
* sign extend things and pass in the wrong value. So cast it to
* an unsigned 64-bit value before doing the shift.
*/
+ sys_offset = (uint64_t)offset MMAP2_PAGE_SHIFT;
+
return (__ptr_t) INLINE_SYSCALL(mmap2, 6, addr, len, prot, flags, fd,
- ((uint64_t)offset MMAP2_PAGE_SHIFT));
+ sys_offset);
}
# endif
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 2/2] Update C6X support
On Tuesday 24 April 2012 09:47:10 Mark Salter wrote: This patch updates the C6X support to work with latest uClibc code and uses reworked DSBT support to allow using kernel FDPIC loader. do static progs (and thus the crt code) need updating too to handle the new kernel behavior ? -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: [ANNOUNCE] uClibc-0.9.33.1 released
On Wednesday 11 April 2012 13:45:49 Bernhard Reutner-Fischer wrote: You can grab the current uClibc release from our download-page at http://uclibc.org/downloads/ specifically http://uclibc.org/downloads/uClibc-0.9.33.1.tar.xz looks like this tarball doesn't match the v0.9.33.1 tag. the tarball has EXTRAVERSION set to 2-git instead of 1 ... any idea what happened ? should we update `make dist` to force people to manually specify a rev like a git tag name ? make dist VER=v0.9.33.1 -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] spawn: Expose posix_spwanattr_* functions
On Friday 13 April 2012 11:46:33 Khem Raj wrote: Static inline wont work on packages like gnulib where it will generate its own spawn.h let's fix gnulib then. this seems like it'll add code bloat overall -- a single memory store vs a full func call. -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: Support for CLOCK_MONOTONIC_RAW
On Wednesday 11 April 2012 07:36:17 Richard Braun wrote: Is there a particular reason why CLOCK_MONOTONIC_RAW isn't defined in libc/sysdeps/linux/common/bits/time.h ? headers generally get synced with glibc when someone notices + posts a patch -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: [ANNOUNCE] uClibc-0.9.33.1 released
On Wednesday 11 April 2012 15:31:20 Bernhard Reutner-Fischer wrote: On Wed, Apr 11, 2012 at 09:19:47PM +0200, Piotr Gluszenia Slawinski wrote: On Wed, 11 Apr 2012, Bernhard Reutner-Fischer wrote: Hello all, The uClibc team is happy to announce the maintenance-release of uClibc-0.9.33.1. not sure if anyone responsible is on the list but... will there be release for gentoo? I hope gentoo folks will take care of this soonish, yep. Ed's been making ebuilds of late -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: gcc + uclibc
On Tuesday 10 April 2012 13:06:44 Alberich de megres wrote: After some testings, and check your script and link (thanks for both), i'm having a different problem: while building gcc step 2, and libgcc: libgcc/../gcc/libgcc2.c:29: /opt/x/usr/include/pthread.h:25:19: fatal error: sched.h: No such file or directory In pthread.h I can see the include line is this one: #include sched.h while headers are located at include/linux/sched.h shouldn't it be: #include linux/sched.h no. uClibc provides sched.h. you should see why it wasn't installed in the uClibc headers stage. -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 V2 8/8] MIPS: Fix more *_NONBLOCK definitions
On Sunday 08 April 2012 01:55:52 Kevin Cernekee wrote: On Sat, Apr 7, 2012 at 10:32 PM, Mike Frysinger vap...@gentoo.org wrote: On Saturday 07 April 2012 16:31:32 Kevin Cernekee wrote: The proposed change is to add #ifdef clauses for __mips__, similar to what was done for SFD_NONBLOCK in include/sys/signalfd.h . This fixes the two failing test cases. we don't want arch ifdefs in these common files, nor do we want to diverge from glibc. upstream glibc has finally gotten sane and converted to bits/inotify.h for handling arch-specific stuff. let's import those updates instead. Thanks for the quick review. The original non-ifdef submission is here: which predates the glibc sanity unfortunately. now that glibc is sane, we can import their work unmodified. -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 1/4] inotify_rm_watch: Change second argument to int
thanks ... merged all 4 -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 4/8] test/signal: Add tst-signalfd
merged, 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: [PATCH 6/8] test/inet: Add tst-sock-nonblock
merged, 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: [PATCH 7/8] test/misc: Add tst-inotify
merged, 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: [PATCH V5] ldso: fix fdpic support broken from prelink patch
On Friday 06 April 2012 05:18:35 Filippo ARCIDIACONO wrote: The fdpic support has been broken since the prelink support was added, because it didn't take into account DL_LOADADDR_TYPE could be a different type of ElfW(Addr). i fixed a typo in the mmu code and pushed it. 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: [PATCH 1/8] test: Ignore various test objects
thanks, merged -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 3/8] test/signal: Fix compile warning in tst-sigset
On Saturday 07 April 2012 16:31:27 Kevin Cernekee wrote: Move up the variable declaration, to fix this: tst-sigset.c: In function 'do_test': tst-sigset.c:28:3: warning: ISO C90 forbids mixed declarations and code the tests that we import from glibc i'd rather not modify we build the rest of the tree with -std=gnu99, so sounds like the test subdir needs that update too -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: [git commit] buildsys: remove duplicate rule around defconfigs
On Wednesday 04 April 2012 01:54:35 Bernhard Reutner-Fischer wrote: --- a/Makefile.in +++ b/Makefile.in @@ -458,10 +458,7 @@ allyesconfig: $(conf) allnoconfig: $(conf) $(Q)$ -n extra/Configs/Config.in -defconfig: $(conf) - $(Q)$ -D extra/Configs/defconfigs/$(ARCH)/$@ extra/Configs/Config.in - -%_defconfig: $(conf) +defconfig %_defconfig: $(conf) $(Q)$ -D extra/Configs/defconfigs/$(ARCH)/$@ extra/Configs/Config.in this was duplicated on purpose. it breaks otherwise, like it now does with make-3.82 in master: $ make Makefile.in:461: *** mixed implicit and normal rules. Stop. -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: gcc + uclibc
On Mon, Apr 2, 2012 at 04:13, Alberich de megres alberich...@gmail.com wrote: I'm trying to understand the toolchain creation, by building one. I want to learn how they work. http://embedded.gentoo.org/handbook/?part=1chap=2#doc_chap3 -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso: mark _start hidden
On Tuesday 27 March 2012 00:10:16 Mike Frysinger wrote: There's no need to export this symbol, so mark them all hidden. merged -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 V3] ldso: fix fdpic support broken from prelink patch
On Tuesday 27 March 2012 08:46:38 Filippo ARCIDIACONO wrote: The fdpic support has been broken since the prelink support was added, because it didn't take into account DL_LOADADDR_TYPE could be a different type of ElfW(Addr). this looks much better. two things though ... (1) this patch is horribly mangled. i had to manually hack it up just to apply. please send with git send-email. --- a/ldso/include/dl-defs.h +++ b/ldso/include/dl-defs.h +#define DL_GET_LIB_OFFSET _dl_library_offset (2) make it: #define DL_GET_LIB_OFFSET() _dl_library_offset -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] ldso: mark _start hidden
There's no need to export this symbol, so mark them all hidden. Signed-off-by: Mike Frysinger vap...@gentoo.org --- ldso/ldso/arm/dl-startup.h|1 + ldso/ldso/avr32/dl-startup.h |1 + ldso/ldso/bfin/dl-startup.h |2 ++ ldso/ldso/c6x/dl-startup.h|1 + ldso/ldso/cris/dl-startup.h |2 ++ ldso/ldso/i386/dl-startup.h |1 + ldso/ldso/m68k/dl-startup.h |1 + ldso/ldso/microblaze/dl-startup.h |1 + ldso/ldso/mips/dl-startup.h |1 + ldso/ldso/powerpc/dl-startup.h|1 + ldso/ldso/sh/dl-startup.h |1 + ldso/ldso/sh64/dl-startup.h |1 + ldso/ldso/sparc/dl-startup.h |1 + ldso/ldso/x86_64/dl-startup.h |1 + ldso/ldso/xtensa/dl-startup.h |1 + 15 files changed, 17 insertions(+), 0 deletions(-) diff --git a/ldso/ldso/arm/dl-startup.h b/ldso/ldso/arm/dl-startup.h index f7d6052..0723d29 100644 --- a/ldso/ldso/arm/dl-startup.h +++ b/ldso/ldso/arm/dl-startup.h @@ -14,6 +14,7 @@ __asm__( .text\n .globl _start\n .type _start,%function\n + .hidden _start\n _start:\n @ at start time, all the args are on the stack\n mov r0, sp\n diff --git a/ldso/ldso/avr32/dl-startup.h b/ldso/ldso/avr32/dl-startup.h index a7179e4..e491019 100644 --- a/ldso/ldso/avr32/dl-startup.h +++ b/ldso/ldso/avr32/dl-startup.h @@ -12,6 +12,7 @@ __asm__( .text\n .global _start\n .type _start,@function\n + .hidden _start\n _start:\n /* All arguments are on the stack initially */ mov r12, sp\n diff --git a/ldso/ldso/bfin/dl-startup.h b/ldso/ldso/bfin/dl-startup.h index 76ae150..cb39112 100644 --- a/ldso/ldso/bfin/dl-startup.h +++ b/ldso/ldso/bfin/dl-startup.h @@ -42,8 +42,10 @@ __asm__( .type __start,@function\n /* Build system expects a _start for the entry point; provide it as it's free to do so with aliases. */ + .hidden __start\n .set_start, __start\n .global _start\n + .hidden _start\n __start:\n call.Lcall\n .Lcall:\n diff --git a/ldso/ldso/c6x/dl-startup.h b/ldso/ldso/c6x/dl-startup.h index 6ad801f..70a8b89 100644 --- a/ldso/ldso/c6x/dl-startup.h +++ b/ldso/ldso/c6x/dl-startup.h @@ -42,6 +42,7 @@ _dl_start (unsigned placeholder, \ __asm__( .text\n .globl _start\n + .hidden _start\n _start:\n B .S2_dl_start\n STW .D2T2B14, *+B14[1]\n diff --git a/ldso/ldso/cris/dl-startup.h b/ldso/ldso/cris/dl-startup.h index 57f84ea..6658000 100644 --- a/ldso/ldso/cris/dl-startup.h +++ b/ldso/ldso/cris/dl-startup.h @@ -10,6 +10,7 @@ __asm__(\ .text\n\ .globl _start\n\ .type _start,@function\n \ + .hidden _start\n \ _start:\n\ move.d $sp,$r10\n \ lapc_dl_start,$r9\n\ @@ -28,6 +29,7 @@ __asm__(\ .text\n\ .globl _start\n\ .type _start,@function\n \ + .hidden _start\n \ _start:\n\ move.d $sp,$r10\n \ move.d $pc,$r9\n \ diff --git a/ldso/ldso/i386/dl-startup.h b/ldso/ldso/i386/dl-startup.h index 973ed72..125132c 100644 --- a/ldso/ldso/i386/dl-startup.h +++ b/ldso/ldso/i386/dl-startup.h @@ -7,6 +7,7 @@ __asm__ ( .text\n .globl _start\n .type _start,@function\n + .hidden _start\n _start:\n call _dl_start\n # Save the user entry point address in %edi.\n diff --git a/ldso/ldso/m68k/dl-startup.h b/ldso/ldso/m68k/dl-startup.h index 8755ecf..52a950c 100644 --- a/ldso/ldso/m68k/dl-startup.h +++ b/ldso/ldso/m68k/dl-startup.h @@ -19,6 +19,7 @@ __asm__ (\ .text\n\ .globl _start\n\ .type _start,@function\n\ + .hidden _start\n\ _start:\n\ move.l %sp, -(%sp)\n\ jbsr _dl_start\n\ diff --git a/ldso/ldso/microblaze/dl-startup.h b/ldso/ldso/microblaze/dl-startup.h index 44966d6..4c6de5f 100644 --- a/ldso/ldso/microblaze/dl-startup.h +++ b/ldso/ldso/microblaze/dl-startup.h @@ -20,6 +20,7 @@ __asm__ (\ .text\n\ .globl _start\n\ .type _start,@function\n\ + .hidden _start\n\ _start:\n\ addk r5,r0,r1\n\ addk r3,r0,r0\n\ diff --git a/ldso/ldso/mips/dl-startup.h b/ldso/ldso/mips/dl-startup.h index 31730d4..4d9918d 100644 --- a/ldso/ldso/mips/dl-startup.h +++ b/ldso/ldso/mips/dl-startup.h @@ -12,6 +12,7 @@ __asm__( .globl _start\n .ent_start\n .type _start,@function\n + .hidden _start\n _start:\n .set noreorder\n
Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option
On Sunday 25 March 2012 03:23:38 Khem Raj wrote: On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger vap...@gentoo.org 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 -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: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option
On Sunday 25 March 2012 17:52:51 Khem Raj wrote: On Sun, Mar 25, 2012 at 12:42 PM, Joakim Tjernlund wrote: Khem Raj raj.k...@gmail.com wrote on 2012/03/25 20:23:04: On Sun, Mar 25, 2012 at 10:30 AM, Joakim Tjernlund wrote: On Sun, Mar 25, 2012 at 12:58 AM, Mike Frysinger wrote: On Sunday 25 March 2012 03:23:38 Khem Raj wrote: On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger 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. it should be easy to add aliases via .set for both mips and blackfin (and prob h8300, although that doesn't have a ldso port) so _start == __start. i don't think there would be runtime penalties for this as long as the symbol has hidden visibility. -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: Invitation to connect on LinkedIn
On Thursday 22 March 2012 01:08:05 Rich Felker wrote: On Wed, Mar 21, 2012 at 09:16:15AM +0100, Carmelo AMOROSO wrote: On 21/03/2012 3.46, harshad poshtiwala wrote: LinkedIn I'd like to add you to my professional network on LinkedIn. Do not send this sort of message to this mailing list. I'm pretty sure this was not sent intentionally but by a malicious website that asks for your email password then harvests all your contacts and spams them... not necessarily. apparently the linkedin apps suck and aren't clear (probably on purpose) when syncing contacts that they might spam everyone imported. i've been contacted by a few people and they found out that it did that after the fact. at any rate, i've unsubscribed him from the list. -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: stpcpy is Posix-2008, not __USE_GNU.
On Friday 16 March 2012 07:06:47 Rob Landley wrote: The standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html uClibc's include/string.h: #ifdef __USE_GNU ... /* Copy SRC to DEST, returning the address of the terminating '\0' in DEST. */ # if 0 /* uClibc: disabled */ extern char *__stpcpy (char *__restrict __dest, __const char *__restrict __src) __THROW __nonnull ((1, 2)); # endif extern char *stpcpy (char *__restrict __dest, __const char *__restrict __src) __THROW __nonnull ((1, 2)); libc_hidden_proto(stpcpy) That #ifdef is a bug. s/bug/outdated/ -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] A microblaze-specific sys/user.h is needed
On Thursday 15 March 2012 20:45:32 Steve Bennett wrote: for (e.g.) strace, so use this version from glibc merged ... 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: [PATCHv5] librt: Add posix_spawn support
On Monday 05 March 2012 03:43:49 Ismael Luceno wrote: --- a/librt/Makefile.in +++ b/librt/Makefile.in + +librt_filter_SRC += $(if $(UCLIBC_HAS_ADVANCED_REALTIME),, + spawn.c \ + spawn_faction_addclose.c \ + spawn_faction_adddup2.c \ + spawn_faction_addopen.c \ + spawn_faction_init.c) this lacks a \ in the first line leading to: librt/Makefile.in:37: *** unterminated call to function `if': missing `)'. Stop. fixed that merged. cheers! -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] prevent retries on fclose/fflush after write errors
fixed the style pushed. thanks all! it's nice we have people versed in esoteric low level aspects nowadays. -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] prevent retries on fclose/fflush after write errors
On Monday 12 March 2012 01:27:08 Kevin Cernekee wrote:
+ if (errno != EINTR
+ errno != EAGAIN
+ /* do we have other soft errors? */
+ ) {
+ break;
stylewise, this break is missing a tab too :p
otherwise, this looks good to go, no one has any complaints with it, so should
be good to merge ...
-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] prevent retries on fclose/fflush after write errors
On Tuesday 13 March 2012 01:58:49 Rich Felker wrote:
On Tue, Mar 13, 2012 at 01:41:01AM -0400, Mike Frysinger wrote:
On Sunday 11 March 2012 11:12:19 Denys Vlasenko wrote:
--- a/libc/sysdeps/linux/common/bits/uClibc_stdio.h
+++ b/libc/sysdeps/linux/common/bits/uClibc_stdio.h
@@ -250,6 +250,7 @@ struct __STDIO_FILE_STRUCT {
unsigned char __ungot[2];
#endif /* __UCLIBC_HAS_WCHAR__ */
int __filedes;
+ int __errno_value;
#ifdef __STDIO_BUFFERS
unsigned char *__bufstart; /* pointer to buffer */
unsigned char *__bufend;/* pointer to 1 past end of buffer */
pretty sure this breaks ABI. i know we aren't completely strict on this,
but it's something we should avoid if possible.
How so? Application code should not be touching the internals of
FILE...
because the uClibc macros which implement the public API directly access the
structure contents. look at the getc macros and how it leverages the locking
members.
-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] prevent retries on fclose/fflush after write errors
On Tuesday 13 March 2012 15:32:01 Rich Felker wrote: On Tue, Mar 13, 2012 at 07:19:35PM +, u-uclibc-q...@aetey.se wrote: there's no correct/sane program that would be affected by this ABI change. Actually I suspect that stdio macros might use stuff (like __bufpos) which is located past the proposed new structure member, in which case existing binaries would become incompatible with a patched library: #endif /* __UCLIBC_HAS_WCHAR__ */ int __filedes; + int __errno_value; #ifdef __STDIO_BUFFERS unsigned char *__bufstart; /* pointer to buffer */ unsigned char *__bufend;/* pointer to 1 past end of buffer */ - unsigned char *__bufpos; Indeed, I missed this. It should definitely not be added near the beginning of the structure, only past elements that could be part of the macro ABI. that would help only if the uClibc code itself had versioned functions which handled the growing struct. if you're attempting to support code that allocated sizeof(FILE) memory (which is dumb), then location in the struct wouldn't matter. -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] prevent retries on fclose/fflush after write errors
On Tuesday 13 March 2012 16:56:13 u-uclibc-q...@aetey.se wrote: On Tue, Mar 13, 2012 at 04:24:33PM -0400, Mike Frysinger wrote: It should definitely not be added near the beginning of the structure, only past elements that could be part of the macro ABI. that would help only if the uClibc code itself had versioned functions which handled the growing struct. Curious, why wouldn't this work without versioned functions? if end user code encodes sizeof(FILE) anywhere, they're creating a memory region of a fixed number of bytes, so increasing the structure means that the app will give us a pointer to memory of X bytes, but the library requires it to be Y (where Y is greater than X) bytes, so the library will clobber memory the user did not intend. declare char buf[sizeof(FILE)]; FILE *x = buf; on the stack and uClibc will overwrite random stuff on the stack. FILE structures are expected to be allocated by the library your sub-thread here indicated that someone other than uClibc was allocating FILE structures (or i misread). that cannot work w/out symbol versioning. if uClibc is the only thing that allocates/uses these structures, then appending members should be fine. Of course this generally only works if the macros are not being changed. correct, any existing members which are exposed via macros as part of the public API would have to remain in place. if you're attempting to support code that allocated sizeof(FILE) memory (which is dumb), then location in the struct wouldn't matter. I don't think keeping the size of FILE constant is practically important, even though I mentioned this as an incompatibility. if by practically you mean we don't care about the end users who are relying on sizeof(FILE), then sure (i don't care about that use case). i was just being pedantic in my reply. -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: tar-1.26 not unpacking archives with symlinks?
On Tuesday 13 March 2012 17:40:38 Natanael Copa wrote: I have seen this too and it only happens when the symlink is extracted before the file it points to. To reproduce: touch myfile ln -s myfile mylink tar -cf testcase1.tar mylink myfile i vaguely recall seeing this before and the issue came down to tar not detecting the right features. might want to compare the config.log output between glibc and uclibc to see how they differ. -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: [PATCHv5] librt: Add posix_spawn support
i don't have a problem with this as long as it builds warning free ;). if no one else has feedback, or Rich wants to attempt to shrink, i'll merge it. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
