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
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
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
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
+++
Stuart Anderson writes:
On Sat, 11 Feb 2006, Aurelien Jarno wrote:
Also, I am ready to give some help there. I am first trying to build the
gcc and glibc packages on a mips, but I face a chicken and egg problem
here. Does anybody already have glibc and/or gcc packages for mips? If
not,
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]
`-
Hi,
Thiemo Seufer a écrit :
The three mips ABIs are o32 (fully 32bit), n32 (32bit address space,
64bit register width) and n64 (fully 64bit). n32 traditionally uses
(/usr)/lib32.
The general problem with this approach is that it doesn't scale beyond
2-3 ABIs, and requires a native ABI
On Sat, 11 Feb 2006, Aurelien Jarno wrote:
Also, I am ready to give some help there. I am first trying to build the
gcc and glibc packages on a mips, but I face a chicken and egg problem
here. Does anybody already have glibc and/or gcc packages for mips? If
not, what is the easiest way to
Hello,
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 it is not a patch to the patch.
Bye,
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
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
22 matches
Mail list logo