> On Sat, Jan 24, 2004 at 09:31:37PM -0500, Jeff Bailey wrote:
> > Can you give me the steps to reproduce?
> Unpack libc6 before mawk is configured. mawk depends against libc6.
mawk is essential, you cannot unpack libc6 until mawk is working effectively.
That's what bootstrapping is all about.
On
On Sun, Feb 15, 2004 at 03:27:40PM -0500, Daniel Jacobowitz wrote:
> On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote:
> > Package: libc6
> > Version: 2.3.2.ds1-11
> >
> > It appears that, given:
> >
> > library libbar, providing version BAR1 of symbol bar_sym1;
> > library libquux,
On Sun, Feb 15, 2004 at 09:15:05PM +, Andrew Suffield wrote:
> Hmm, how about only doing this for things picked up via LD_PRELOAD?
> It's really *nasty* for regular libraries.
All I know is that I'm not touching lookup behavior with a thousand
yard stick for Debian specifically.
If you don't
On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote:
> Package: libc6
> Version: 2.3.2.ds1-11
>
> It appears that, given:
>
> library libbar, providing version BAR1 of symbol bar_sym1;
> library libquux, linked against libbar and using (version BAR1 of) bar_sym1;
> and program foo, lin
Package: libc6
Version: 2.3.2.ds1-11
It appears that, given:
library libbar, providing version BAR1 of symbol bar_sym1;
library libquux, linked against libbar and using (version BAR1 of) bar_sym1;
and program foo, linked with -rdynamic, providing unversioned symbol
bar_sym1, and dlopen()ing lib
On Sun, Feb 15, 2004 at 03:27:40PM -0500, Daniel Jacobowitz wrote:
> On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote:
> > Package: libc6
> > Version: 2.3.2.ds1-11
> >
> > It appears that, given:
> >
> > library libbar, providing version BAR1 of symbol bar_sym1;
> > library libquux,
On Sun, Feb 15, 2004 at 09:15:05PM +, Andrew Suffield wrote:
> Hmm, how about only doing this for things picked up via LD_PRELOAD?
> It's really *nasty* for regular libraries.
All I know is that I'm not touching lookup behavior with a thousand
yard stick for Debian specifically.
If you don't
On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote:
> Package: libc6
> Version: 2.3.2.ds1-11
>
> It appears that, given:
>
> library libbar, providing version BAR1 of symbol bar_sym1;
> library libquux, linked against libbar and using (version BAR1 of) bar_sym1;
> and program foo, lin
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
> I assume that all glibc headers should be compilable when using 'gcc
> -ansi'.
is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably _not_ trying
Package: libc6
Version: 2.3.2.ds1-11
It appears that, given:
library libbar, providing version BAR1 of symbol bar_sym1;
library libquux, linked against libbar and using (version BAR1 of) bar_sym1;
and program foo, linked with -rdynamic, providing unversioned symbol
bar_sym1, and dlopen()ing lib
Package: glibc
Severity: wishlist
Tags: patch l10n
Please include the attached Danish debconf translation.
# translation of da.po to Danish
# translation of glibc Debian debconf template to Danish
# Claus Hindsgaul <[EMAIL PROTECTED]>, 2004.
#
msgid ""
msgstr ""
"Project-Id-Version: da\n"
"Report
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
> I assume that all glibc headers should be compilable when using 'gcc
> -ansi'.
is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably _not_ trying
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote:
> Noticed that ksysguardd includes only to
> get PAGE_SIZE.
>
> other apps seem to use for that? Is using that
> ansi safe on all platforms?
Both are wrong. Use sysconf(_SC_PAGESIZE) instead.
Noticed that ksysguardd includes only to
get PAGE_SIZE.
other apps seem to use for that? Is using that
ansi safe on all platforms?
--
Riku Voipio|[EMAIL PROTECTED] |
kirkkonummentie 33 |+358 40 8476974 --+--
02140 Espoo|
Package: glibc
Severity: wishlist
Tags: patch l10n
Please include the attached Danish debconf translation.
# translation of da.po to Danish
# translation of glibc Debian debconf template to Danish
# Claus Hindsgaul <[EMAIL PROTECTED]>, 2004.
#
msgid ""
msgstr ""
"Project-Id-Version: da\n"
"Report
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote:
> Noticed that ksysguardd includes only to
> get PAGE_SIZE.
>
> other apps seem to use for that? Is using that
> ansi safe on all platforms?
Both are wrong. Use sysconf(_SC_PAGESIZE) instead.
--
To UNSUBSCRIBE, email to [EMAIL PR
Noticed that ksysguardd includes only to
get PAGE_SIZE.
other apps seem to use for that? Is using that
ansi safe on all platforms?
--
Riku Voipio|[EMAIL PROTECTED] |
kirkkonummentie 33 |+358 40 8476974 --+--
02140 Espoo|
Here is more info on the problem.
The issue is that 'struct user' in on s390 need 'struct
user_regs_struct' from , and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64' type
is mising is that ANS
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /* __s3
Here is more info on the problem.
The issue is that 'struct user' in on s390 need 'struct
user_regs_struct' from , and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64' type
is mising is that ANS
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and
s/390:
http://buildd.debian.org/fetch.php?&pkg=kdeadmin&ver=4%3A3.1.5-1&arch=mips&stamp=1074004757&file=log&as=raw
There is no s/390 buildd log, but the packages are on the mirrors, so
presumably someone compiled them by hand.
t
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /* __s3
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and
s/390:
http://buildd.debian.org/fetch.php?&pkg=kdeadmin&ver=4%3A3.1.5-1&arch=mips&stamp=1074004757&file=log&as=raw
There is no s/390 buildd log, but the packages are on the mirrors, so
presumably someone compiled them by hand.
t
23 matches
Mail list logo