Bug#231015: libm.so: symlink should be relative
clone 231015 -1 reassign -1 debhelper retitle -1 dh_link does not work with relative symlink path tags patch thanks I cloned this bug to debhelper because it's dh_link bug. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: clone 231015 -1 Bug#231015: Bug#231015: libm.so: symlink should be absolute Bug 231015 cloned as bug 244157. reassign -1 debhelper Bug#244157: Bug#231015: libm.so: symlink should be absolute Bug reassigned from package `libc6' to `debhelper'. retitle -1 dh_link does not work with relative symlink path Bug#244157: Bug#231015: libm.so: symlink should be absolute Changed Bug title. tags patch Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
clone 231015 -1 reassign -1 debhelper retitle -1 dh_link does not work with relative symlink path tags patch thanks I cloned this bug to debhelper because it's dh_link bug. Regards, -- gotom
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: clone 231015 -1 Bug#231015: Bug#231015: libm.so: symlink should be absolute Bug 231015 cloned as bug 244157. reassign -1 debhelper Bug#244157: Bug#231015: libm.so: symlink should be absolute Bug reassigned from package `libc6' to `debhelper'. retitle -1 dh_link does not work with relative symlink path Bug#244157: Bug#231015: libm.so: symlink should be absolute Changed Bug title. tags patch Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#231015: libm.so: symlink should be relative
Joey,
This #231015 is critical bug - could you look at my last post (the
attached mail) ? I clone this bug and reassign it to debhelper
if you think it's dh_link bug.
Bug Summary: dh_link does not work for relative symlinks, and I make a
patch for fixing this problem.
Regards,
-- gotom
At Mon, 15 Mar 2004 02:19:18 +0900,
GOTO Masanori wrote:
At Mon, 15 Mar 2004 00:53:25 +0900,
GOTO Masanori wrote:
At Sun, 14 Mar 2004 12:31:37 +0900,
GOTO Masanori wrote:
Joey, please look at this patch. How to test in libc6-dev as following:
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
dh_link.new -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 18 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - /lib/libm-2.3.2.so
Umm, this patch has the bug. The resolved symlink path should be
/lib/libm.so...
The problem is that if /lib/libm.so is existed, then this path keeps
resolving to /lib/libm-2.3.2.so because readlink(2) resolves both
. and .. and symlinks. So we can't use abs_path() for this purpose.
I implement path expand routine which resolve . and .., but don't
resolve symbolic links.
This patch can handle to expand pathname even if the first character
in $src component includes `..' or `.'.
--- dh_link 2004-03-12 18:49:27.0 +0900
+++ dh_link.new 2004-03-15 02:09:35.0 +0900
@@ -78,6 +78,39 @@
init();
+# expand_path expands all path . and .. component, but don't
+# resolve symbolic links.
+sub expand_path
+{
+ my $start = @_ ? shift : '.';
+ my @pathname = split(m:/+:,$start);
+
+ my $entry;
+ my @respath;
+ foreach $entry (@pathname) {
+ if ($entry eq '.' || $entry eq '') {
+ # Do nothing
+ } elsif ($entry eq '..') {
+ if ($#respath == -1) {
+ # Do nothing
+ } else {
+ pop @respath;
+ }
+ } else {
+ push @respath, $entry;
+ }
+ }
+
+ # reconstruct full pathname
+ my $result;
+ foreach $entry (@respath) {
+ $result .= '/' . $entry;
+ }
+
+ return $result;
+}
+
+
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $file=pkgfile($package,links);
@@ -128,6 +161,9 @@
my $dest=pop @links;
my $src=pop @links;
+ # Expand . and .. in src.
+ $src=expand_path($src);
+
# Relavatize src and dest.
$src=~s:^/::;
$dest=~s:^/::;
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
./dh_link -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 12 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - /lib/libm.so
I keep testing for another path examples.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
Joey,
This #231015 is critical bug - could you look at my last post (the
attached mail) ? I clone this bug and reassign it to debhelper
if you think it's dh_link bug.
Bug Summary: dh_link does not work for relative symlinks, and I make a
patch for fixing this problem.
Regards,
-- gotom
At Mon, 15 Mar 2004 02:19:18 +0900,
GOTO Masanori wrote:
At Mon, 15 Mar 2004 00:53:25 +0900,
GOTO Masanori wrote:
At Sun, 14 Mar 2004 12:31:37 +0900,
GOTO Masanori wrote:
Joey, please look at this patch. How to test in libc6-dev as following:
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
dh_link.new -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 18 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - /lib/libm-2.3.2.so
Umm, this patch has the bug. The resolved symlink path should be
/lib/libm.so...
The problem is that if /lib/libm.so is existed, then this path keeps
resolving to /lib/libm-2.3.2.so because readlink(2) resolves both
. and .. and symlinks. So we can't use abs_path() for this purpose.
I implement path expand routine which resolve . and .., but don't
resolve symbolic links.
This patch can handle to expand pathname even if the first character
in $src component includes `..' or `.'.
--- dh_link 2004-03-12 18:49:27.0 +0900
+++ dh_link.new 2004-03-15 02:09:35.0 +0900
@@ -78,6 +78,39 @@
init();
+# expand_path expands all path . and .. component, but don't
+# resolve symbolic links.
+sub expand_path
+{
+ my $start = @_ ? shift : '.';
+ my @pathname = split(m:/+:,$start);
+
+ my $entry;
+ my @respath;
+ foreach $entry (@pathname) {
+ if ($entry eq '.' || $entry eq '') {
+ # Do nothing
+ } elsif ($entry eq '..') {
+ if ($#respath == -1) {
+ # Do nothing
+ } else {
+ pop @respath;
+ }
+ } else {
+ push @respath, $entry;
+ }
+ }
+
+ # reconstruct full pathname
+ my $result;
+ foreach $entry (@respath) {
+ $result .= '/' . $entry;
+ }
+
+ return $result;
+}
+
+
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $file=pkgfile($package,links);
@@ -128,6 +161,9 @@
my $dest=pop @links;
my $src=pop @links;
+ # Expand . and .. in src.
+ $src=expand_path($src);
+
# Relavatize src and dest.
$src=~s:^/::;
$dest=~s:^/::;
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
./dh_link -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 12 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - /lib/libm.so
I keep testing for another path examples.
Regards,
-- gotom
Bug#231015: libm.so: symlink should be relative
At Sun, 14 Mar 2004 12:31:37 +0900, GOTO Masanori wrote: Joey, please look at this patch. How to test in libc6-dev as following: ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l debian/libc6-dev/usr/lib/libm.so lrwxrwxrwx1 gotomgotom 17 2004-03-14 12:26 debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so dh_link.new -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so lrwxrwxrwx1 gotomgotom 18 2004-03-14 12:26 debian/libc6-dev/usr/lib/libm.so - /lib/libm-2.3.2.so Umm, this patch has the bug. The resolved symlink path should be /lib/libm.so... Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
At Mon, 15 Mar 2004 00:53:25 +0900,
GOTO Masanori wrote:
At Sun, 14 Mar 2004 12:31:37 +0900,
GOTO Masanori wrote:
Joey, please look at this patch. How to test in libc6-dev as following:
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
dh_link.new -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 18 2004-03-14 12:26
debian/libc6-dev/usr/lib/libm.so - /lib/libm-2.3.2.so
Umm, this patch has the bug. The resolved symlink path should be
/lib/libm.so...
The problem is that if /lib/libm.so is existed, then this path keeps
resolving to /lib/libm-2.3.2.so because readlink(2) resolves both
. and .. and symlinks. So we can't use abs_path() for this purpose.
I implement path expand routine which resolve . and .., but don't
resolve symbolic links.
This patch can handle to expand pathname even if the first character
in $src component includes `..' or `.'.
--- dh_link 2004-03-12 18:49:27.0 +0900
+++ dh_link.new 2004-03-15 02:09:35.0 +0900
@@ -78,6 +78,39 @@
init();
+# expand_path expands all path . and .. component, but don't
+# resolve symbolic links.
+sub expand_path
+{
+ my $start = @_ ? shift : '.';
+ my @pathname = split(m:/+:,$start);
+
+ my $entry;
+ my @respath;
+ foreach $entry (@pathname) {
+ if ($entry eq '.' || $entry eq '') {
+ # Do nothing
+ } elsif ($entry eq '..') {
+ if ($#respath == -1) {
+ # Do nothing
+ } else {
+ pop @respath;
+ }
+ } else {
+ push @respath, $entry;
+ }
+ }
+
+ # reconstruct full pathname
+ my $result;
+ foreach $entry (@respath) {
+ $result .= '/' . $entry;
+ }
+
+ return $result;
+}
+
+
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $file=pkgfile($package,links);
@@ -128,6 +161,9 @@
my $dest=pop @links;
my $src=pop @links;
+ # Expand . and .. in src.
+ $src=expand_path($src);
+
# Relavatize src and dest.
$src=~s:^/::;
$dest=~s:^/::;
ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l
debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 17 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - ../../lib/libm.so
./dh_link -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
lrwxrwxrwx1 gotomgotom 12 2004-03-15 02:11
debian/libc6-dev/usr/lib/libm.so - /lib/libm.so
I keep testing for another path examples.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
At Thu, 12 Feb 2004 10:13:59 +0900, GOTO Masanori wrote: At Fri, 6 Feb 2004 13:48:33 -0500, Joey Hess wrote: Jeff Bailey wrote: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. In debhelper v4 mode, dh_link does scan for existing non-policy compliant symlinks, and corrects them. That's nice. But it seems debian glibc package debian/compat=4, and rules.d/debhelper.ml has dh_link -p$(curpass). Maybe package has bug in rules. This is not dh_link issue. We don't use libc6-dev.link for /usr/lib/libm.so because ../../libm.so is generated during glibc build, and we put them to /usr/lib directly. So I think this bug is no relation to debhelper handling. I would like to put the script which I proposed and that changes ../../lib - /lib. OK? In addition, I think it's good idea to put general program which resolves from relative path to absolute path like BSD readlink -f. Unfortunatelly GNU readlink -f returns ENOENT if the real path is not existed, and realpath -s returns the same path. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
On Fri, 2004-03-12 at 05:35, GOTO Masanori wrote: But it seems debian glibc package debian/compat=4, and rules.d/debhelper.ml has dh_link -p$(curpass). Maybe package has bug in rules. This is not dh_link issue. We don't use libc6-dev.link for /usr/lib/libm.so because ../../libm.so is generated during glibc build, and we put them to /usr/lib directly. But we call dh_link anyway for that package. According to the man page, it really ought to take care of it for us. In addition, I think it's good idea to put general program which resolves from relative path to absolute path like BSD readlink -f. Unfortunatelly GNU readlink -f returns ENOENT if the real path is not existed, and realpath -s returns the same path. I don't have my posix handy - is GNU readlink buggy? Tks, Jeff Bailey -- I never know what to expect when you respond to my postings. No insult intended, you are merely a surprise :) - Carlos O'Donnell signature.asc Description: This is a digitally signed message part
Bug#231015: libm.so: symlink should be relative
At Fri, 6 Feb 2004 13:48:33 -0500, Joey Hess wrote: Jeff Bailey wrote: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. In debhelper v4 mode, dh_link does scan for existing non-policy compliant symlinks, and corrects them. That's nice. But it seems debian glibc package debian/compat=4, and rules.d/debhelper.ml has dh_link -p$(curpass). Maybe package has bug in rules. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
At Fri, 6 Feb 2004 13:48:33 -0500, Joey Hess wrote: Jeff Bailey wrote: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. In debhelper v4 mode, dh_link does scan for existing non-policy compliant symlinks, and corrects them. That's nice. But it seems debian glibc package debian/compat=4, and rules.d/debhelper.ml has dh_link -p$(curpass). Maybe package has bug in rules. Regards, -- gotom
Bug#231015: libm.so: symlink should be relative
Jeff Bailey wrote: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. In debhelper v4 mode, dh_link does scan for existing non-policy compliant symlinks, and corrects them. -- see shy jo signature.asc Description: Digital signature
Bug#231015: libm.so: symlink should be relative
Jeff Bailey wrote: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. In debhelper v4 mode, dh_link does scan for existing non-policy compliant symlinks, and corrects them. -- see shy jo signature.asc Description: Digital signature
Bug#231015: libm.so: symlink should be relative
On Thu, 2004-02-05 at 00:24, GOTO Masanori wrote: This modification is for only debian, so I plan to put special shell script path-usrlib-rel2abs.sh and use it in build.mk after installing tmp-libc as follows: Hrm.. I'd like to ask the debhelper maintainer what he thinks first - It seems to me that one of the fixups scripts (possibly dh_fixperms) should have this built in. I'm going to be late to work today, but I'll try to remember to ask joeyh when he hops on later. Tks, Jeff Bailey -- I never know what to expect when you respond to my postings. No insult intended, you are merely a surprise :) - Carlos O'Donnell signature.asc Description: This is a digitally signed message part
Bug#231015: libm.so: symlink should be relative
On Wed, Feb 04, 2004 at 12:53:40AM +0100, Yann Dirson wrote: Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. For anyone else as confused by this message as I was: the relative in the subject line should be absolute. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: retitle 231015 libm.so: symlink should be absolute Bug#231015: libm.so: symlink should be relative Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
On Wed, Feb 04, 2004 at 09:46:51AM -0500, Daniel Jacobowitz wrote: For anyone else as confused by this message as I was: the relative in the subject line should be absolute. Thanks for pointing that out Daniel - let's blame the lack of sleep, as usual :) -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
At Wed, 4 Feb 2004 00:53:40 +0100, Yann Dirson wrote: policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. Exactly. This modification is for only debian, so I plan to put special shell script path-usrlib-rel2abs.sh and use it in build.mk after installing tmp-libc as follows: for file in $1/* do if [ -L $file ]; then newfile=`readlink $file | sed 's/\.\.\/\.\.\/lib/\/lib/'` ln -sf $newfile $file fi done debian-glibc guys, OK to commit? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
On Wed, Feb 04, 2004 at 12:53:40AM +0100, Yann Dirson wrote: Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. For anyone else as confused by this message as I was: the relative in the subject line should be absolute. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: retitle 231015 libm.so: symlink should be absolute Bug#231015: libm.so: symlink should be relative Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#231015: libm.so: symlink should be relative
On Wed, Feb 04, 2004 at 09:46:51AM -0500, Daniel Jacobowitz wrote: For anyone else as confused by this message as I was: the relative in the subject line should be absolute. Thanks for pointing that out Daniel - let's blame the lack of sleep, as usual :) -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Bug#231015: libm.so: symlink should be relative
At Wed, 4 Feb 2004 00:53:40 +0100, Yann Dirson wrote: policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. Exactly. This modification is for only debian, so I plan to put special shell script path-usrlib-rel2abs.sh and use it in build.mk after installing tmp-libc as follows: for file in $1/* do if [ -L $file ]; then newfile=`readlink $file | sed 's/\.\.\/\.\.\/lib/\/lib/'` ln -sf $newfile $file fi done debian-glibc guys, OK to commit? Regards, -- gotom
Bug#231015: libm.so: symlink should be relative
Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux bylbo 2.4.23-k6+preempt+acl #1 sam déc 13 00:48:10 CET 2003 i586 Locale: LANG=français, LC_CTYPE=français Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
severity 231015 important thanks Yann Dirson [EMAIL PROTECTED] writes: Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. should != serious. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: severity 231015 important Bug#231015: libm.so: symlink should be relative Severity set to `important'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231015: libm.so: symlink should be relative
Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. This allows me to have /usr being a symlink to a non-top-level dir, and having libm.so using a relative symlink breaks. This in turn causes gcc to pick libm.a since it can't open libm.so, and since libm.a requires libc.a as opposed to libc.so, I cannot link any program against libm. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux bylbo 2.4.23-k6+preempt+acl #1 sam déc 13 00:48:10 CET 2003 i586 Locale: LANG=français, LC_CTYPE=français Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Bug#231015: libm.so: symlink should be relative
severity 231015 important thanks Yann Dirson [EMAIL PROTECTED] writes: Package: libc6 Version: 2.3.2.ds1-11 Severity: serious policy 10.5 says: [...] symbolic links pointing from one top-level directory into another should be absolute. should != serious. -- James
Processed: Re: Bug#231015: libm.so: symlink should be relative
Processing commands for [EMAIL PROTECTED]: severity 231015 important Bug#231015: libm.so: symlink should be relative Severity set to `important'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
