Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Matthias Klose wrote: > Bdale Garbee writes: > > On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: > > > > > The only change planned is to make libc6-dev-i386 and libc6-i386 provide > > > a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I > > > still have to find how to do that cleanly in the debhelper files). > > > > > > Bdale, do you agree with such a change? > > > Yes, I think we can handle that. It means some small work on ia32-libs > > to stop delivering any conflicting files, but I'm sure we can work that > > out easily enough. If you want to provide me a patch for ia32-libs that > > does what you want it to do, that would be welcome. > > thanks. with this setup we are able to build our toolchain without > build dependencies on ia32-libs or with packages conflicting with > future multiarch packages (maybe additionally building lib32z1 from > zlib). Hello, please consider to install the 32-bit files from libc6(-dev)-i386, lib32gcc1, lib32stdc++ and lib32z1 in /usr/lib32 instead of /emul/ia32-linux/usr/lib. This way the amd64 case would be handled in a similar way as the other 32/64-bit "biarch" architectures. I think that a future migration to multiarch will be easier if the amd64 case needs no special handling. Also, with /usr/lib32 there will be no need for ugly glibc debhelper file hacks as it would be for /emul/ia32-linux/usr/lib. I suggest the following setup for 32-bit libraries on amd64: 1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages. 2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib. 3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other "_amd64.deb" packages are installed in /usr/lib32 which is not a symlink but a real directory. 4. The (/usr)/lib/i486-linux-gnu directories are reserved for future multiarch installations. These changes could be implemented by simple patches without breaking existing installations. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Andreas Jochens a écrit : Matthias Klose wrote: Bdale Garbee writes: On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. thanks. with this setup we are able to build our toolchain without build dependencies on ia32-libs or with packages conflicting with future multiarch packages (maybe additionally building lib32z1 from zlib). Hello, please consider to install the 32-bit files from libc6(-dev)-i386, lib32gcc1, lib32stdc++ and lib32z1 in /usr/lib32 instead of /emul/ia32-linux/usr/lib. This way the amd64 case would be handled in a similar way as the other 32/64-bit "biarch" architectures. IMHO, I think it would be better to use (/usr)/lib32. But I won't do any change without having a mail from Steve Langasek, Matthias Klose and Bdale Garbee telling that they are ok with this change. I think that a future migration to multiarch will be easier if the amd64 case needs no special handling. Also, with /usr/lib32 there will be no need for ugly glibc debhelper file hacks as it would be for /emul/ia32-linux/usr/lib. Here is my opinion: Advantages - Coherency between ports. MIPS will use /usr/lib32 when the tri-arch patch will be finished, the unofficial ppc64 pot uses /usr/lib32. Also this is the counterpart of /usr/lib64 on other arches. - Easier for biarch package maintainers, as they don't need to do special things for amd64. This is essentially true for the glibc. - /usr/lib32 is a search path for gcc /emul/ia32-linux/usr/lib is not, that's why we currently have a symlink. Drawbacks: - We have to change. I suggest the following setup for 32-bit libraries on amd64: 1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages. That was the plan. 2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib. Removing this link render the ia32-libs-dev package unusable as /emul/ia32-linux/usr/lib is not a search path when linking libraries. 3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other "_amd64.deb" packages are installed in /usr/lib32 which is not a symlink but a real directory. Personally I feel we have to remove as much as possible libraries from ia32-libs replacing them by biarch packages, as it has been done for amd64-libs. This package is not build from sources, but uses the binaries from i386.deb files. Yes the sources are also provided in the source package, but that doesn't really help more. Imagine you want to fix something, you can't simply apply a patch to ia32-libs sources and rebuild. That's bad, and at the limit of your policy manual. Bdale, please don't take that as a personal attack. This package is really useful and also it exists! But I think we could do better. 4. The (/usr)/lib/i486-linux-gnu directories are reserved for future multiarch installations. These changes could be implemented by simple patches without breaking existing installations. Yes, they are all on http://people.debian.org/~aurel32/amd64-lib32/ for a while. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
On 06-Feb-24 12:06, Aurelien Jarno wrote: > Andreas Jochens a écrit : > >I suggest the following setup for 32-bit libraries on amd64: > > > >1. The ia32-libs package continues to install the 32-bit libraries in > >/emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) > >packages. > >2. The ia32-libs package does no longer provide a symlink from > >/usr/lib32 to /emul/ia32-linux/usr/lib. > > Removing this link render the ia32-libs-dev package unusable as > /emul/ia32-linux/usr/lib is not a search path when linking libraries. /emul/ia32-linux/usr/lib _is_ in the search path of the dynamic linker because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not necessary to run 32-bit binaries that use libraries from ia32-libs. As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs because without it 'gcc -m32' did not work correctly because it expects its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This problem with gcc will no occur in my suggested setup because of: > >3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, > >lib32z1 and other "_amd64.deb" packages are installed in > >/usr/lib32 which is not a symlink but a real directory. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Andreas Jochens a écrit :
On 06-Feb-24 12:06, Aurelien Jarno wrote:
Andreas Jochens a écrit :
I suggest the following setup for 32-bit libraries on amd64:
1. The ia32-libs package continues to install the 32-bit libraries in
/emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev)
packages.
2. The ia32-libs package does no longer provide a symlink from
/usr/lib32 to /emul/ia32-linux/usr/lib.
Removing this link render the ia32-libs-dev package unusable as
/emul/ia32-linux/usr/lib is not a search path when linking libraries.
/emul/ia32-linux/usr/lib _is_ in the search path of the dynamic linker
When I say linking, I don't speak about the dynamic linking, but the
linking that occurs when building a package with gcc.
because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by
ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not
necessary to run 32-bit binaries that use libraries from ia32-libs.
Agreed that part works. Note that I spoke about ia32-libs-dev.
As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs
because without it 'gcc -m32' did not work correctly because it expects
its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This
problem with gcc will no occur in my suggested setup because of:
It expects _all_ libraires to be there or (in /lib), not only the gcc ones:
[EMAIL PROTECTED]:/# echo 'main() {}' > test.c
[EMAIL PROTECTED]:/# gcc -m32 -o test test.c -ljpeg
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libjpeg.so when searching
for -ljpeg
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libjpeg.a when searching
for -ljpeg
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libjpeg.so when
searching for -ljpeg
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libjpeg.a when
searching for -ljpeg
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching
for -ljpeg
/usr/bin/ld: skipping incompatible /usr/lib/libjpeg.a when searching for
-ljpeg
/usr/bin/ld: cannot find -ljpeg
collect2: ld returned 1 exit status
[EMAIL PROTECTED]:/# ls /emul/ia32-linux/usr/lib/libjpe*
/emul/ia32-linux/usr/lib/libjpeg.so.62
/emul/ia32-linux/usr/lib/libjpeg.so.62.0.0
So that does not work.
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)
Hello,
On 06-Feb-24 14:04, Aurelien Jarno wrote:
> Andreas Jochens a écrit :
> When I say linking, I don't speak about the dynamic linking, but the
> linking that occurs when building a package with gcc.
>
> >because /emul/ia32-linux/usr/lib is added to /etc/ld.so.conf by
> >ia32-libs.postinst. Consequently, the symlink to /usr/lib32 is not
> >necessary to run 32-bit binaries that use libraries from ia32-libs.
>
> Agreed that part works. Note that I spoke about ia32-libs-dev.
The current ia32-libs-dev package contains basically only the 32-bit
files from the i386 libc6-dev package, i.e. it will be completely
replaced by the new libc6-dev-i386 package.
> >As far as I remember, the /usr/lib32 symlink was introduced in ia32-libs
> >because without it 'gcc -m32' did not work correctly because it expects
> >its own 32-bit libraries (e.g. libgcc*) to be in /usr/lib32. This
> >problem with gcc will no occur in my suggested setup because of:
>
> It expects _all_ libraires to be there or (in /lib), not only the gcc ones:
Yes, you are right. However, the current ia32-libs-dev package does not
contain any development libraries besides libc6-dev anyway, so no
functionality will be lost by removing the symlink from ia32-libs,
provided that all other _amd64.deb packages install their 32-bit
development libraries in /usr/lib32.
> [EMAIL PROTECTED]:/# echo 'main() {}' > test.c
> [EMAIL PROTECTED]:/# gcc -m32 -o test test.c -ljpeg
> /usr/bin/ld: cannot find -ljpeg
You will get the same result with or without the symlink, simply because
ia32-libs-dev does not contain the necessary libjpeg.so at all.
In any case, there are other reasons why the ia32-libs-dev package
setup does not allow for any serious 32-bit development (e.g. problems
with architecture specific include files). 32-bit development in the
sense of package building will require either an i386 chroot environment
or maybe in the future a full multiarch environment.
Regards
Andreas Jochens
P.S. Thank you for all your recent work on the glibc package and
especially for the recent upload of version 2.3.6-2. This new version
will make many things a lot easier, especially for amd64,
regardless which of the discussed directory setups will be chosen
finally.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350688: Patch
tag 350688 patch
thanks
The attached patch integrates Daniel's patch into the build system.
It fixes the problem on PowerPC.
--
Matt
diff -Nru gcc-2.95-2.95.4.ds15-orig/debian/patches/p-make-lang.dpatch
gcc-2.95-2.95.4.ds15/debian/patches/p-make-lang.dpatch
--- gcc-2.95-2.95.4.ds15-orig/debian/patches/p-make-lang.dpatch 1969-12-31
16:00:00.0 -0800
+++ gcc-2.95-2.95.4.ds15/debian/patches/p-make-lang.dpatch 2006-02-22
12:55:05.0 -0800
@@ -0,0 +1,56 @@
+#! /bin/sh -e
+
+# DP: Quote the arguments to sed in the Pascal Make-lang.in.
+
+if [ $# -eq 3 -a "$2" = '-d' ]; then
+pdir="-d $3"
+elif [ $# -ne 1 ]; then
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+fi
+case "$1" in
+-patch) patch $pdir -f --no-backup-if-mismatch -p0 < $0;;
+-unpatch) patch $pdir -f --no-backup-if-mismatch -R -p0 < $0;;
+*)
+ echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+ exit 1
+esac
+exit 0
+
+--- gcc/p/Make-lang.in.old 2006-01-31 12:15:09.0 +
gcc/p/Make-lang.in 2006-01-31 12:16:05.0 +
+@@ -570,20 +570,20 @@
+ # Exclude patched files from language-independent object file list.
+ # Not necessary for gcc-3 since for a library (libbackend.a), the linker does
this automatically.
+ p/stamp-gbe: stamp-objlist Makefile
+- sed -e 's: ../: :g;\
+- s: convert.o::g;\
+- s: dbxout.o::g;\
+- s: dwarf2out.o::g;\
+- s: emit-rtl.o::g;\
+- s: expr.o::g;\
+- s: fold-const.o::g;\
+- s: function.o::g;\
+- s: integrate.o::g;\
+- s: optabs.o::g;\
+- s: stmt.o::g;\
+- s: stor-layout.o::g;\
+- s: toplev.o::g;\
+- s: tree.o::g' "$<" > "$@" || { rm -f "$@"; false; }
++ sed -e 's: ../: :g;'\
++' s: convert.o::g;'\
++' s: dbxout.o::g;'\
++' s: dwarf2out.o::g;'\
++' s: emit-rtl.o::g;'\
++' s: expr.o::g;'\
++' s: fold-const.o::g;'\
++' s: function.o::g;'\
++' s: integrate.o::g;'\
++' s: optabs.o::g;'\
++' s: stmt.o::g;'\
++' s: stor-layout.o::g;'\
++' s: toplev.o::g;'\
++' s: tree.o::g' "$<" > "$@" || { rm -f "$@"; false; }
+
+ gpc1$(exeext): $(P) $(GPC_GCC_VERSION_DEPS) $(GPC_OBJS) $(LIBDEPS)
+ @grep "@@ PATCHED FOR GPC 20030218 @@" $(srcdir)/stor-layout.c >
/dev/null || \
diff -Nru gcc-2.95-2.95.4.ds15-orig/debian/rules
gcc-2.95-2.95.4.ds15/debian/rules
--- gcc-2.95-2.95.4.ds15-orig/debian/rules 2006-02-22 12:51:16.0
-0800
+++ gcc-2.95-2.95.4.ds15/debian/rules 2006-02-22 12:56:09.0 -0800
@@ -36,7 +36,7 @@
$(MAKE) -f debian/rules.conf control
touch $(control_stamp)
-configure: control $(configure_stamps)
+configure: patch $(configure_stamps)
$(configure_stamp)-%:
$(MAKE) -f debian/rules2 TARGET=$* $@
diff -Nru gcc-2.95-2.95.4.ds15-orig/debian/rules.patch
gcc-2.95-2.95.4.ds15/debian/rules.patch
--- gcc-2.95-2.95.4.ds15-orig/debian/rules.patch2006-02-22
12:51:16.0 -0800
+++ gcc-2.95-2.95.4.ds15/debian/rules.patch 2006-02-22 14:47:58.0
-0800
@@ -182,6 +182,8 @@
# conflicts with gcc-core-2.95.2-avr-1.1
#all_patches += gcc-s390
+debian_patches += p-make-lang
+
# testing only
#debian_patches := $(all_patches)
#debian_patches := $(min_patches)
signature.asc
Description: Digital signature
Processed: Patch
Processing commands for [EMAIL PROTECTED]: > tag 350688 patch Bug#350688: gcc-2.95: FTBFS with new make There were no tags set. Tags added: patch > 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]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
On Fri, Feb 24, 2006 at 07:45:16AM +0100, Christian Perrier wrote: > > After a discussion on IRC, it seems there is no consensus about how > > multiarch should be done. Therefore I stop working on that (patches are > > still welcome for glibc). > Is this really the best thing to do? > Even though there is no consensus (I overread the thread and anyway > most parts of it fly in the stratosphere from my point of view), I'm > not sure that abandoning the work is really the answer in this > situation. I didn't interpret this as "abandoning" the work. I think this is the right point to stop at on glibc right now -- we really need to have support for multiarch in dpkg an apt before usefully proceeding further. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
(restricting the CC list to real lists) Quoting Steve Langasek ([EMAIL PROTECTED]): > On Fri, Feb 24, 2006 at 07:45:16AM +0100, Christian Perrier wrote: > > > > After a discussion on IRC, it seems there is no consensus about how > > > multiarch should be done. Therefore I stop working on that (patches are > > > still welcome for glibc). > > > Is this really the best thing to do? > > > Even though there is no consensus (I overread the thread and anyway > > most parts of it fly in the stratosphere from my point of view), I'm > > not sure that abandoning the work is really the answer in this > > situation. > > I didn't interpret this as "abandoning" the work. I think this is the right > point to stop at on glibc right now -- we really need to have support for > multiarch in dpkg an apt before usefully proceeding further. OK, sorry for the confusion but I really didn't want to see Aurélien just stop this work which I'm pretty sure he's doing well. For dpkg, I think I've seen some discussion but Guillem Jover and/or Frank Lichtenheld have probably a better picture. Anyway, the dpkg development model is now pretty much opened so anyone with ideas/skills/patches can probably come up and discuss in debian-dpkg... For apt, ahem.Michael is pretty much alone doing visible development work. Some help here would probably be welcomedat least from my very far point of view. Please show up on the devel list ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
