Re: help needed for defining hppa __clz_tab gcc-compat symbol
Hi, On Sun, Mar 02, 2003 at 11:01:41AM +0900, GOTO Masanori wrote: It's my concern. We're adding much symbols - my concern is (1) the script can't catch like this case, (2) your listed symbols are really needed for libgcc-compat. Yes, apparently libgcc-compat is needed, but I wonder such a lot of symbols are really needed. What do you think? Adding too many symbols won't do much harm since programs compiled for sarge won't use them - we shouldn't add unnecessary cruft though. We we should ask the port maintainers to check which symbols are unnecessary when we have the patches for all archs together. BTW, I've finished to make compat symbols for alpha, arm, ia64, m68k, and s390. After some more tests, I send it to this list. I added alpha and cleaned up mips a bit (removing two unneeded symbols), it passes all the tests (although I had to increase the timeout for test-lfs on escher, but I don't think that's related). Regards, -- Guido P.S.: many thanks to Ryan and Joey for their very quick responses to my debian-admin questions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.1-14
On Sun, Mar 02, 2003 at 09:08:57PM +0900, GOTO Masanori wrote:
OK, I review your patch, and found that:
1. mips part should declare extern float __floatdisf
2. alpha part lacks Makefile and Versions files.
3. ia64 part does not declare __divsi3 __modsi3 __udivsi3
__umodsi3. other declarations (__ia64_save_stack_nonlocal,
etc.) are not needed, I post it later.
When did you grab that? I updated the patch just before announcing it to
the list. It fixes 1 2 and removes ia64 since you said you'll handle
that.
I fixed 1/2. compilation is succeeded on both ia64 and alpha.
Changed files are sysdeps/alpha/Dist, sysdeps/alpha/Makefile,
sysdeps/mips/libgcc-compat.c. I put fixed version at:
http://megaela.gotom.jp/~gotom/patch/debian/glibc/libgcc-compat-all.dpatch
I would like to commit it, so could you review and update it?
You have:
+extern floatdisf (int64_t);
in the mips part but it should be:
+extern float floatdisf (int64_t);
I wonder why the Redhat glibc removes all the assembly and uses C
functions instead. Any ideas?
BTW, IA64 missing symbols (__divsi3 __modsi3 __udivsi3 __umodsi3)
can be resolved like:
extern long __divsi3 (long, long) attribute_hidden;
long INTUSE (__divsi3) (long x, long y)
{
return __divsi3 (x, y);
}
symbol_version (INTUSE (__divdi3), __divdi3, GLIBC_2.2);
I don't add them yet, but should we add?
I'd rather use something like int64_t instead of long like we do for the
other archs but that's cosmetics.
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183112: libc6-dev: Missing prototypes for new resolver funcs from netdb.h
Package: libc6-dev
Version: 2.3.1-9
Severity: important
Tags: patch
Missing prototypes for the following new resolver functions from netdb.h
However, they are documented in the corresponding man pages.
- getipnodebyname
- getipnodebyaddr
- freehostent
solved by including this in netdb.h:
--
extern C
{
struct hostent *getipnodebyname(const char *name,
int af, int flags, int *error_num);
struct hostent *getipnodebyaddr(const void *addr,
size_t len, int af, int *error_num);
void freehostent(struct hostent *ip);
}
--
Thanks.
J.L.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux DarkCube 2.4.19-lvm1.0.5-reiserquota #1 Wed Oct 23 12:02:14 CEST 2002
i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libc6-dev depends on:
ii libc6 2.3.1-9GNU C Library: Shared libraries an
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.1-14
On Sun, Mar 02, 2003 at 10:21:31PM +0900, GOTO Masanori wrote:
I prepared for you and debian-glibc yesterday about my patch:
OK, for ia64, I'm preparing it.
Great!
[..snip..]
I wonder why the Redhat glibc removes all the assembly and uses C
functions instead. Any ideas?
BTW, IA64 missing symbols (__divsi3 __modsi3 __udivsi3 __umodsi3)
can be resolved like:
extern long __divsi3 (long, long) attribute_hidden;
long INTUSE (__divsi3) (long x, long y)
{
return __divsi3 (x, y);
}
symbol_version (INTUSE (__divdi3), __divdi3, GLIBC_2.2);
I don't add them yet, but should we add?
I'd rather use something like int64_t instead of long like we do for the
other archs but that's cosmetics.
Thanks, please do like int64_t. BTW, is not attribute_hidden part
necessary?
It's trying to make sure we get the right __divsi3 in case there are
other 'not hidden' definitions. Ia64 does in Redhats glibc that, ppc32
doesn't.
Regards,
-- Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: next glibc release
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 to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: libc.so.6 has static non-PIC code linked in
I can confirm now that glibc 2.3.2 eliminates the TEXTREL that shows up in recent (since at least 2.3.1-12?) glibc builds in libc.so.6 on ppc sid. Using the current debian glibc 2.3.1-14 packaging and patches with the release 2.3.2 tarballs I get a libc.so.6 that no longer shows a TEXTREL using... objdump --all-headers ./libc.so.6 | grep TEXTREL This fix doesn't appear to be related to changes in the devtools since the same debian ppc sid machine shows a TEXTREL in libc.so.6 when rebuilding the current glibc-2.3.1-14 package. Oh, for my glibc-2.3.2 test debian packages I disabled the following patches because they were merged into upstream... cvs glibc23-00-hppa-pthreads signal-texi glibc23-ia64-strncpy glibc23-getdents64-fix glibc23-getaddrinfo glibc23-hppa-shmlba document-fix glibc23-regcomp glibc23-malloc-check The following patches weren't included in my build but need adjustment for 2.3.2... glibc23-hppa-Rminkernel alpha-pic libgcc-compat-all Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183139: libc-udeb: Should be renamed to libc6-udeb
Package: libc-udeb Version: unavailable; reported 2003-03-02 Severity: normal On the next soname change all udebs relying on libc-udeb are about to break. Until they are rebuilded, net installs will not be possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183143: libc-udeb: Should provide libc6
Package: libc-udeb Version: unavailable; reported 2003-03-02 Severity: normal Together with the packagename change this will allow other udebs to just use dh_shlibdeps to determine their dependencies, because the shlibs file for glibc of course ponts to libc6. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183143: libc-udeb: Should provide libc6
On Sun, Mar 02, 2003 at 08:06:12PM +0100, Sebastian Ley wrote: Package: libc-udeb Version: unavailable; reported 2003-03-02 Severity: normal Together with the packagename change this will allow other udebs to just use dh_shlibdeps to determine their dependencies, because the shlibs file for glibc of course ponts to libc6. Hell no. This would cause than a fair share of problem. All deps on libc6 are versioned and versioned provides are non-existent. So it wouldn't even work. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ 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#183081: libc6-dev: hppa: bug in byteorder.h and swab.h
Stephen Gran [EMAIL PROTECTED] wrote:
Ah, I see that now. I checked with dpkg -S, but didn't look further.
Because of what appear to be largely syntactic errors in these two
headers, the build failed, but only on hppa. I guess this needs to be
reassigned to the kernel. Sorry about that.
No you should close this. User space programs must not include kernel
headers.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183143: libc-udeb: Should provide libc6
* Ben Collins wrote: Hell no. This would cause than a fair share of problem. All deps on libc6 are versioned and versioned provides are non-existent. So it wouldn't even work. I discussed this issue with Martin Sjögren, and he stated that udpkg just does not parse the version information. So it will do no harm if they are present. Naming library udebs libfooN-udeb (with N = noname number) and providing the original name of the corresponding deb packe in the Provides field should enable all packagers to use the dh_shlibdeps determine their dependancies. If I miss something please provide me with further information. The alternative would be to declare dependancies manually. -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183081: libc6-dev: hppa: bug in byteorder.h and swab.h
On Mon, Mar 03, 2003 at 07:30:15AM +1100, Herbert Xu said: Stephen Gran [EMAIL PROTECTED] wrote: Ah, I see that now. I checked with dpkg -S, but didn't look further. Because of what appear to be largely syntactic errors in these two headers, the build failed, but only on hppa. I guess this needs to be reassigned to the kernel. Sorry about that. No you should close this. User space programs must not include kernel headers. I'm happy to close it here, but it's not the user space program explicitly including these headers - they're being brought in by recursive #includes: In file included from /usr/include/linux/cdrom.h:14, from audiocd.h:33, from cddbaccessdialog.h:31, from cddbaccessdialogdata.cpp:10: /usr/include/asm/byteorder.h: cddbaccessdialogdata.cpp includes cddbaccessdialog.h, which includes audiocd.h, and so forth until /usr/include/asm/byteorder.h is finally brought in. It's not an error in this program, and it builds fine on other architectures - there's clearly some problem with the headers on hppa. It's only that the headers do not come from your package (although dpkg -S reported tat they did), and so I apologize for bugging the wrong package. I will close this. -- -- | Stephen Gran | This is a good time to punt work. | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgp0.pgp Description: PGP signature
Bug#183081: marked as done (libc6-dev: hppa: bug in byteorder.h and swab.h)
Your message dated Sun, 2 Mar 2003 15:47:39 -0500
with message-id [EMAIL PROTECTED]
and subject line bug in kernel, not libc6-dev
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 2 Mar 2003 06:05:10 +
From [EMAIL PROTECTED] Sun Mar 02 00:05:09 2003
Return-path: [EMAIL PROTECTED]
Received: from adsl-216-158-52-98.cust.oldcity.dca.net (mail.lobefin.net)
[216.158.52.98]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18pMaz-0004WY-00; Sun, 02 Mar 2003 00:05:09 -0600
Received: from adsl-216-158-52-108.cust.oldcity.dca.net ([216.158.52.108]
helo=busybox.lobefin.net)
by mail.lobefin.net with asmtp (Exim 3.35 #1 (Debian))
id 18pMaU-00043F-00; Sun, 02 Mar 2003 01:04:38 -0500
Received: from steve by busybox.lobefin.net with local (Exim 3.36 #1 (Debian))
id 18pMYc-0001MQ-00; Sun, 02 Mar 2003 01:02:42 -0500
From: Stephen Gran [EMAIL PROTECTED]
Subject: libc6-dev: hppa: bug in byteorder.h and swab.h
To: [EMAIL PROTECTED]
X-Mailer: bug 3.3.10.2
Message-Id: [EMAIL PROTECTED]
Sender: Stephen Gran [EMAIL PROTECTED]
Date: Sun, 02 Mar 2003 01:02:42 -0500
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-0.2 required=4.0
tests=HAS_PACKAGE,SPAM_PHRASE_00_01
version=2.44
X-Spam-Level:
Package: libc6-dev
Version: 2.3.1-14
Severity: normal
I noticed this problem when the autobuilding of one of my packages failed:
In file included from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/asm/byteorder.h:43: syntax error before `(' token
/usr/include/asm/byteorder.h:46: `x' was not declared in this scope
/usr/include/asm/byteorder.h:47: `t1' was not declared in this scope
/usr/include/asm/byteorder.h:47: `int ___arch__swab32' redeclared as different
kind of symbol
/usr/include/asm/byteorder.h:9: previous declaration of `const __u32
___arch__swab32(unsigned int)'
/usr/include/asm/byteorder.h:48: redefinition of `int ___arch__swab32'
/usr/include/asm/byteorder.h:47: `int ___arch__swab32' previously defined here
/usr/include/asm/byteorder.h:49: syntax error before `return'
In file included from /usr/include/linux/byteorder/big_endian.h:11,
from /usr/include/asm/byteorder.h:73,
from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/linux/byteorder/swab.h: In function `const __u32
__fswab32(unsigned int)':
/usr/include/linux/byteorder/swab.h:146: `___arch__swab32' cannot be used as a
function
/usr/include/linux/byteorder/swab.h: In function `__u32 __swab32p(__u32*)':
/usr/include/linux/byteorder/swab.h:150: `___arch__swab32' cannot be used as a
function
/usr/include/linux/byteorder/swab.h: In function `void __swab32s(__u32*)':
/usr/include/linux/byteorder/swab.h:154: `___arch__swab32' cannot be used as a
function
Full build log is at:
http://buildd.debian.org/fetch.php?pkg=kcdlabelver=2.11-KDE3-1arch=hppastamp=1046564305file=logas=raw
-- System Information:
Debian Release: testing/unstable
Kernel Version: Linux paer 2.4.19-64 #1 Fri Nov 22 23:59:56 MST 2002 parisc64 unknown
unknown GNU/Linux
Versions of the packages libc6 depends on:
hi libc6 2.3.1-14GNU C Library: Shared libraries and Timezone data
---
Received: (at 183081-done) by bugs.debian.org; 2 Mar 2003 20:47:58 +
From [EMAIL PROTECTED] Sun Mar 02 14:47:58 2003
Return-path: [EMAIL PROTECTED]
Received: from adsl-216-158-52-98.cust.oldcity.dca.net (mail.lobefin.net)
[216.158.52.98]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18paNJ-00011d-00; Sun, 02 Mar 2003 14:47:57 -0600
Received: from adsl-216-158-52-108.cust.oldcity.dca.net ([216.158.52.108]
helo=gashuffer.lobefin.net)
by mail.lobefin.net with asmtp (Exim 3.35 #1 (Debian))
id 18paMp-00071j-00
for [EMAIL PROTECTED]; Sun, 02 Mar 2003 15:47:27 -0500
Received: from steve by gashuffer.lobefin.net with local (Exim 3.36 #1 (Debian))
id 18paN1-0005pQ-00
for [EMAIL PROTECTED]; Sun, 02 Mar 2003 15:47:39 -0500
Date: Sun, 2 Mar 2003 15:47:39 -0500
From: Stephen Gran [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: bug in kernel, not libc6-dev
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Bug#183155: libc-udeb: libpthread is needed for the gtk-frontend
Package: libc-udeb Version: unavailable; reported 2003-03-02 Severity: normal GTK and libdirectfb link against libpthread, so we need libpthread in the libc udeb. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to glibc-package/debian/locales/DEBIAN by gotom
On Thu, Feb 27, 2003 at 10:28:51PM +0900, GOTO Masanori wrote: [...] Thanks! I followed your suggestion. I've just commited into cvs. A last word about it. Could you please move debian/locales/DEBIAN/po/ into debian/po/ ? The reason is that po-debconf is designed so that all translatable strings are gathered inside a single PO file per language (to help translators), and http://www.debian.org/intl/l10n/po-debconf/ only lists source packages shipping a debian/po/templates.pot file. If you accept to do so, you must edit POTFILES.in and replace templates by locales/DEBIAN/templates, and that's all. When other templates files are needed (in locales or any other binary package), you add a line in POTFILES.in for each templates file and run debconf-updatepo, then PO files are updated and contain all translatable strings. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183155: libc-udeb: libpthread is needed for the gtk-frontend
On Sun, Mar 02, 2003 at 10:41:18PM +0100, Sebastian Ley wrote: Package: libc-udeb Version: unavailable; reported 2003-03-02 Severity: normal GTK and libdirectfb link against libpthread, so we need libpthread in the libc udeb. Whoa now. That seems like the wrong way to go. Why can't you build them without threading support? If you're going to put LinuxThreads in the udeb, you might as well just use libc. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.1-14
On Sun, Mar 02, 2003 at 12:51:04AM +0900, GOTO Masanori wrote:
Yes, /bin/sh example makes sense. Binaries contained in bash and
libc6 and sysvinit should exist at the same time. This bootstraping
problem lies all over the essential packages.
Yup.
BTW, postinst has another file-rc checking:
check=$check inetd
rl=$(runlevel | awk '{print $2}')
for service in $check; do
if [ -f /usr/share/file-rc/rc -a -f /etc/runlevel.conf ]; then
idl=$(filerc $rl $service)
else
idl=$(ls /etc/rc${rl}.d/S??${service} 2 /dev/null | head -1)
fi
This place is changed simply as checking -f /usr/{share,lib}/file-rc/rc.
Yick. You might be able to use invoke-rc.d here instead? You'll probably
end up with circular dependencies on upgrades then though :(
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
pgp0.pgp
Description: PGP signature
Re: [PATCH] Update HPPA LinuxThread implementation and remove old .dpatch's
At Sun, 2 Mar 2003 11:48:16 -0500, Carlos O'Donell wrote: With regards to GNU/Libc 2.3.x The following is an update of LinuxThreads for HPPA, the changelog is in progress and it has shown no regressions from a testing standpoint. It actually does better in the gcc/g++ testsuite. This work represents some long discussions between John David Anglin and myself, please read the dpatch for more information about a specific patch. Please remove the following .dpatch files from debian-glibc's CVS: glibc23-02-hppa-min-kern-unwind-fde.dpatch glibc23-03-hppa-mcontext.dpatch glibc23-04-hppa-fcntl64.dpatch glibc23-05-hppa-buildhack.dpatch glibc23-06-hppa-tests.dpatch glibc23-08-hppa-configure.dpatch They are no longer being used and were superceeded by CVS patches. Please replace glibc23-00-hppa-pthreads.dpatch with the attached version. Please add glibc23-hppa-malloc-align.dpatch to the list of HPPA patches. Quick Summary: - LinuxThreads is now using a self-aligning lock. - Malloc alignment has been moved back to 8 for optimal performance. I did this work over 2-3 weeks ago, but due to current time constraints it was behind libgcc-compat hppa on the queue, and thus didn't get out. Randolph Chung recently fixed hppa's __clz_tab libgcc-compat issue, which means I can take the 5 minutes I need to send this email :) This code has been heavily tested by John and myself, though should any HPPA users find problems, or have comments, please file bugs and/or contact me direclty or via any of the lists :) Excellent :) Thanks, but should it apply in 2.3.1-15? I would like to delay to apply it in 2.3.2-1. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100986: libc6-dev: Additional missing manpages
At Sun, 02 Mar 2003 14:56:33 +0100, Jose Luis Tallon wrote: Package: libc6-dev Version: 2.3.1-9 Followup-For: Bug #100986 Additional missing manpages: cap_set_proc(3) / cap_get_proc(3) , capsetp(3) / capgetp(3) However, the raw funcs in section 2, capget / capset are documented. You misunderstand #100986. #100986 says /usr/bin/gencat is existed, but manual is not existed. It's not API issue but binary manpages. You report this kind of bug to manpages-dev. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
