On Tue, Jul 8, 2008 at 4:49 AM, Miguel Gea Milvaques
[EMAIL PROTECTED] wrote:
Package: glibc
Version: 2.7-12
Severity: serious
Justification: no longer builds from source
It fails to build in hppa. See buildd logs [1].
[1]
On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
Workaround is already upstream here:
http://sourceware.org/bugzilla/show_bug.cgi?id=6653
I don't really like this workaround, this just means that every program
that use a regex and an UTF-8 locale will hang...
In case
On Tue, Jul 8, 2008 at 12:09 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
Carlos O'Donell a écrit :
On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
Workaround is already upstream here:
http://sourceware.org/bugzilla/show_bug.cgi?id=6653
I don't really like
On Mon, Jun 16, 2008 at 8:13 PM, John Wright [EMAIL PROTECTED] wrote:
Package: glibc
Version: 2.7-12
Severity: normal
I'm trying to test rebuilding the archive against an nptl-enabled glibc
on hppa, but I'm having trouble building glibc. I have attached the
patch against 2.7-12 that I used
On Wed, May 7, 2008 at 10:24 PM, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Thu, May 08, 2008 at 03:16:38AM +0200, Frank Lichtenheld wrote:
Package: libc6-dev
Version: 2.7-10
Severity: important
On HPPA sys/user.h only contains #include linux/user.h
which doesn't do anything
On Sat, Mar 15, 2008 at 10:04 AM, Angel Tsankov
[EMAIL PROTECTED] wrote:
Is there a way to extract a subset of the files in glibc? Sorry if this is
an off-topic.
This is a very vague question. Could you epxlain what you want to
extract, why you want to extract it, and from where?
Cheers,
On 7/26/07, dann frazier [EMAIL PROTECTED] wrote:
Package: glibc
Version: 2.6-4
Severity: serious
From:
http://buildd.debian.org/fetch.cgi?pkg=glibcver=2.6-4arch=hppastamp=1185478685file=log
[snip]
gcc-4.2 -nostdlib -nostartfiles -shared -o
On 6/2/07, John David Anglin [EMAIL PROTECTED] wrote:
Ok, I applied the first fix, and now -pie exe are working again !!!
Hope that update gets installed ASAP.
#else
/* load main (1st argument) */
ldilLR'.Lpmain, %r26
ldw RR'.Lpmain(%r26), %r26
On 6/1/07, Sébastien Bernard [EMAIL PROTECTED] wrote:
This problem is indeed related to the pie. Same kind of crash before the
main function start.
I'll start a glibc build and check the flags.
This is because PIE is broken on hppa, and the glibc testsuite shows
this problem.
Aurelien,
Who
On 5/18/07, Clint Adams [EMAIL PROTECTED] wrote:
I took a brief look, and concluded that the following modifications will
allow all the patches to apply. The lines that have been commented out
represent patches that need to be reviewed and either fixed or thrown
out. This is based on the 2.6
On 5/19/07, Clint Adams [EMAIL PROTECTED] wrote:
I am available for discussing these patches.
Some may already be upstream. For example I've committed the r19use
patch to ports already, and some of the nptl changes have been
committed already.
Where is the debian-glibc svn?
On 5/19/07, Carlos O'Donell [EMAIL PROTECTED] wrote:
What is your eta for having this cleaned up?
Better put, when would you like these patches cleaned up?
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On 5/19/07, John Zoidberg [EMAIL PROTECTED] wrote:
I'm running a Debian system with glibc6 2.3, but I'm stuck (i.e. I'm
unable to install TeX and friends) unless I upgrade to glibc 2.5.
This would be no problem if I didn't have to run commercial software
(including a cross compiling toolchain)
On 5/19/07, Clint Adams [EMAIL PROTECTED] wrote:
Better put, when would you like these patches cleaned up?
I'm just in a hurry to get the packaging tweaked so that I can build and
upload 2.6 to experimental, whether or not we have regressions from 2.5.
Then we can see how it builds and works
On 5/15/07, Frans Pop [EMAIL PROTECTED] wrote:
Today I saw this error for the second time on my hppa box running the
2.6.18-parisc64-smp kernel:
cat: error while loading shared libraries: internal error: symidx out of
range of fptr table
This does not appear to be a reproducable error.
The
On 4/12/07, Aurelien Jarno [EMAIL PROTECTED] wrote:
Also for hppa and glibc 2.6, if we are not able to build it linuxthreads
+ TLS support, we will have to switch to NPTL, and that *may* mean a
libc transition. We are still waiting for more information from the
upstream hppa porters.
The
On 2/23/07, Roland McGrath [EMAIL PROTECTED] wrote:
Unfortunatly, due to alignment the NPTL pthread_cond_t grows larger
than the Linuxthreads version when I add the padding. This is the only
structure the grows larger in size than before. Is there any way I can
avoid adding the padding?
It
On 2/23/07, Roland McGrath [EMAIL PROTECTED] wrote:
In the new structure we have shifted everything up because __lock is
now an integer, instead of a _pthread_fastlock with a 4 word lock
structure. Should I add padding after __lock e.g. int pad[3]?
Yes, you must dedicate those words to
On 2/22/07, Roland McGrath [EMAIL PROTECTED] wrote:
All statically initialized locks are broken. We made locks smaller,
and changed the value of the static initialization.
Smaller? Smaller is easy. And you didn't actually reduce
__SIZEOF_PTHREAD_MUTEX_T, did you? This seems like it would
On 2/19/07, Aurelien Jarno [EMAIL PROTECTED] wrote:
Well, the ABI breakage is confirmed. I just remember people siting
some other corner case problems with the ABI they wanted to change.
Now would be a great time to change it all over if we need to do this.
You mean on hppa? Do you remember
NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
have broken the pthread ABI.
I made the choice. I told people we were breaking the ABI. We even
looked at weird alternatives. In the end I felt we could not sanely
support NPTL with load and clear word primitives. When I say
On 2/18/07, Roland McGrath [EMAIL PROTECTED] wrote:
NPTL for hppa-linux is not backwards compatible with Linuxthreads, we
have broken the pthread ABI.
Please elaborate on exactly which types and entrypoints are incompatible.
All statically initialized locks are broken. We made locks
On 2/6/07, Guy Martin [EMAIL PROTECTED] wrote:
make[2]: ***
[/var/tmp/portage/glibc-2.5/work/build-default-hppa2.0-unknown-linux-gnu-nptl/math/test-float.out]
Error 1
make[2]: ***
[/var/tmp/portage/glibc-2.5/work/build-default-hppa2.0-unknown-linux-gnu-nptl/math/test-double.out]
Error 1
On 2/6/07, Matthew Wilcox [EMAIL PROTECTED] wrote:
On Mon, Feb 05, 2007 at 10:13:01PM -0500, Carlos O'Donell wrote:
make[2]: *** [/libc-tls-nptl/io/tst-fstatat.out] Error 1
make[2]: *** [/libc-tls-nptl/io/tst-futimesat.out] Error 1
make[2]: *** [/libc-tls-nptl/io/tst-renameat.out] Error 1
On 2/6/07, Guy Martin [EMAIL PROTECTED] wrote:
The NaN fix was applied. The bug changed this way after aplying it :
Test suite completed:
2917 test cases plus 2564 tests for exception flags executed.
4 errors occurred.
This is a tolerance issue. Udate sysdeps/hppa/fpu/libm-test-ulps. I
On 2/5/07, Guy Martin [EMAIL PROTECTED] wrote:
Also what is the current status of NPTL on HPPA. Last time I tried it
was building but they were some failures in the testsuite. I am
currently building a test version here. Is it something stable enough
that it can be used in production? I have
I did a bit of hacking this evening...
only to find more compiler bugs, and workarounds :-)
The glibc head hppa-linux testsuite baseline looks like this:
make[2]: [/libc-tls-nptl/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/libc-tls-nptl/io/tst-fstatat.out] Error 1
make[2]: ***
On 8/29/06, Aurelien Jarno [EMAIL PROTECTED] wrote:
Ok I see. I actually asked that, because the testsuite was still running
when I sent my mail. Now it is finished, and I have see the errors in
the testsuite :( Thanks a lot for you hard work on the hppa glibc.
I think there are a handful of
On 8/27/06, Aurelien Jarno [EMAIL PROTECTED] wrote:
What are exactly the serious bugs currently with the NPTL version?
If I knew I would fix them. As Jeff says, there are serious testsuite
failures. We are debugging them as fast as possible given the
volunteer nature of our effort.
Given the
On 8/25/06, Aurelien Jarno [EMAIL PROTECTED] wrote:
If we count the glibc in experimental all the architectures but the
following have TLS support:
- hppa
It has TLS support in upstream binutils, in gcc 4.1, and there are
patches available for glibc, they seems to work. Some people are
For the HPPA port, guys from parisc-linux are doing very good job for
both the kernel and the glibc. If I am right some of them (at least
Carlos) have commit access to the CVS for HPPA.
Having write access to the Debian SVN, having an HPPA machine and
reading debian-hppa, parisc-linux and
On Thu, Oct 13, 2005 at 11:11:50PM -0400, Daniel Jacobowitz wrote:
On Wed, Sep 21, 2005 at 12:46:48PM -0400, Carlos O'Donell wrote:
- These are double word stores, so you need sw[2].
Oh, this one's not right either - see today's #333766. You need to
make it aligned(8), or GCC may not give
On Thu, Oct 13, 2005 at 11:10:18PM -0400, Daniel Jacobowitz wrote:
On Wed, Sep 21, 2005 at 12:46:48PM -0400, Carlos O'Donell wrote:
int
fesetround (int round)
{
struct { unsigned int sw[2]; } s;
/* Get the current status word. */
__asm__ (fstd %%fr0,0(%1) : =m (s) : r (s
My apologies for not responding to this bug earlier. I'm currently the
upstream maintainer for the glibc port to hppa. I also try to do all the
debian libc6 work. I'm suffering from the must finish thesis syndrome
and I had to drop everything. A consequence is that hppa has some
mis-merged
On Sun, May 15, 2005 at 02:52:58PM +0100, Matthew Wilcox wrote:
On Sat, May 14, 2005 at 03:15:36PM -0400, Carlos O'Donell wrote:
On Fri, May 13, 2005 at 09:26:10PM +0100, Matthew Wilcox wrote:
If you want to change glibc at this point, discuss with Carlos; I can't
take care of it. Just
On Fri, May 13, 2005 at 09:26:10PM +0100, Matthew Wilcox wrote:
If you want to change glibc at this point, discuss with Carlos; I can't
take care of it. Just getting -22 built has taken most of my free time
for this week.
Carlos? This seems like your fault, how do *you* want to fix it?
debian-glibc,
The newest compiler in unstable has caught a bug in the feupdateenv
implementation for hppa. The code should not be using the constant input
argument as temporary scratch.
Cheers,
Carlos.
2004-04-02 Carlos O'Donell [EMAIL PROTECTED]
* patches/00list: Add hppa
On Wed, Feb 25, 2004 at 10:07:59AM +0100, Julien BLACHE wrote:
The define is shown in *example* code. It doesn't say anywhere that it
must be defined.
I understand this snippet of code in the manpage as look, this is how
the thing is defined in the header, not as sample code.
No, that's
On Wed, Feb 25, 2004 at 10:07:59AM +0100, Julien BLACHE wrote:
The define is shown in *example* code. It doesn't say anywhere that it
must be defined.
I understand this snippet of code in the manpage as look, this is how
the thing is defined in the header, not as sample code.
No, that's
On Tue, Feb 24, 2004 at 06:55:59PM +0100, Julien BLACHE wrote:
I don't know this is intentional or not, but there is no rule that we
need to define UNIX_PATH_MAX. In addition POSIX does not define its
path size (typically it's between 92 and 108, and linux is 108). If
you want to look
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote:
We currently run the glibc testsuite with 'make -k check', ingoring the
testsuite failures. This isn't the way we should be doing business.
Instead I propose we maintain a list of allowed failures per-arch,
including the make
On Tue, Feb 24, 2004 at 06:55:59PM +0100, Julien BLACHE wrote:
I don't know this is intentional or not, but there is no rule that we
need to define UNIX_PATH_MAX. In addition POSIX does not define its
path size (typically it's between 92 and 108, and linux is 108). If
you want to look
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote:
We currently run the glibc testsuite with 'make -k check', ingoring the
testsuite failures. This isn't the way we should be doing business.
Instead I propose we maintain a list of allowed failures per-arch,
including the make
On Thu, Feb 19, 2004 at 11:46:58PM -0500, Jeff Bailey wrote:
No, because that penalizes the common case (which could be expensive on
platforms like m68k).
I don't understand your comment, how does this penalize m68k?
If we build multiple passes the logfiles have different names (appended
On Thu, Feb 19, 2004 at 11:46:58PM -0500, Jeff Bailey wrote:
No, because that penalizes the common case (which could be expensive on
platforms like m68k).
I don't understand your comment, how does this penalize m68k?
If we build multiple passes the logfiles have different names (appended
/convertlog.sh | 15 +++
debian/testsuite-checking/hppa-linux-test-results | 17
5 files changed, 84 insertions(+), 1 deletion(-)
---
2004-02-19 Carlos O'Donell [EMAIL PROTECTED]
* debian/rules: Define TESTING_CHECKING and TESTING_CURRENT,
disable
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote:
In debian/rules we set TESTING_CHECKING and TESTING_CURRENT. The former
is the location of the file containing the expected failures. While the
latter is the location we put our current results. If logging is
disabled we disable
/convertlog.sh | 15 +++
debian/testsuite-checking/hppa-linux-test-results | 17
5 files changed, 84 insertions(+), 1 deletion(-)
---
2004-02-19 Carlos O'Donell [EMAIL PROTECTED]
* debian/rules: Define TESTING_CHECKING and TESTING_CURRENT,
disable
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote:
In debian/rules we set TESTING_CHECKING and TESTING_CURRENT. The former
is the location of the file containing the expected failures. While the
latter is the location we put our current results. If logging is
disabled we disable
On Thu, Feb 19, 2004 at 05:17:45PM -0500, Carlos O'Donell wrote:
I've implemented this framework and attached the patch below. The logic is
as follows:
Thanks to Dan for helping me make the grep rule cleaner, it doesn't rely
on Make[3] being present, or rather it no longer relies
Richard,
Can you try out these changes and tell me if this fixes the issue?
http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-25/
It's against glibc 2.3.2-ds1-10, with two point changes that are in my
own tree. The first is a fix for profiling, already in
Richard,
Can you try out these changes and tell me if this fixes the issue?
http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-25/
It's against glibc 2.3.2-ds1-10, with two point changes that are in my
own tree. The first is a fix for profiling, already in
is present, do not setup lazy linking structures
# DP: Related bugs: debian installer breaks on hppa.
# DP: Author: Carlos O'Donell (Reported by Richard Hirst)
# DP: Upstream status: Pending
# DP: Status Details: This file has a lot of changes going upstream.
# DP: Date: 2004-01-24
if [ $# -ne 2
is present, do not setup lazy linking
structures
# DP: Related bugs: debian installer breaks on hppa.
# DP: Author: Carlos O'Donell (Reported by Richard Hirst)
# DP: Upstream status: Pending
# DP: Status Details: This file has a lot of changes going upstream.
# DP: Date: 2004-01-24
if [ $# -ne 2
On Sun, Jan 25, 2004 at 04:23:20AM +0900, GOTO Masanori wrote:
Carlos, could you look at this report?
Regards,
-- gotom
Gotom,
I had a conversation with Richard about this and his conclusions were
correct. If there is no DT_PLTREL section then elf_machine_runtime_setup
has nothing to do,
On Sun, Jan 25, 2004 at 04:23:20AM +0900, GOTO Masanori wrote:
Carlos, could you look at this report?
Regards,
-- gotom
Gotom,
I had a conversation with Richard about this and his conclusions were
correct. If there is no DT_PLTREL section then elf_machine_runtime_setup
has nothing to do,
The solution is to integrate upstream changes for:
libc/linuxthreads/sysdeps/pthread/malloc-machine.h
libc/linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h
libc/nptl/sysdeps/pthread/malloc-machine.h
libc/sysdeps/generic/malloc-machine.h
debian-glibc,
Some updates for hppa, still pending are a *lot* of local changes that I
need to submit upstream first for revision.
* Carlos O'Donell [EMAIL PROTECTED]
- debian/patches/51_glibc232-hppa-dist.dpatch: Add entry.h to dist.
- debian/patches/51_glibc232-hppa
The solution is to integrate upstream changes for:
libc/linuxthreads/sysdeps/pthread/malloc-machine.h
libc/linuxthreads/sysdeps/unix/sysv/linux/hppa/malloc-machine.h
libc/nptl/sysdeps/pthread/malloc-machine.h
libc/sysdeps/generic/malloc-machine.h
Package: glibc
Version: 2.3.2.ds1-10
Severity: important
malloc's arena locking routines in glibc rely on simple locking
functions that assume lock taken is 1 and lock released is 0.
This is not the case for hppa, the architecture has only one
primitive locking instruction ldcw (load and clear
219458,
hppa does not support utimes, it supports utime. During the last
coreutils build it seems that configure was confused and thought hppa
*had* utimes, but it does not.
http://buildd.debian.org/fetch.php?pkg=coreutilsver=5.0.91-2arch=hppastamp=1065315205file=logas=raw
--- checkdd.log
219458,
hppa does not support utimes, it supports utime. During the last
coreutils build it seems that configure was confused and thought hppa
*had* utimes, but it does not.
http://buildd.debian.org/fetch.php?pkg=coreutilsver=5.0.91-2arch=hppastamp=1065315205file=logas=raw
--- checkdd.log
Jeff,
glibc-package/debian/patches/glibc23-hppa-Rminkernel.dpatch
Has to go back into the list of patches, since it will keep users
running their boxes with 2.4.17 or later based kernels instead of
2.4.19. Developer testing didn't catch this since we all run 2.4.19.
Please and thank you!
I'm
Jeff, Drow,
00list patch provided for -rnptl, and .dpatch url provided.
http://www.baldric.uwo.ca/~carlos/glibc232-hppa-full-nptl-2003-10-22.dpatch
Cheers,
Carlos.
---
2003-10-22 Carlos O'Donell [EMAIL PROTECTED]
* debian/patches/00list: Remove all hppa patches, leave
Jeff, Drow,
00list patch provided for -rnptl, and .dpatch url provided.
http://www.baldric.uwo.ca/~carlos/glibc232-hppa-full-nptl-2003-10-22.dpatch
Cheers,
Carlos.
---
2003-10-22 Carlos O'Donell [EMAIL PROTECTED]
* debian/patches/00list: Remove all hppa patches, leave
On Tue, Oct 21, 2003 at 08:03:59AM -0400, Jeff Bailey wrote:
Hey Carlos - When submitting these upstream, will you consider adding
test cases for these failures? feraiseexcept should certainly be tested
somewhere. I don't know if there's a reasonable way to put in the test
for the syscalls,
On Tue, Oct 21, 2003 at 08:03:59AM -0400, Jeff Bailey wrote:
Hey Carlos - When submitting these upstream, will you consider adding
test cases for these failures? feraiseexcept should certainly be tested
somewhere. I don't know if there's a reasonable way to put in the test
for the syscalls,
Jeff,
glibc-package/debian/patches/glibc23-hppa-Rminkernel.dpatch
Has to go back into the list of patches, since it will keep users
running their boxes with 2.4.17 or later based kernels instead of
2.4.19. Developer testing didn't catch this since we all run 2.4.19.
Please and thank you!
I'm
On Sun, Oct 19, 2003 at 07:50:05PM -0400, Carlos O'Donell wrote:
Will produce a new patch and new testing debs. Thanks go to all the
testers that turned up these problems.
New debs fix reported problems:
a. Six argument syscall faiulres.
b. feraiseexcept(FE_INEXACT) doesn't raise FE_INEXACT
On Sun, Oct 19, 2003 at 07:50:05PM -0400, Carlos O'Donell wrote:
Will produce a new patch and new testing debs. Thanks go to all the
testers that turned up these problems.
New debs fix reported problems:
a. Six argument syscall faiulres.
b. feraiseexcept(FE_INEXACT) doesn't raise FE_INEXACT
On Fri, Oct 17, 2003 at 02:12:52PM -0400, Carlos O'Donell wrote:
Please wait 2 days before doing the upload, I am in the process
of getting other testers to make sure this release is of the
highest quality possible. If the testers do not agree with the
release quality I will request by email
On Sun, Oct 19, 2003 at 02:13:42PM -0400, Carlos O'Donell wrote:
On Fri, Oct 17, 2003 at 02:12:52PM -0400, Carlos O'Donell wrote:
Please wait 2 days before doing the upload, I am in the process
of getting other testers to make sure this release is of the
highest quality possible
On Fri, Oct 17, 2003 at 02:12:52PM -0400, Carlos O'Donell wrote:
Please wait 2 days before doing the upload, I am in the process
of getting other testers to make sure this release is of the
highest quality possible. If the testers do not agree with the
release quality I will request by email
On Sun, Oct 19, 2003 at 02:13:42PM -0400, Carlos O'Donell wrote:
On Fri, Oct 17, 2003 at 02:12:52PM -0400, Carlos O'Donell wrote:
Please wait 2 days before doing the upload, I am in the process
of getting other testers to make sure this release is of the
highest quality possible
: Related bugs:
# DP: Author: Carlos O'Donell [EMAIL PROTECTED]
# DP: Upstream status: Submitted and pending.
# DP: Status Details: Waiting on upstream to review patcfhes/
# DP: Date: 2003-10-16
if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case
I still think that skiping a supported architecture, as well as the ground
rule
about syncing everything before allowing a package to slide down to
testing, is
a REALLY bad idea, especialy for something so fundamental as glibc.
You are _so_ welcome to fix the problem. It's
I still think that skiping a supported architecture, as well as the ground rule
about syncing everything before allowing a package to slide down to testing, is
a REALLY bad idea, especialy for something so fundamental as glibc.
You are _so_ welcome to fix the problem. It's impractical to
Package: glibc
Version: 2.3.2-5
Severity: critical
Fails to build from source on hppa, and that's a good thing, if it ever
built it would be disasterous to userspace. We need to add a system by where
debian can list Allowed failures during 'make -k check' runs on the
glibc testsuite (next on my
Bah. Since you're the pretty much the most active glibc-hppa porter,
I'd do pretty much whatever you suggested for that port. That's like
suggesting that because drepper's not a DD we shouldn't follow his
advice. =) And if it weren't for me begging you to make glibc on HPPA
work, I'd be
On Fri, Jul 11, 2003 at 02:42:49PM -0700, Jeff Bailey wrote:
On Fri, Jul 11, 2003 at 04:09:34PM -0400, Carlos O'Donell wrote:
Since debian doesn't check the test-suite results for install (e.g. we
aren't at a zero error in make check poilcy), it would be suicide to
install said glibc
Bah. Since you're the pretty much the most active glibc-hppa porter,
I'd do pretty much whatever you suggested for that port. That's like
suggesting that because drepper's not a DD we shouldn't follow his
advice. =) And if it weren't for me begging you to make glibc on HPPA
work, I'd be
On Fri, Jul 11, 2003 at 02:42:49PM -0700, Jeff Bailey wrote:
On Fri, Jul 11, 2003 at 04:09:34PM -0400, Carlos O'Donell wrote:
Since debian doesn't check the test-suite results for install (e.g. we
aren't at a zero error in make check poilcy), it would be suicide to
install said glibc
these are m68k and hppa. not sure if it's an option or not. at least
for binutils glibc-2.3.1 shows failures where I see no ones with
2.2.3, is this fixed for 2.3.2?
I don't know because working m68k and hppa are not available.
I'm still working on the hppa side. It builds. And I just
BTW, what is the status for hppa? If it's not so much, I would like
to help you, AFAIC.
The problem is not an issue of development, I have all the patches
required to _build_ glibc. It's down to the nitty-gritty right now. I
need help from more eyes that know hppa assembly _well_. I'm
BTW, what is the status for hppa? If it's not so much, I would like
to help you, AFAIC.
The problem is not an issue of development, I have all the patches
required to _build_ glibc. It's down to the nitty-gritty right now. I
need help from more eyes that know hppa assembly _well_. I'm
I cheer each architecture porters to work it :-) (If not, I should
work it, well...)
Fixing Glibc is hard :)
- There is no mips/mipsel public machine. Thus I can't compile on
_all_ architectures. Sometimes I hit the problem that dchroot
environment is not well prepared (ex:
Well, this seems an idea, but still many bugs are remained in BTS.
Debian glibc stores up many bugs.
So what? As long as they're known to be fixed by 2.3.2, what's the
big deal? Stalling all of sarge for the sake of closing a bunch of
bugs in one package seems like a stunningly pyrrhic
Hackers,
The following is the set of preliminary patches allows HPPA to build a
semi-functional 32-bit GLibc (against upstream CVS head as of today).
http://www.baldric.uwo.ca/~carlos/glibc-2.3.2-patches.tar.gz
I'm almost certain that I _don't_ have the sysdep-cancel code correctly
Hackers,
The following is the set of preliminary patches allows HPPA to build a
semi-functional 32-bit GLibc (against upstream CVS head as of today).
http://www.baldric.uwo.ca/~carlos/glibc-2.3.2-patches.tar.gz
I'm almost certain that I _don't_ have the sysdep-cancel code correctly
It's ready to go out. There is no reason to stay -14.
Well, I plan to fix preinst with the suggestion of Anthony DeRobertis
[EMAIL PROTECTED] (Bug#184036), but it may be fixed in -16.
OK, I release -15 really soon.
Are you going to include the HPPA pthread patches? I haven't seen a cvs
It's ready to go out. There is no reason to stay -14.
Well, I plan to fix preinst with the suggestion of Anthony DeRobertis
[EMAIL PROTECTED] (Bug#184036), but it may be fixed in -16.
OK, I release -15 really soon.
Are you going to include the HPPA pthread patches? I haven't seen a cvs
Being perverse, I tried installing 2.3.1-5. I hit the same problem
that Joel mentioned previously, the old dynamic loader doesn't define
GLIBC_PRIVATE. I was trying to install glibc privately in a prefix of
my selection. I have been using LD_LIBRARY_PATH to select my library
path.
Next 2.3.1-15. We're making/checking libgcc-compat symbols as you
created for ppc. If the test is OK for all archs, then we will go to
2.3.2-1.
Agreed. I second this. Since 2.3.2-1 will definately FTBS for HPPA
unless I get the sysdep-cancel.h support written.
c.
--
To UNSUBSCRIBE, email
FWIW I have a list of candidates for compat symbols up now at:
http://honk.physik.uni-konstanz.de/linux-mips/glibc/compat-symbols/
I skipped ppc since this should be handeld upstream.
Regards,
-- Guido
Curious, how did you construct the list of symbols for each arch?
c.
--
To
* #173082: libnss-db_2.2-6.1(hppa/unstable): FTBFS: assumes __LT_SPINLOCK_INIT is
int
Probably a libnss-db problem. ``Conflicts: ... libnss-db (
2.2-6)'' from libc6 might be wrong; it seems like it should be
= 2.2-6 if there's been significant changes made.
I submitted
Checking for every symbol that _has_ ever leaked is the main thing,
so we can get all the broken packages rebuilt. You need that list for
glibc anyway, by the looks.
I agree, I was learning how to write lintian test for this specific
purpose. gcc leaked __clz_tab in HPPA and according to John
That's really fucking stupid. Nothing in that name indicates to me it
should be used as a predicate. And it wasn't when I originally defined
it, it was (as its name implies) the value to initialise a spinlock to.
Call it __LT_MUTEX_INITIALISER_NEEDED or __LT_SPINLOCK_INIT_P or
something.
New patches will be coming this evening to fix libnss-db.
Plunk it in at libnss-db-2.2/debian/patches/004_hppa_libc-lock.diff
- Builds libnss-db-2.2
- Haven't tested the built package, but the patch is trivial.
I'm not a DD yet so I can't push this forward, would someone please do
me the
]
* malloc/hooks.c (mem2chunk_check): Check alignment of mem
pointer, not of the computed chunk. Bug report from Carlos
O'Donell [EMAIL PROTECTED].
--- hooks.c 2002/07/11 13:45:01 1.5
+++ hooks.c 2003/01/27 10:36:11
@@ -179,8 +179,8 @@
INTERNAL_SIZE_T sz, c;
unsigned char
118 # Note that parisc64 kernel version scheme is `uname -r`-64.
119 if [ $realarch = parisc64 ]
120 then
121 kernel_ver=`uname -r`
122 if [ $ver = ${kernel_ver/pa/} ]
123 then
124 if dpkg --compare-versions
101 - 200 of 286 matches
Mail list logo
