Re: asm/page.h: No such file or directory
On Sunday 04 November 2007, Haavard Skinnemoen wrote: On Sat, 3 Nov 2007 10:35:48 +0100 Carmelo Amoroso [EMAIL PROTECTED] wrote: arm-softfloat-linux-uclibc-strip -x -R .note -R .comment brk.o ioperm.c:47:22: error: asm/page.h: No such file or directory It seems you don't have kernel headers properly configured for your architecture, or worst no properly installed. Check firstly if include/asm is a symlink to include/asm-arch. Actually, asm/page.h is about to be removed on all architectures, and it's been empty for some time on several architectures (avr32, arm, ...) i made a preemptive strike in Gentoo a while ago and nuked page.h and friends so as to catch the bad packages earlier than most I think ioperm.c should be fixed so that it doesn't rely on PAGE_SIZE (which I assume is the reason why it needs asm/page.h in the first place.) it was fixed some time ago ... but the version in Gentoo does not contain the fix, so from time to time, people get bitten -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: sys_errlist obsolete but replaced by what?
On Thursday 08 November 2007, Hamish Moffatt wrote: The help text for the sys_errlist feature says that it is deprecated and may be removed in the future, but what is its replacement? i guess not everyone is fluent in this stuff so i added a note in the help text to refer them to strerror(3) as Ned said -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: unresolved symbols with locale support
Lane Brooks wrote: I found my problem. It was stale binaries did not get installed correctly. Lane Hi, please note that the current status of locale support is not fully completed. We at ST have a whole Linux distro build against uclibc with locale enabled comprising almost 500 packages (Xorg, glib2... see the whole list at ftp://ftp.stlinux.com/pub/stlinux/2.3/STLinux/sh4_uclibc). We are running some locale specific tests for 8bit locale and found some bugs into locale code we'll release hopefully to the community soon, but the support is generally working. Note that multi-byte locale support is only for UTF8 (we did not yet test it fully). uclibc doesn't provide gettext functions (if you need it, you can build the gettext libraries and link your apps against libintl a we actually did) Hope to be helpful. Cheers, Carmelo Lane Brooks wrote: I recently turned on locale support in my uclibc build, and after recompiling everything, I am getting the following unresolved symbols when trying to run commands like python: python: symbol '__ctype_b': can't resolve symbol in lib 'python' I am new to locale support and am unsure how to hunt this problem down. I see that __ctype_b_loc is now defined. So is the problem with python or uclibc? Things were working fine for me before turning on locale support, but it seems I need locale support to compile xorg/gtk. Thanks, Lane Brooks ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Patch for Maverick Crunch support
On Tuesday 27 November 2007, Brian Austin wrote: This patch adds MAVERICK CRUNCH FPU support for the Cirrus Logic EP93XX ARM9 Procs. i dont think it needs another special ifdef when it can be integrated into the existing arm mess ... ive done that in svn instead for future reference, please fix your mailer so it doesnt line wrap patches. or attach them so they dont get screwed. thanks! -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc Support for gettext funtionality??
On Wednesday 21 November 2007, Carmelo AMOROSO wrote: Vikas TM wrote: Hello all, Please help me to find answers for following questions 1. What version of uClibc supports gettext functionality? none If you want to add this support into uCLibc will be appreciated. Otherwise you may build gettext libraries against uClibc and then explicitly link against libintl your applications requiring gettext functions. 2. Can I use mixture of both GLIBC and UCLIBC libraries in same environment? If so, should I need to do any special configuration setting? yes, search the list, there is a my post where I suggested how to use --dynamic-linker option for this purpose. And I remember some other suggested a link to to an wrapper/tools aimed to do this, likely better ... but I forgot the details. i'll reply here rather than the one you refer to (as that one is from mid-2006 and i doubt many people here have that in their mail still) there's no need to fiddle with dynamic linker if you have a properly configured toolchain. merely configure your uClibc's PREFIX (RUNTIME and DEVEL) to something like /fooie/uClibc and leave the ldso in /lib/ where the toolchain expects it. uClibc's ldso will do the rest. i wouldnt attempt to get glibc to go anywhere else other than the standard /lib/ as glibc isnt exactly configurable. in terms of filenames, the only one that would actually clash on the filesystem is libpthread.so.0 ... otherwise, you could have glibc and uclibc both living in /lib/ ... but unless you really know what you're doing, this is probably a bad idea :P -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: termios2 support
On Tuesday 11 December 2007, Will Wagner wrote: I would like support for arbitrary baud rates with serial ports with through uclibc. I have looked at the uclibc code and there appear to be some support for this in kernel_termios.h but it is limited to alpha powerpc. It also does not seem to use the kernel ioctl's TCGETS2 TCSETS2 that are available with 2.6 not really. the fact that the speed members exist in the termios struct for some ports is irrelevant so long as the TCGET/TCSET ioctl's are being used. for all the termios having different structures/layouts, the kernel implements the tty layer the same for everyone. it's just the structure itself which has these stupid arch/ABI warts because it's exposed to userspace. Can anyone suggest the best way to extend x86 so that it has support for c_ispeed c_ospeed in the termios structure? I believe that with the 2.6 kernel all architectures ktermios struct contains c_ispeed c_ospeed and so it could be added generically. Is that correct? Looks like TCGETS2 TCSETS2 are supported on both x86 and arm, is that right? you dont need libc support to access the functionality now ... you can cheat by doing: #include asm/termios.h #include asm/ioctls.h ... struct termios2 t; ioctl(fd, TCGETS2, t); t.c_ospeed = t.c_ispeed = 543210; t.c_cflag = ~CBAUD; t.c_cflag |= BOTHER; ioctl(fd, TCSETS2, t); ... i hesitate to add support for termios2 to uClibc in case the glibc guys implement things in a different way. the last thing i want is that sort of ugly API incompatibility. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: readelf/ldconfig confused about ELF header
On Wednesday 31 October 2007, Hamish Moffatt wrote: I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. please use the buildroot mailing list in the future uclibc's readelf and ldconfig are giving confusing results reading the headers of compiled libraries. Programs run ok, but ldconfig decides that my target has mixed byte-order libraries and generates a wrong-endianness ld.so.conf. readelf says the right things for uClibc's own libraries: [ 5:00PM] [EMAIL PROTECTED]:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf you are running readelf from binutils, so that isnt really uClibc's concern ... dunno about the ldconfig thing you mention though -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Testing of memcmp(). Possible patch to tester.c
On Saturday 27 October 2007, Mats Erik Andersson wrote: the attached difference file addresses the problem of better detecting a malfunctioning memcmp() call. It concerns the file uClibc-0.9.29/test/string/tester.c we blatantly steal this test from glibc ... any enhancements ive made i pushed back upstream as appropriate. in the test suite. Where possible the old test cases were rebuilt to avoid the return values (from memcmp) +1 and -1, but still only positivity and negativity are tested for. This was done in order to better disclose problems with the optimized and architecture specific implementations. In addition, there are some new test cases gleaned from Dropbear, and which conduct tests with shifting alignment. Of course, not all of these twenty test cases are independent, but in more verbose forms they were instrumental when I debugged architecture specific assembly code for an embedded system (not yet incorporated into the code base of uClibc). going by your description, it sounds like this would be something the glibc guys would accept. can you please resend this entire e-mail to [EMAIL PROTECTED] ? i'll take care of merging it into uClibc's copy. It was also essential to use a flag -fno-builtin to detect the failures, both for the old test cases and these new ones. which should already be happening ... the string Makefile makes sure to add this flag Based I on this recent experience, I have begun developing a modified testing machinery that better would issue warnings for false positives. The effort to avoid return values +1 and -1 is an afterglow of this methodology. Since the present test suite is somewhat awkward to use in cross compiled settings, I might come back to that issue another time. the test framework should be converted to dejagnu ... ive spent a little time on this, but much more is needed -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Any documentation about how uClibc would like new architecture patches?
On Thursday 25 October 2007, Hans-Christian Egtvedt wrote: I am in the work of submitting the AVR32 architecture fork of uClibc, and would like to know if you have a preferd way of receiving the patches? My plan is to pull down the latest snapshot, do a merge in my local repository (for the record I use git), test and verify that it works as intended and then submit patches. I was planning on splitting the patches into ldso.patch, libc.patch and libpthread.patch. Or is a huge patch ok? The total size of the diff is 99316 bytes, 3582 lines. it's already been done, but all patches should be posted to the list. i guess a more developer guide page on the website is in order ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: readelf/ldconfig confused about ELF header
On Sat, Jan 05, 2008 at 04:14:59AM -0500, Mike Frysinger wrote: On Wednesday 31 October 2007, Hamish Moffatt wrote: I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. please use the buildroot mailing list in the future I thought it was an ldconfig bug, but it turned out to be a problem with one of the other packages in my buildroot configuration. Patch submitted and applied to the buildroot repository already. thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
mipsel memcpy gcc3.4.6
Hi! Can anyone help with this issue ? I've opened a bug in the busybox tracking system: http://busybox.net/bugs/view.php?id=1894 It there any way to compile uClibc for mipsel with gcc 3.4.6 ? Some notes: - uClibc uses platform-specific memcpy (libc/string/mips/memcpy.os) Is it possible to swith to the generic memcpy version ? - The bug in the AS (preprocessor), not in the GCC itself -- -=AV=- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Saturday 05 January 2008, Alexander Voropay wrote: Can anyone help with this issue ? I've opened a bug in the busybox tracking system: http://busybox.net/bugs/view.php?id=1894 i already told you it wasnt a bug in uClibc ... It there any way to compile uClibc for mipsel with gcc 3.4.6 ? remove the -std=gnu99 flag when building memcpy.S if you like - uClibc uses platform-specific memcpy (libc/string/mips/memcpy.os) Is it possible to swith to the generic memcpy version ? that's a configuration choice on your side ... review your uClibc configuration file - The bug in the AS (preprocessor), not in the GCC itself incorrect ... the bug is in the gcc preprocessor. it errors out before it even gets a chance to output assembly which gas would then process. notice how the error message is prefixed with gcc there and not gas. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] uclibc extern inline
On Friday 07 December 2007, Khem Raj wrote: Compiling with gcc 4.3 I get a lot of warning about inlining. with -std=c99 or -std=gnu99 GCC implements ISO C99 inline semantics unless -fgnu89-inline is used. the warnings are in gcc 4.2 as well. ive imported the extern inline defines from glibc into our cdefs.h and converted all of the pthreads code to use it. i think that covers everything without forcing -fgnu89-inline ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Fix dladdr return value when cannot find symbol
On Wednesday 12 December 2007, Carmelo AMOROSO wrote: while running more tests on this (indeed never used dladdr in the past), which tests ? our dl tests certainly dont have the coverage anywhere close to what i wish they did ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] c99 math func log2
On Wednesday 07 November 2007, Bernhard Fischer wrote: If we can subsummize some or individual funcs depending one a certain standard, then all is well (see bsd-compat in e.g. network or others). If they are non-standard but just serve as glibc-compat, then please state so both in configury as in help-text and resubmit accordingly. for math functions, the groupings currently are: - all functions required by C99 - POSIX/IEEE 1003.1b-1993 functions i imagine we should add standard options: - float wrappers (what we have now -- all float funcs just call double funcs) - float versions (actually import the float variations) the only other piece would be a way to provide a custom list of desired math functions ... shouldnt be terribly hard for libm actually seeing as how most files are 1 func per file ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: building a new (nios2) toolchain starting with uclibc
On Thursday 18 October 2007, Robert P. J. Day wrote: as an experiment, i want to create an updated version of a Nios II toolchain, and i thought i'd start with testing whether i could just compile the latest version of uclibc with the older toolchain, and take it from there. first, i already have a nios2 cross-compiler toolchain from here: http://nioswiki.jot.com/WikiHome/OperatingSystems/%C2%B5Clinux/BinaryToolch ain that toolchain is based on gcc-3.4.6 so, as a first exercise, i thought it would be educational to see if i could cross-compile the latest svn checkout of uclibc with it. there should be no problems with gcc-3.4.6 and any architecture on the uClibc side of things. there is someone on bugs.uclibc.org who has spent a lot of time getting nios2 things working in uClibc again. -rw-r--r-- 1 rpjday rpjday 5544 2006-05-07 09:57 elf2flt.ld ah elf2flt, how i stab thee ... this will require custom modifications to your binutils install step is this a sane way to start the process -- just to see where the older toolchain has problems building the current version of uclibc, and seeing if there's an obvious fix? thanks. i'm pretty sure svn trunk of uClibc actually has a decent nios2 status. it'd prob be faster to go the other way -- enable everything you expect and only turn off upon failure. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Sunday 06 January 2008, Mike Frysinger wrote: buflen += i; err, that should be -= of course ... but you get the gist of where i'm trying to take the changes ;) -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] c99 math func log2
On Wednesday 31 October 2007, Natanael Copa wrote: Here is a patch for the c99 math func log2(). If this gets applied I will look into the other c99 math funcs as well. is this function actually needed by something ? the current working policy has been to merge C99 functions really only on demand ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: need for getifaddrs in uclibc
On Thursday 08 November 2007, Jason Curl wrote: Then sysctl() is supposed to be the successor of ioctl(). UNP talks about using the routing sockets to get the information for each interface (sounds similar to netlink, but different enough). from what i've seen on lkml, they're trying pretty hard to kill sysctl() since it just doesnt scale the way they need to -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: need for getifaddrs in uclibc
On Saturday 10 November 2007, Khem Raj wrote: On Wed, Nov 07, 2007 at 05:45:23PM +0100, Natanael Copa wrote: Hi, Does anyone know a susv3/POSIX compliant way to list all ipv6 interfaces? I bet there are no. ioctl(SIOCGIFCONF) ignores ipv6 interfaces, I just tested. I suggest implementing a getifaddrs in uclibc, even if its not susv3/POSIX. here is one implementation based on glibc getifaddrs(). It should get compiled in when you have UCLIBC_USE_NETLINK enabled. the netlink detection/assumption stuff should probably be scrubbed in favor of the have netflink define. Let me know if this is OK? Natanael: get a chance to test this ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
