status of 0.9.30 release
Hi, Were there any plans for a 0.9.30 release before the NPTL merge? What is the status of the 0.9.30 release? Thanks! -nc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Auditing the menuconfig help entries.
On Wed, Aug 27, 2008 at 12:29 AM, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 26 August 2008 08:03:03 you wrote: On Sun, Aug 24, 2008 at 06:56:44PM -0500, Rob Landley wrote: Fiddling with menuconfig: DOPIC (Create only position independent code) Does not say why you would or wouldn't want to do this. (Does it generate position independent code and non-position independent code? Should the .a files also be PIC, or just the .so files? If you select this are you telling it _not_ to generate any .a files, so static linking isn't an option? Is there a downside to statically linking PIC code?) Building pic code into an .a doesn't make sense to me. Anyway. If you're lucky (and e.g. on i386), it's possible to get away without pic even for .so. Don't try that at home unless you know exactly what you're doing. PIC makes sense for .so files, but not for .a files. When you dynamically link, you use .so files. When you statically link, you use .a files. This is why this option confuses me, is it saying don't create .a files, we will never statically link? Is it saying create bloated .a files? Is this platform-specific for certain platforms? Historically the distinction has been that i386 can deal with non-PIC code in situations where other architectures can't. There are now other wrinkles such as PIE code (e.g. I may want a statically linked PIE executable) and I suspect the NOMMU architectures may need some special casing as well. A .a file is a ar archive, it may be used as a static linked library but it may also be linked into a shared library in which case it must be PIC. I'm not aware of any particular case where this would happen in uClibc, but it can happen. What is the benefit of creating _only_ position independent code? LINUXTHREADS_OLD: Ok, what does this currently mean? This selects the old libpthreads implementation from the dawn of time, but what's the alternative? The new NPTL stuff hasn't been merged yet, so this intermediate version is... what? OLD means the old version. !OLD is something newer. !UCLIBC_HAS_THREADS is what i do and the rest is a myth. OLD works now. In theory NPTL might be made to work someday. The one in between doesn't seem to work and nobody's actually trying to improve it; does it have a reason for still being there? (Is somebody, anywhere, successfully using it for anything?) Yes, I use it and it works. (And while we're at it, what does this mean: ./libpthread/linuxthreads.old/sysdeps/x86_64/pt-machine.h:39: warning: register used for two global register variables ) Which versions of binutils and gcc? DOMULTI set in configure? It was whatever ubuntu came with (2.18 and 4.1.3), and using the .config I attached on sunday (which had DOMULTI set). UCLIBC_HAS_STUBS This is just fork on nommu, right? Shouldn't it be under nommu sypport and depend on it? The additional comment is a bit misleading. Initially i ment it to just be the first paragraph with s/impossible/impossible or unwarranted/ UCLIBC_BUILD_RELRO UCLIBC_BUILD_NOW There are no help entries for these, and no _clue_ why one defaults to on and the other off. man ld I was thinking it might be a good idea to explain in the menuconfig help what the uClibc config options actually do. Call me crazy... I've looked at the LD man page, and although the NOW entry is fairly understandable: now When generating an executable or shared library, mark it to tell the dynamic linker to resolve all symbols when the program is started, or when the shared library is linked to using dlopen, instead of deferring function call resolution to the point when the function is first called. It doesn't even speculate about the advantages/disadvantages of actually doing it. After re-reading the man page, I still don't know what relro means: relro Create an ELF PT_GNU_RELRO segment header in the object. norelro Don't create an ELF PT_GNU_RELRO segment header in the object. I googled for PT_GNU_RELRO, but the first page of hits all assumed you knew what it meant. Some had hopeful titles, but alas... http://sources.redhat.com/ml/libc-hacker/2004-01/msg00053.html I tried several search variants and eventually found a blog entry on it: http://www.airs.com/blog/archives/189 Which itself spends the last paragraph talking about how obscure and poorly-documented a feature it is. If we assume that five minutes of googling and reading per config entry is acceptable, with around 200 config entries, this would mean that configuring uClibc for the first time can be expected to take about 2 full work days. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org
Re: confirmed working NPTL revision?
Hello, On Tue, 2008-08-19 at 13:14 +0200, Carmelo AMOROSO wrote: Cristi Magherusan wrote: On Tue, 2008-08-19 at 08:34 +0200, Carmelo Amoroso wrote: Cristi Magherusan wrote: Hello, Can anyone tell which revision of the NPTL branch is tested and confirmed to work well on x86? None, only mips, arm and sh4 have nptl support. Can we hope for a x86 version in the (near) future? My application (the kvm userspace tool) needs Thread Local Storage support and some other things from the libc. It seems the main uclibc branch lacks the TLS stuff and it is present in the NPTL one. TLS does not imply NTPL. TLS concerns handling of a new kind of relocation and it should be provided by the dynamic linker, while NPTL is the Posix implementation on a pthread library rather then using linuxthreads implementation. Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? I can volunteer, but I may need someone more experienced to guide me. What could be the complexity/difficulty of implementing NPTL support on x86? do you need TLS support or NPTL pthread library too? I only need TLS support. My program crashes when encountering variables declared with __thread. And that has nothing to do with the threading implementation, but only with the TLS support it provides. Regards, Cristi -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații Pusztai Kalman Tel. 0264/401247 http://cc.utcluj.ro 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: confirmed working NPTL revision?
On Wed, Aug 27, 2008 at 12:58:50PM +0300, Cristi Magherusan wrote: Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? Perhaps it would be better to update the non-old libpthread to something recent and add TLS to that. The .old is the proven fallback AFAIU. I can volunteer, but I may need someone more experienced to guide me. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Auditing the menuconfig help entries.
On Wed, 27 Aug 2008, Will Newton wrote: LINUXTHREADS_OLD: Ok, what does this currently mean? This selects the old libpthreads implementation from the dawn of time, but what's the alternative? The new NPTL stuff hasn't been merged yet, so this intermediate version is... what? OLD means the old version. !OLD is something newer. !UCLIBC_HAS_THREADS is what i do and the rest is a myth. OLD works now. In theory NPTL might be made to work someday. The one in between doesn't seem to work and nobody's actually trying to improve it; does it have a reason for still being there? (Is somebody, anywhere, successfully using it for anything?) Yes, I use it and it works. Any idea what is wrong with the !old version, in that it seems not to be recommended for use? /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: status of 0.9.30 release
On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote: Hi, Were there any plans for a 0.9.30 release before the NPTL merge? What is the status of the 0.9.30 release? vapier would know, ISTR that he was the designated RM. What are the outstanding regressions versus 0.9.29 on your arch? i386 seems to be in a good shape, AFAICS. Perhaps it would be nice to look at the open issues in mantis and fix a couple of them for .30-rc1. Just a thought.. cheers, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Auditing the menuconfig help entries.
On Wed, Aug 27, 2008 at 12:39:44PM +0200, Ricard Wanderlof wrote: Yes, I use it and it works. Any idea what is wrong with the !old version, in that it seems not to be recommended for use? IIRC the old is the fallback if you encounter problems in the !old. Since the !old is, by now, supposedly not too current either, somebody could look into updating the !old, i guess (but then, i'm not interrested in any of them). ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Auditing the menuconfig help entries.
On Wed, Aug 27, 2008 at 11:46 AM, Bernhard Reutner-Fischer
[EMAIL PROTECTED] wrote:
On Wed, Aug 27, 2008 at 12:39:44PM +0200, Ricard Wanderlof wrote:
Yes, I use it and it works.
Any idea what is wrong with the !old version, in that it seems not to be
recommended for use?
IIRC the old is the fallback if you encounter problems in the !old.
Since the !old is, by now, supposedly not too current either, somebody
could look into updating the !old, i guess (but then, i'm not
interrested in any of them).
Last time I looked the linuxthreads development had slowed to the
point that the diff to the HEAD is actually quite small. I have a
patch I made that looks like this:
descr.h| 11 +--
manager.c | 26 +++---
pthread.c | 36 +---
specific.c | 10 ++
spinlock.c | 14 +-
spinlock.h |6 --
6 files changed, 76 insertions(+), 27 deletions(-)
That patch is no longer current and I can't guarantee it's correctness.
--- libpthread/linuxthreads/descr.h 5 Feb 2008 14:49:33 - 1.2
+++ libpthread/linuxthreads/descr.h 23 Apr 2008 13:27:00 -
@@ -123,9 +123,9 @@
union dtv *dtvp;
pthread_descr self; /* Pointer to this structure */
int multiple_threads;
-# ifdef NEED_DL_SYSINFO
uintptr_t sysinfo;
-# endif
+ uintptr_t stack_guard;
+ uintptr_t pointer_guard;
} data;
void *__padding[16];
} p_header;
@@ -193,6 +193,13 @@
size_t p_alloca_cutoff; /* Maximum size which should be allocated
using alloca() instead of malloc(). */
/* New elements must be added at the end. */
+
+ /* This member must be last. */
+ char end_padding[];
+
+#define PTHREAD_STRUCT_END_PADDING \
+ (sizeof (struct _pthread_descr_struct) \
+ - offsetof (struct _pthread_descr_struct, end_padding))
} __attribute__ ((aligned(32))); /* We need to align the structure so that
doubles are aligned properly. This is 8
bytes on MIPS and 16 bytes on MIPS64.
--- libpthread/linuxthreads/manager.c 20 Dec 2007 17:04:03 - 1.1.1.1
+++ libpthread/linuxthreads/manager.c 23 Apr 2008 13:27:00 -
@@ -679,6 +679,17 @@
new_thread-p_inheritsched = attr ? attr-__inheritsched : 0;
new_thread-p_alloca_cutoff = stksize / 4 __MAX_ALLOCA_CUTOFF
? __MAX_ALLOCA_CUTOFF : stksize / 4;
+
+ /* Copy the stack guard canary. */
+#ifdef THREAD_COPY_STACK_GUARD
+ THREAD_COPY_STACK_GUARD (new_thread);
+#endif
+
+ /* Copy the pointer guard value. */
+#ifdef THREAD_COPY_POINTER_GUARD
+ THREAD_COPY_POINTER_GUARD (new_thread);
+#endif
+
/* Initialize the thread handle */
__pthread_init_lock(__pthread_handles[sseg].h_lock);
__pthread_handles[sseg].h_descr = new_thread;
@@ -742,15 +753,15 @@
pid = __clone2(pthread_start_thread_event,
(void **)new_thread_bottom,
(char *)stack_addr - new_thread_bottom,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#elif _STACK_GROWS_UP
pid = __clone(pthread_start_thread_event, (void *) new_thread_bottom,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#else
pid = __clone(pthread_start_thread_event, stack_addr,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#endif
saved_errno = errno;
@@ -783,15 +794,15 @@
pid = __clone2(pthread_start_thread,
(void **)new_thread_bottom,
(char *)stack_addr - new_thread_bottom,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#elif _STACK_GROWS_UP
pid = __clone(pthread_start_thread, (void *) new_thread_bottom,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#else
pid = __clone(pthread_start_thread, stack_addr,
- CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND |
+ CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_SYSVSEM |
__pthread_sig_cancel, new_thread);
#endif /* !NEED_SEPARATE_REGISTER_STACK */
saved_errno = errno;
@@ -892,10 +903,11 @@
#ifdef _STACK_GROWS_UP
# ifdef USE_TLS
size_t stacksize = guardaddr - th-p_stackaddr;
+ guardaddr = th-p_stackaddr;
# else
size_t stacksize = guardaddr - (char *)th;
-# endif
guardaddr = (char *)th;
+# endif
#else
/* Guardaddr is always set, even if guardsize is 0. This allows
us to compute everything else. */
--- libpthread/linuxthreads/pthread.c 20 Dec 2007 17:04:03 - 1.1.1.1
+++
ICE in change_decl_assembler_name() [was: svn commit: trunk/uClibc: extra/scripts include]
On Sun, Jun 08, 2008 at 01:38:54PM -0700, [EMAIL PROTECTED] wrote: Author: bernds Date: 2008-06-08 13:38:53 -0700 (Sun, 08 Jun 2008) New Revision: 22271 Log: In string.h, move libc_hidden_proto next to the corresponding declaration. Filter them out when installing headers. Tested by building up bfin-*linux toolchains and building our copy of uClinux-dist. Modified: trunk/uClibc/include/string.h === --- trunk/uClibc/include/string.h 2008-06-08 16:47:09 UTC (rev 22270) +++ trunk/uClibc/include/string.h 2008-06-08 20:38:53 UTC (rev 22271) @@ -38,10 +38,12 @@ extern void *memcpy (void *__restrict __dest, __const void *__restrict __src, size_t __n) __THROW __nonnull ((1, 2)); +libc_hidden_proto(memcpy) Hi, unfortunately this trips an assert on current gcc trunk for uClibc's DOMULTI (all honza's fault i assume, this definitely compiled fine some weeks ago ;) In file included from libc/sysdeps/linux/i386/sigaction.c:24: ./include/string.h:41: internal compiler error: in change_decl_assembler_name, at cgraph.c:1154 $ head -n 1154 cgraph.c | tail -n1 gcc_assert (!assembler_name_hash); Perhaps you can look into it? PS: oh, and i would be very grateful if you could eventually comment on my patch for PR31537 (an issue with duplicate weakrefs where i have no clear idea on how this was ment to work in the first place; perhaps you do or somebody here does?). That PR is not really related but IIRC both uClibc and libgfortran triggered it. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] move ifaddrs.h from libc/inet to include
On Wed, Aug 27, 2008 at 04:29:57PM +0200, Ricard Wanderlof wrote:
Yeah, should have split this into one 'follow-up-the-thread' and one
actual patch. So, resending the patch with correct subject. Sorry for the
confusion.
Here's a patch to move ifaddrs.h from libc/inet/ to include/ . It is also
removed from the installed include files if UCLIBC_SUPPORT_AI_ADDRCONFIG
is not enabled. It's largely the same as what Bernhard and Yann sent in a
while ago. It has been tested with UCLIBC_SUPPORT_AI_ADDRCONFIG enabled
and disabled.
Patch made against svn 23243, and included inline as well as an
attachment. If there are no comments, I'll go ahead and commit this in a
couple of days.
Ok if you change the comment to fit in one line, like
# Remove ifaddrs.h since it was disabled upon request
so it's congruent with the rest.
Thanks,
PS: I don't remember if you added a testcase for both getifaddrs() and
freeifaddrs(). Please consider adding those if you haven't done it
already.
/Ricard
Index: Makefile.in
===
--- Makefile.in (revision 23242)
+++ Makefile.in (working copy)
@@ -331,6 +331,11 @@
# Remove crypt.h since libcrypt was disabled upon request
$(RM) $(PREFIX)$(DEVEL_PREFIX)include/crypt.h
endif
+ifneq ($(UCLIBC_SUPPORT_AI_ADDRCONFIG),y)
+ # Remove ifaddrs.h since the corresponding functionality was disabled
+ # by request
+ $(RM) $(PREFIX)$(DEVEL_PREFIX)include/ifaddrs.h
+endif
# Installs development library links.
install_dev: install_headers
Index: include/ifaddrs.h
===
--- include/ifaddrs.h (revision 0)
+++ include/ifaddrs.h (revision 0)
@@ -0,0 +1,74 @@
+/* ifaddrs.h -- declarations for getting network interface addresses
+ Copyright (C) 2002 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#ifndef _IFADDRS_H
+#define _IFADDRS_H 1
+
+#include features.h
+#include sys/socket.h
+
+__BEGIN_DECLS
+
+/* The `getifaddrs' function generates a linked list of these structures.
+ Each element of the list describes one network interface. */
+struct ifaddrs
+{
+ struct ifaddrs *ifa_next;/* Pointer to the next structure. */
+
+ char *ifa_name; /* Name of this network interface. */
+ unsigned int ifa_flags; /* Flags as from SIOCGIFFLAGS ioctl. */
+
+ struct sockaddr *ifa_addr; /* Network address of this interface. */
+ struct sockaddr *ifa_netmask; /* Netmask of this interface. */
+ union
+ {
+/* At most one of the following two is valid. If the IFF_BROADCAST
+ bit is set in `ifa_flags', then `ifa_broadaddr' is valid. If the
+ IFF_POINTOPOINT bit is set, then `ifa_dstaddr' is valid.
+ It is never the case that both these bits are set at once. */
+struct sockaddr *ifu_broadaddr; /* Broadcast address of this interface.
*/
+struct sockaddr *ifu_dstaddr; /* Point-to-point destination address. */
+ } ifa_ifu;
+ /* These very same macros are defined by net/if.h for `struct ifaddr'.
+ So if they are defined already, the existing definitions will be fine.
*/
+# ifndef ifa_broadaddr
+# define ifa_broadaddrifa_ifu.ifu_broadaddr
+# endif
+# ifndef ifa_dstaddr
+# define ifa_dstaddr ifa_ifu.ifu_dstaddr
+# endif
+
+ void *ifa_data; /* Address-specific data (may be unused). */
+};
+
+
+/* Create a linked list of `struct ifaddrs' structures, one for each
+ network interface on the host machine. If successful, store the
+ list in *IFAP and return 0. On errors, return -1 and set `errno'.
+
+ The storage returned in *IFAP is allocated dynamically and can
+ only be properly freed by passing it to `freeifaddrs'. */
+extern int getifaddrs (struct ifaddrs **__ifap) __THROW;
+
+/* Reclaim the storage allocated by a previous `getifaddrs' call. */
+extern void freeifaddrs (struct ifaddrs *__ifa) __THROW;
+
+__END_DECLS
+
+#endif /* ifaddrs.h */
Index: libc/inet/ifaddrs.c
===
---
Re: Auditing the menuconfig help entries.
On Wed, 27 Aug 2008, Will Newton wrote: Any idea what is wrong with the !old version, in that it seems not to be recommended for use? No, I'm not sure. There were a few small issues with Makefiles but I think these are all fixed now. Certainly we are shipping it in a product that will probably sell hundreds of thousands of units and uses pthreads quite extensively. We use it because it supports upward-growing stacks which the old pthreads does not. If you have any specific issues then let me know and I'll go have a dig in our source repository to see if there's any changes I haven't pushed upstream that I forgot about. No, no specific issues, really just a reaction on the general don't use anything but linuxthreads.old that seems to prevail here on the list and in the menuconfig help texts. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
fenv.h missing, gcc-4.3.1 issue
gcc-4.3.1 seems to need fenv.h, or more specifically information from within bits/fenv.h. Because bits/fenv.h should not be directly included a stub fenv.h needs to be created so that '#include fenv.h' works. Currently, no fenv.h exists as far as I can find. (Looking under uClibc-0.8.28.3 and uClibc-0.8.29, I did not find the fenv.h that includes bits/fenv.h.) Here is what worked for me, fenv.h contents: #ifndef _FENV_H #define _FENV_H 1 #include features.h #include bits/fenv.h #endif /* fenv.h */ Thats it, GCC-4.3.1 now continues to compile past: FE_INEXACT not defined issues (see: gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c) -- Kevin Day ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: fenv.h missing, gcc-4.3.1 issue
On Wed, Aug 27, 2008 at 11:17:39AM -0500, Kevin Day wrote: gcc-4.3.1 seems to need fenv.h, or more specifically information from within bits/fenv.h. Because bits/fenv.h should not be directly included a stub fenv.h needs to be created so that '#include fenv.h' works. Currently, no fenv.h exists as far as I can find. (Looking under uClibc-0.8.28.3 and uClibc-0.8.29, I did not find the fenv.h that includes bits/fenv.h.) Here is what worked for me, fenv.h contents: #ifndef _FENV_H #define _FENV_H 1 #include features.h #include bits/fenv.h #endif /* fenv.h */ Thats it, GCC-4.3.1 now continues to compile past: FE_INEXACT not defined issues (see: gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c) Search the uClibc and buildroot archives for details. HTH, Bernhard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] move ifaddrs.h from libc/inet to include
Ricard, Bernhard, All, On Wednesday 27 August 2008 16:29:57 Ricard Wanderlof wrote: Here's a patch to move ifaddrs.h from libc/inet/ to include/ . It is also removed from the installed include files if UCLIBC_SUPPORT_AI_ADDRCONFIG is not enabled. It's largely the same as what Bernhard and Yann sent in a while ago. It has been tested with UCLIBC_SUPPORT_AI_ADDRCONFIG enabled and disabled. OK from my point of view. Apart form the comment by Bernhard. Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^| | --== ^_^ ==-- `.---: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|conspiracy. | `--^---^--^' ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: fenv.h missing, gcc-4.3.1 issue
On Wed, 2008-08-27 at 18:53 +0200, Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 11:17:39AM -0500, Kevin Day wrote: gcc-4.3.1 seems to need fenv.h, or more specifically information from within bits/fenv.h. Because bits/fenv.h should not be directly included a stub fenv.h needs to be created so that '#include fenv.h' works. Currently, no fenv.h exists as far as I can find. (Looking under uClibc-0.8.28.3 and uClibc-0.8.29, I did not find the fenv.h that includes bits/fenv.h.) Here is what worked for me, fenv.h contents: #ifndef _FENV_H #define _FENV_H 1 #include features.h #include bits/fenv.h #endif /* fenv.h */ Thats it, GCC-4.3.1 now continues to compile past: FE_INEXACT not defined issues (see: gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c) Search the uClibc and buildroot archives for details. HTH, Bernhard fenv.h was missing from 0.9.29 but got committed to current in r20880 and it has nothing to do with gcc-4.3. The problem with gcc-4.3 is related to limits.h which got moved from include/ to include-fixed/ and busybox was still broken last time I checked. uClibc got a workaround in r22067 Cristi -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații Pusztai Kalman Tel. 0264/401247 http://cc.utcluj.ro ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: fenv.h missing, gcc-4.3.1 issue
On Wed, Aug 27, 2008 at 09:40:43PM +0300, Cristi Magherusan wrote: fenv.h was missing from 0.9.29 but got committed to current in r20880 and it has nothing to do with gcc-4.3. well libdecnumber can be configured to use fenv(3) and libdecnumber is in gcc, so it is in fact related (a little bit, if you like). The problem with gcc-4.3 is related to limits.h which got moved from include/ to include-fixed/ and busybox was still broken last time I checked. uClibc got a workaround in r22067 Well, that's not a workaround but the correct thing to do. I'm not sure how busybox is related, though, since it isn't using nostdinc IIRC, and that, too, is ok for busybox. cheers, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote: Takashi Yoshii wrote: For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I had to think about this briefly. It was part of the SH-2 work done by Mark Shinwell (added to Cc). The disabling of GOT related code in the non-shared case was intentional, but I don't immediately recall what the rationale was. Original thread here: http://www.uclibc.org/lists/uclibc/2006-October/016617.html I expect that it's related to the ABI, in that we also don't have the GOT references in the FDPIC case, so it should likely be conditionalized for the targets that actually emit _GLOBAL_OFFSET_TABLE_, rather than depending on __HAVE_SHARED__. While I hit this on FDPIC, I would wager that Mark hit this on shared FLAT (which we don't have support in-tree for anyways) on his internal libc. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh : a little optimization in clone.S
Carmelo AMOROSO wrote: Hi Paul, All attached a little fix in clone asm code for SH to use a delayed branch instead of a normal branch. Let me know so I can commit it. Regards, Carmelo Please hold on. After a discussion with a colleague of mine, really sh4 architectural expert, we are thinking that it could not be a real optimization due to potential unuseful i-cache miss. So, I need to clarify it before. sorry ;-) Carmelo ___ 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
