Bug#223846: [mips/s390] FTBFS: linux/mod_devicetable.h errors - seems fixed
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and s/390: http://buildd.debian.org/fetch.php?pkg=kdeadminver=4%3A3.1.5-1arch=mipsstamp=1074004757file=logas=raw There is no s/390 buildd log, but the packages are on the mirrors, so presumably someone compiled them by hand. testing-wise, it seems only #231972 is left at the moment.. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
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 /* __s390x__ */
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
It fail to provide the type __u64 when the --ansi compile option is
used. Here is an example demonstrating the problem:
% uname -a
Linux raptor 2.4.21-debian02-1 #1 SMP Wed Jan 28 20:45:17 CET 2004
s390 GNU/Linux
% cat sys-user-test.c
#include sys/user.h
int main() { return 0; }
% gcc sys-user-test.c
% gcc -ansi sys-user-test.c
In file included from /usr/include/linux/ptrace.h:49,
from /usr/include/asm/user.h:13,
from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/ptrace.h:193: error: syntax error before __u64
/usr/include/asm/ptrace.h:199: error: syntax error before '}' token
/usr/include/asm/ptrace.h:204: error: syntax error before freg_t
/usr/include/asm/ptrace.h:448: error: syntax error before s390_fp_regs
/usr/include/asm/ptrace.h:457: error: syntax error before '}' token
In file included from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/user.h:55: error: field `regs' has incomplete type
%
I'm not sure how to best solve the problem. Changing the includes in
sys/user.h might be the best solution, but I am not sure if that is
safe to do. Building kdebase without -ansi is an option too, but not
a good one. :/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
Here is more info on the problem.
The issue is that 'struct user' in sys/user.h on s390 need 'struct
user_regs_struct' from asm/ptrace.h, 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 ANSI C do not define 'long long'. (Hm, is this fixed
in later versjons of ANSI C?). So the result is that sys/user.h is
impossible to include in a program compiled with '-ansi' on
linux/s390.
The reason this work on other archs seem to be that 'struct user' do
not depend on a 64-bit integer type on these archs.
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
It seem hard to avoid the dependency on the 64-bit value for
sys/user.h on s390. Could it be an idea to make sure there is a
64-bit type available using a packed struct?
#if !defined(__s390x__) !(defined(__GNUC__) !defined(__STRICT_ANSI__))
typedef struct {
long first_part;
long last_part;
} __u64;
#endif
This will of course break on all code _using_ variables with this
type, but might hide the problem in programs which only need a
includable sys/user.h to access the members available on all archs.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232891: glibc: Include Danish debconf translation
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-Msgid-Bugs-To: \n
POT-Creation-Date: 2003-11-01 23:07-0500\n
PO-Revision-Date: 2004-02-15 17:39+0100\n
Last-Translator: Claus Hindsgaul [EMAIL PROTECTED]\n
Language-Team: Danish [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: KBabel 1.0.2\n
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid Select locales to be generated.
msgstr Vlg sprogunderstttelser at generere.
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid
Locale is a framework to switch between multiple languages for users who can
select to use their language, country, characters, collation order, etc.
msgstr
Sprogunderstttelsen giver brugere mulighed for at skifte mellem forskellige
sprog, landeindstillinger, tegnst, sorteringsrkkeflger o.s.v.
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid
Choose which locales to generate. The selection will be saved to `/etc/
locale.gen', which you can also edit manually (you need to run `locale-gen'
afterwards).
msgstr
Vlg hvilke sprog, der skal genereres understttelse for. Valget vil blive
gemt i '/etc/locale.gen', som du ogs selv kan rette i (du skal kre
'locale-gen' bagefter).
#. Type: select
#. Choices
#: ../debhelper.in/locales.templates:14
msgid None, ${locales}
msgstr Ingen, ${locales}
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid Which locale should be the default in the system environment?
msgstr Hvilket sprogvalg skal bruges som standard?
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid
Many packages in Debian use locales to display text in the correct language
for users. You can change the default locale if you're not a native English
speaker. These choices are based on which locales you have chosen to
generate.
msgstr
Mange pakker i Debian benytter sprogvalget til at vise tekst i brugerens
eget sprog. Du kan vlge standardsproget, hvis du ikke har engelsk som
modersml. Udvalget af sprog i denne liste er baseret p dem, du har
valgt at generere.
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid
Note: This will select the language for your whole system. If you're running
a multi-user system where not all of your users speak the language of your
choice, then they will run into difficulties and you might want not to set a
default locale.
msgstr
Bemrk: Dette vil vlge sproget i hele dit system. Hvis det er et
flerbrugersystem, hvor ikke alle dine brugere taler dit sprog, kan de
lbe ind i problemer. I s tilflde br du nok ikke angive et
standardsprogvalg.
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
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'. sys/user.h 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 to write code using a plain ANSI enviroment but rather Posix, SUSv3 or some large enough subset of common unix variants. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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 libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. -- Steve Langasek postmodern programmer dlopentest.tgz Description: GNU Unix tar archive signature.asc Description: Digital signature
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. I am fairly positive that Andrew is wrong. This behavior is, for instance, one which allows LD_PRELOAD libraries to continue to work. However, there is a definite shortage of conclusive documentation. The ELF gABI does not specify. The Solaris documentation is distinctly vague on this point. Glibc says only: /* We can match the version information or use the default one if it is not hidden. */ -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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, linked against libbar and using (version BAR1 of) bar_sym1; and program foo, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. I am fairly positive that Andrew is wrong. This behavior is, for instance, one which allows LD_PRELOAD libraries to continue to work. However, there is a definite shortage of conclusive documentation. The ELF gABI does not specify. The Solaris documentation is distinctly vague on this point. Glibc says only: /* We can match the version information or use the default one if it is not hidden. */ Hmm, how about only doing this for things picked up via LD_PRELOAD? It's really *nasty* for regular libraries. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#229461: libc6 - fails to install - uses awk in preinst
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. Once you've got mawk working, you cannot unpack a new version of mawk (or gawk) until the new version of libc6 is working -- the pre-dependency from both packages on libc6 will stop you from doing that. This appears to be a bug in cdebootstrap, not in libc6. You cannot rely on dpkg while Essential packages are not configured. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Bug#223846: [mips/s390] FTBFS: linux/mod_devicetable.h errors - seems fixed
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and s/390: http://buildd.debian.org/fetch.php?pkg=kdeadminver=4%3A3.1.5-1arch=mipsstamp=1074004757file=logas=raw There is no s/390 buildd log, but the packages are on the mirrors, so presumably someone compiled them by hand. testing-wise, it seems only #231972 is left at the moment.. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
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 /* __s390x__ */
typedef __signed__ long __s64;
typedef unsigned long __u64;
#endif
It fail to provide the type __u64 when the --ansi compile option is
used. Here is an example demonstrating the problem:
% uname -a
Linux raptor 2.4.21-debian02-1 #1 SMP Wed Jan 28 20:45:17 CET 2004
s390 GNU/Linux
% cat sys-user-test.c
#include sys/user.h
int main() { return 0; }
% gcc sys-user-test.c
% gcc -ansi sys-user-test.c
In file included from /usr/include/linux/ptrace.h:49,
from /usr/include/asm/user.h:13,
from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/ptrace.h:193: error: syntax error before __u64
/usr/include/asm/ptrace.h:199: error: syntax error before '}' token
/usr/include/asm/ptrace.h:204: error: syntax error before freg_t
/usr/include/asm/ptrace.h:448: error: syntax error before s390_fp_regs
/usr/include/asm/ptrace.h:457: error: syntax error before '}' token
In file included from /usr/include/sys/user.h:22,
from sys-user-test.c:1:
/usr/include/asm/user.h:55: error: field `regs' has incomplete type
%
I'm not sure how to best solve the problem. Changing the includes in
sys/user.h might be the best solution, but I am not sure if that is
safe to do. Building kdebase without -ansi is an option too, but not
a good one. :/
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
Here is more info on the problem.
The issue is that 'struct user' in sys/user.h on s390 need 'struct
user_regs_struct' from asm/ptrace.h, 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 ANSI C do not define 'long long'. (Hm, is this fixed
in later versjons of ANSI C?). So the result is that sys/user.h is
impossible to include in a program compiled with '-ansi' on
linux/s390.
The reason this work on other archs seem to be that 'struct user' do
not depend on a 64-bit integer type on these archs.
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
It seem hard to avoid the dependency on the 64-bit value for
sys/user.h on s390. Could it be an idea to make sure there is a
64-bit type available using a packed struct?
#if !defined(__s390x__) !(defined(__GNUC__) !defined(__STRICT_ANSI__))
typedef struct {
long first_part;
long last_part;
} __u64;
#endif
This will of course break on all code _using_ variables with this
type, but might hide the problem in programs which only need a
includable sys/user.h to access the members available on all archs.
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
Noticed that ksysguardd includes sys/user.h only to get PAGE_SIZE. other apps seem to use asm/page.h for that? Is using that ansi safe on all platforms? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver |
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote: Noticed that ksysguardd includes sys/user.h only to get PAGE_SIZE. other apps seem to use asm/page.h for that? Is using that ansi safe on all platforms? Both are wrong. Use sysconf(_SC_PAGESIZE) instead.
Bug#232891: glibc: Include Danish debconf translation
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-Msgid-Bugs-To: \n
POT-Creation-Date: 2003-11-01 23:07-0500\n
PO-Revision-Date: 2004-02-15 17:39+0100\n
Last-Translator: Claus Hindsgaul [EMAIL PROTECTED]\n
Language-Team: Danish [EMAIL PROTECTED]\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: KBabel 1.0.2\n
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid Select locales to be generated.
msgstr Vlg sprogunderstttelser at generere.
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid
Locale is a framework to switch between multiple languages for users who can
select to use their language, country, characters, collation order, etc.
msgstr
Sprogunderstttelsen giver brugere mulighed for at skifte mellem forskellige
sprog, landeindstillinger, tegnst, sorteringsrkkeflger o.s.v.
#. Type: multiselect
#. Description
#: ../debhelper.in/locales.templates:4
msgid
Choose which locales to generate. The selection will be saved to `/etc/
locale.gen', which you can also edit manually (you need to run `locale-gen'
afterwards).
msgstr
Vlg hvilke sprog, der skal genereres understttelse for. Valget vil blive
gemt i '/etc/locale.gen', som du ogs selv kan rette i (du skal kre
'locale-gen' bagefter).
#. Type: select
#. Choices
#: ../debhelper.in/locales.templates:14
msgid None, ${locales}
msgstr Ingen, ${locales}
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid Which locale should be the default in the system environment?
msgstr Hvilket sprogvalg skal bruges som standard?
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid
Many packages in Debian use locales to display text in the correct language
for users. You can change the default locale if you're not a native English
speaker. These choices are based on which locales you have chosen to
generate.
msgstr
Mange pakker i Debian benytter sprogvalget til at vise tekst i brugerens
eget sprog. Du kan vlge standardsproget, hvis du ikke har engelsk som
modersml. Udvalget af sprog i denne liste er baseret p dem, du har
valgt at generere.
#. Type: select
#. Description
#: ../debhelper.in/locales.templates:16
msgid
Note: This will select the language for your whole system. If you're running
a multi-user system where not all of your users speak the language of your
choice, then they will run into difficulties and you might want not to set a
default locale.
msgstr
Bemrk: Dette vil vlge sproget i hele dit system. Hvis det er et
flerbrugersystem, hvor ikke alle dine brugere taler dit sprog, kan de
lbe ind i problemer. I s tilflde br du nok ikke angive et
standardsprogvalg.
Bug#231972: lkh: /usr/include/linux/ptrace.h buggy
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'. sys/user.h 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 to write code using a plain ANSI enviroment but rather Posix, SUSv3 or some large enough subset of common unix variants.
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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 libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. -- Steve Langasek postmodern programmer dlopentest.tgz Description: GNU Unix tar archive signature.asc Description: Digital signature
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. I am fairly positive that Andrew is wrong. This behavior is, for instance, one which allows LD_PRELOAD libraries to continue to work. However, there is a definite shortage of conclusive documentation. The ELF gABI does not specify. The Solaris documentation is distinctly vague on this point. Glibc says only: /* We can match the version information or use the default one if it is not hidden. */ -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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 like the current behavior I recommend discussing it on libc-alpha. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols
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, linked against libbar and using (version BAR1 of) bar_sym1; and program foo, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing libquux, the versioned reference to bar_sym1 from libquux will be resolved using the unversioned symbol in foo, instead of the versioned symbol in libbar. This problem also manifests if the unversioned bar_sym1 symbol is provided by a library that was dlopen()ed prior to dlopen()ing libquux; if foo is linked against libquux rather than dlopen()ing it; and, presumably, if foo is linked against both a lib (libbar0) providing the unversioned symbol and against libquux, but libbar0 is opened first. I had somehow reached the conclusion that this was documented and deliberate behavior, but Andrew Suffield [EMAIL PROTECTED] indicates otherwise and asked that I file a bug. The attached tarball contains a small test case that can be used to reproduce the problem, showing that unversioned symbols are allowed to satisfy unresolved references to versioned symbols. I am fairly positive that Andrew is wrong. This behavior is, for instance, one which allows LD_PRELOAD libraries to continue to work. However, there is a definite shortage of conclusive documentation. The ELF gABI does not specify. The Solaris documentation is distinctly vague on this point. Glibc says only: /* We can match the version information or use the default one if it is not hidden. */ Hmm, how about only doing this for things picked up via LD_PRELOAD? It's really *nasty* for regular libraries. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
