Andreas Jochens a écrit :
Hello,
Hi,
[..]
Yes, without the /lib64 symlink the system breaks in any case because
the path to the linker /lib64/ld-linux-x86-64.so.2 - which is hardcoded
by gcc into every binary - no longer exists without the /lib64 symlink.
But I liked the fact that up to
On 06-Feb-15 12:14, Aurelien Jarno wrote:
I have just tested a build with your suggested change, and it works
correctly. Please find attached the final version of the patch, against
the latest SVN.
And the patch...
+++ debian/patches/series.amd64 (copie de travail)
@@ -1,2 +0,0
Andreas Jochens a écrit :
Hello,
Hi !
thanks for applying the patch the glibc SVN! I have a heavily used
amd64 system running with a glibc that has been built with this patch
and it works fine so far.
However, I also built an amd64 installer image with the
libc6-udeb package from the
On Wed, Feb 22, 2006 at 02:45:20PM +0100, Andreas Jochens wrote:
To fix this, I suggest to add the missing symlink /usr/lib64 - /usr/lib
to the 'libc6-udeb' package in debian/sysdeps/amd64.mk in a similar
way as it is done for the 'libc6' package.
The /lib64 - lib symlink on d-i is created
Hello,
On 06-Feb-22 20:37, Aurelien Jarno wrote:
Andreas Jochens a écrit :
This occurs because the patch changes the default library search path
of the dynamic linker from /lib /usr/lib to /lib64 /usr/lib64.
Well it's already strange it has works before. The dynamic linker path
on amd64
Hi !
On Mon, Feb 13, 2006 at 04:53:46PM +0100, Andreas Jochens wrote:
diff -u glibc-2.3.6/debian/sysdeps/amd64.mk
glibc-2.3.6/debian/sysdeps/amd64.mk
--- glibc-2.3.6/debian/sysdeps/amd64.mk
+++ glibc-2.3.6/debian/sysdeps/amd64.mk
@@ -20,0 +21,7 @@
+
+define libc_extra_install
+mv
I have just tested a build with your suggested change, and it works
correctly. Please find attached the final version of the patch, against
the latest SVN.
And the patch...
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical
On 06-Feb-13 00:54, Aurelien Jarno wrote:
Please find attached my latest version of the patch for this bug. I am
waiting for your comments.
Hello,
diff -u glibc-2.3.6/debian/sysdeps/amd64.mk
glibc-2.3.6/debian/sysdeps/amd64.mk
--- glibc-2.3.6/debian/sysdeps/amd64.mk
+++
Please find attached my latest version of the patch for this bug. I am
waiting for your comments.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-
On 06-Feb-10 12:02, Aurelien Jarno wrote:
Please find attached a patch to fix the problem using another way. It
reverts amd64-lib.dpatch, and build the library in /{usr,}/lib64. It
then moves it to /{usr,}/lib during the installation phase of the
package.
It looks cleaner to me in the sense
On Fri, Feb 10, 2006 at 12:48:21PM +0100, Andreas Jochens wrote:
your solution looks indeed nicer that the patch to the patch to fix
the linker path.
However, there is one (probably not really important) thing
which I do not like:
The patch will cause a lot of symlinks which currently
On Fri, Feb 10, 2006 at 01:06:22PM +0100, Aurelien Jarno wrote:
I think it would be good to keep it that way and to let the symlinks
point to '/lib/lib*.so.*' as they do now.
Do you perhaps know of a simple way to achive this within your approach?
I think that's possible, I'll try do
On 06-Feb-10 13:06, Aurelien Jarno wrote:
Currently, the /lib64 directory symlink is used _only_ to provide the
correct linker path. Nothing else in the distribution references
the /lib64 directory, i.e. everything is (or at least should
be) installed in /lib and nothing depends on the
Andreas Jochens a écrit :
On 06-Feb-10 13:06, Aurelien Jarno wrote:
That let me ask about having /lib64 as the real directory, and /lib as
a symlink. At least it would make the /lib64 directory compliant with
the FHS.
Do you know what kind of problem that could cause, other than a complex
On Fri, Feb 10, 2006 at 04:06:25PM +0100, Aurelien Jarno wrote:
[snip]
The FHS should be changed to allow the amd64 port to use the standard
directories (/usr)/lib for its native libraries. I filed a corresponding
request to the FHS mailing list a while ago but I did not get any answer
yet.
Hello,
On 05-Aug-28 09:02, GOTO Masanori wrote:
At Sat, 27 Aug 2005 00:07:17 +0200,
Kurt Roeckx wrote:
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2
Processing commands for [EMAIL PROTECTED]:
severity 325226 important
Bug#325226: libc6: Wrong dynamic linker on amd64.
Severity set to `important'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs
severity 325226 important
thanks
At Sat, 27 Aug 2005 00:07:17 +0200,
Kurt Roeckx wrote:
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
ldd
Package: libc6
Version: 2.3.2.ds1-22
Hi,
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
ldd /usr/bin/iconv
libc.so.6 = /lib/libc.so.6
19 matches
Mail list logo
