glibc hppa - get/set/make/swap/context() & non-atomic ops
PA'ers, Comments or thoughts about the following issues would be appreciated. These items are taken from my collection of TODO notes for glibc, and were recently added by comments from Helge and Willy. - Implement make/swap/set/get/context() calls in glibc = Don't know what's needed... can probably learn = about the calls from other arches. - Doesn't look like it will be that hard. - Helge brought the issue up since SAPDB relies - on this to work properly (www.sapdb.org) - With mcontext working properly... these calls - _should_ work :} * Didn't know these were broken or missing. - Make atomic ops atomic = Need to implement exhcange_and_add/atomic_add = and compare_and_swap. - I have no idea how hard this will be. - PA has a single atomic operation called ldcw - Which is 'load and zero' ... we currently use - this to implement locking primities. * Are we going to have to use spinlocks to * handle the atomic operations? * I see 11 uses of generic/atomicity.h that need * to be fixed. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Breaking PARISC ABI - Testing procedures?
> 3- sizeof(long double) is incorrect in gcc and glibc (?) This also needs to be fixed under 64-bit hpux. Need to determine the calling convention for long doubles. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158497: _PATH_*PATH variables in don't conform to debian standards
Package: libc6-dev Version: 2.2.5-14 Severity: normal Tags: patch Hello, Looking at paths.h: /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" /* All standard utilities path. */ #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin" This is suposed to contain the "default" and "standard" paths for system users. Paths in Debian are defined by the ENV_PATH and ENV_SUPATH variables in /etc/login.defs, which default to: ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin\:/usr/local/bin ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games I think these are saner and the GNU project should accept them for glibc. Even if they don't we should have them in Debian, for they are the default here as choosen in /etc/login.defs. I made up a fixed version where _PATH_STDPATH contains Debian's requirements and _PATH_DEFPATH a set of essential directories, excluding X11, local and games. Also, _PATH_*PATH_ROOT are missing but used in some places so i'm including them too. Here is a patch: --- paths.h.old 2002-08-27 17:11:18.0 +0200 +++ paths.h 2002-08-27 17:42:24.0 +0200 @@ -36,7 +36,13 @@ #define_PATH_DEFPATH "/usr/bin:/bin" /* All standard utilities path. */ #define_PATH_STDPATH \ - "/usr/bin:/bin:/usr/sbin:/sbin" + "/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games" + +/* Default search path for root. */ +#define_PATH_DEFPATH_ROOT "/usr/bin:/bin:/usr/sbin:/sbin" +/* All standard utilities path for root. */ +#define_PATH_STDPATH_ROOT \ + "/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin" #define_PATH_BSHELL"/bin/sh" #define_PATH_CONSOLE "/dev/console" -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux aragorn 2.2.21 #1 Thu Aug 8 13:53:32 CEST 2002 i586 Locale: LANG=ca_ES.ISO-8859-1, LC_CTYPE=ca_ES.ISO-8859-1 Versions of packages libc6-dev depends on: ii libc6 2.2.5-14 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Glibc 2.3
Drepper posted an email[0] yesterday indicating that 2.3 is imminent. To help with this transition, I will cook up some i386 packages based on 2.3 for some initial QA. Should I upload them to experimental, or should I just post them in people.d.o/~jbailey/? Note that I already know that hurd-i386 won't be able to run the 2.3 packages. Anyone else know of other archs that already have special needs? (Once I have these ready, I'll post this message to debian-ports - I'm not ready for a flood of emails yet) [0] http://sources.redhat.com/ml/libc-hacker/2002-08/msg00150.html -- I reincarnated for this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Glibc 2.3
On Tue, Aug 27, 2002 at 08:49:21PM -0700, Jeff Bailey wrote: > Drepper posted an email[0] yesterday indicating that 2.3 is imminent. > To help with this transition, I will cook up some i386 packages based > on 2.3 for some initial QA. > > Should I upload them to experimental, or should I just post them in > people.d.o/~jbailey/? > > Note that I already know that hurd-i386 won't be able to run the 2.3 > packages. Anyone else know of other archs that already have special > needs? (Once I have these ready, I'll post this message to > debian-ports - I'm not ready for a flood of emails yet) For now I strongly suggest just keeping the packages private for testing. Especially do not upload them to experimental. Having them out for public consumption is a bad bad idea. Once Drepper releases 2.2.90, we can make packages based on that, run it through its test suite for all arch's, and decide on when to upload it to unstable. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158589: libc6: please provide an udeb
Package: libc6 Severity: wishlist Priority: high, pretty please, with sugar on top. Debian-installer will need an udeb with the full libc6.so in it. (It doesn't need to have any old symbols -- actually, it would be nice if it didn't have old symbols, because of the size issue). (See debian-installer module in debian-boot cvs for some information about udebs, if you don't know them yet). We need libdl and libm as well in there. Thanks! -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
