I added multilib support to the following packages. Thereby, the basic multilib environment can be made. * sys-devel/gcc/gcc-3.4.4 * sys-libs/glibc/glibc-2.3.4.20041102-r1 * linux-headers/linux-headers-2.6.11 I want to merge these into portage tree in several days. If it is a problem, please let me know. Moreover, please see the following URL for details. http://dev.gentoo.org/~nigoro/ppc64/multilib/ Thanks!
Created attachment 62025 [details, diff] patch for toolchain.eclass This patch adds multilib support to GCC.
Created attachment 62026 [details, diff] patch for glibc-2.3.4.20041102-r1.ebuild This patch adds multilib support to glibc. [memo] glibc-2.3.5 seems to have a problem on PPC64. So, I added multilib support to glibc-2.3.4.20041102-r1.
Created attachment 62027 [details, diff] patch for kernel-2.eclass This patch adds multilib support to linux-headers.
And, I committed the profile which supported multilib. /usr/portage/profiles/default-linux/ppc64/dev/multilib
amd64 herds, I changed your code in some parts in patches. I am sorry to trouble you, but could you check whether the problem is contained in it ?
cc'ing eradicator, he's written most of the multilib stuff
(In reply to comment #5) > amd64 herds, > > I changed your code in some parts in patches. > I am sorry to trouble you, but could you check whether the problem is contained > in it ? This all looks good to me. What problem are you refering to?
kugelfang, Thanks for your advice. The problem which I pointed out is a mistake in conditional branch or multilib support code, for example. Since these packages were core packages, especially I thought before the commitment that a check was required. Next, I want to commit these. May I commit these ? Or should I assign someone to a fit person ? Thank you.
toolchain herds, I want these patches to be merged into Portage tree for the multilib support on ppc64. Would you check my code and merge into Portage tree ? [NOTE] kernel-2.eclass was already merged by dostrow.
the CHOST/CBUILD stuff you do in the glibc ebuild is incorrect... I know you think it's right as I originally made the same assumptions, but read the documentation at the top of the ebuild from vapier about it... it has to do with the way crossdev is setup. Also, I'll review these more thuroughly tomorrow...
this hunk against toolchain.eclass is wrong: - [[ $(tc-arch) == "amd64" && -z ${SKIP_MULTILIB_HACK} ]] ; then + [[ $(tc-arch) == "amd64" || $(tc-arch) == "ppc64" && -z ${SKIP_MULTILIB_HACK} ]] ; then
Created attachment 62513 [details, diff] toolchain.eclass.patch Here's a slightly updated toolchain.eclass.patch that I'll apply after testing... but please make any glibc.eclass changes agains 2.3.5
rrr... I meant to say glibc.ebuild changes... not eclass... 2.3.5 is much different than 2.3.4.20041102 in that I basically rewrote all the code to handle multilib configurations and made it much more abstract... so it might "just work" for you... the only problem might be bootstrapping. You might need to provide a 32bit glibc tarball to bootstrap the process much like amd64 does in our upgrade script to 2005.0 (but we use the emul-x86-glibc package for this purpose.
Created attachment 62755 [details, diff] patch for glibc-2.3.4.20041102-r1.ebuild glibc-2.3.5 seem to have a problem on ppc. So, I stick to this version. Please see Bug #92794 for details. BTW, I did not add emul-linux-ppc-glibc like amd64 to PDEPEND. Is it satisfactory if I write an upgrade document ? Or is it better to add this ? If it is necessary to add to PDEPEND, I will need to change some profiles. Thank you.
Created attachment 62756 [details, diff] FYI, glibc-2.3.5.ebuild.patch [NOTE] I have not fully tested this yet.
Created attachment 62757 [details] new ebuild: app-emulation/emul-linux-ppc-glibc-2.3.4.20041102-r1.ebuild
Created attachment 62760 [details] metadata.xml for emul-linux-ppc-glibc
My upgrade method from 2005.0 # First, change into multilib profile. # It is required in order to apply, when CFLAGS_ppc compiles gcc etc. rm /etc/make.profile ln -s /usr/portage/profiles/default- linux/ppc/2005.1/ppc64/multilib /etc/make.profile echo "app-emulation/emul-linux-ppc-glibc ~ppc64" >> /etc/portage/package.keywords emerge -v --oneshot '<=emul-linux-ppc-glibc-2.3.4.20041102-r1' emerge -v --oneshot '>=sys-devel/binutils-2.15.90.0.3-r4' FEATURES=-sandbox emerge gcc emerge -v --oneshot '>=sys-apps/portage-2.0.51-r9' emerge -v --oneshot '>=sys-devel/gcc-config-1.3.9' emerge -v --oneshot '>=linux-headers-2.6.11' rm /lib32 /usr/lib32 mkdir /lib32 /usr/lib32 cp /emul/linux/ppc/lib32/libsandbox.so /usr/lib32 cp /emul/linux/ppc/usr/lib32/libc.so /usr/lib32 cp /emul/linux/ppc/usr/lib32/libpthread.so /usr/lib32 cp /emul/linux/ppc/usr/lib32/*crt*.o /usr/lib32 env-update emerge -v --oneshot baselayout emerge -v --oneshot '>=sys-libs/glibc-2.3.4.20041102-r1' emerge unmerge emul-linux-ppc-glibc
Created attachment 62762 [details, diff] patch for glibc-2.3.4.20041102-r1.ebuild my bad...
We want to provide stages which supported multilib at 2005.1. Would you merge the following, if there is no big problem in parts other than upgrade support ? * toolchain.eclass.patch (Attachment #62513 [details, diff]) * patch for glibc-2.3.4.20041102-r1.ebuild (Attachment #62762 [details, diff]) * app-emulation/emul-linux-ppc-glibc-2.3.4.20041102-r1.ebuild (Attachment #62757 [details]) Thank you.
(In reply to comment #18) Update my upgrade method from 2005.0 # First, change into 64bit-userland profile for fix_lib64_symlinks. rm /etc/make.profile ln -s /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/64bit- userland /etc/make.profile emerge glibc # Next, change into multilib profile. # It is required in order to apply, when CFLAGS_ppc compiles gcc etc. rm /etc/make.profile ln -s /usr/portage/profiles/default- linux/ppc/2005.1/ppc64/multilib /etc/make.profile [snip]
Created attachment 62861 [details] glibc-2.3.4.20041102-r2.ebuild based on 2.3.5 ebuild
Created attachment 62862 [details] Difference of 2.3.5 to 2.3.4.20041102-r2
glibc-2.3.4-patches-0.1.tar.bz2 is here. http://dev.gentoo.org/~nigoro/ppc64/glibc/glibc-2.3.4-patches-0.1.tar.bz2 files list. patches/1000_all_2.3.4-fedora-branch-no-libnoversion.patch patches/1010_all_2.3.4-fedora-branch-no-force-nontls.patch patches/2000_all_2.3.2-propolice-guard-functions-v3.patch patches/2010_all_2.3.3-frandom-detect.patch patches/3000_all_2.3.4-dl_execstack-PaX-support.patch patches/3010_all_2.3.3_pre20040117-pt_pax.patch patches/3020_all_2.3.4.20040808-i386-got-fix.patch patches/3040_all_glibc-sec-hotfix-20040916.patch patches/4000_all_2.3.4-hardened-sysdep-shared.patch patches/5000_all_2.3.4-mdns-resolver-20041102.patch patches/5010_all_2.3.4-features-header-fix.patch patches/5020_all_nomalloccheck.patch patches/5060_all_2.3.4-fix-_dl_next_tls_modid-assert.patch
(In reply to comment #22) > Created an attachment (id=62861) [edit] > glibc-2.3.4.20041102-r2.ebuild > based on 2.3.5 ebuild ug... It seems that upgrade support of my new ebuild has broken. <snip> --- !targe sym /usr/lib64/libthread_db.so --- !targe sym /usr/lib64/libbsd.a --- !targe sym /lib64/libthread_db.so.1 --- !targe sym /lib64/libpthread.so.0 Traceback (most recent call last): File "/usr/bin/emerge", line 3074, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 1903, in merge retval=unmerge("clean", [xsplit[0]]) File "/usr/bin/emerge", line 2188, in unmerge retval=portage.unmerge(mysplit[0],mysplit [1],portage.root,mysettings,unmerge_action not in ["clean","prune"]) File "/usr/lib/portage/pym/portage.py", line 2828, in unmerge mylink.unmerge(trimworld=mytrimworld,cleanup=1) File "/usr/lib/portage/pym/portage.py", line 6281, in unmerge a=doebuild (myebuildpath,"postrm",self.myroot,self.settings,use_cache=0,tree="vartree") File "/usr/lib/portage/pym/portage.py", line 2542, in doebuild return spawn (EBUILD_SH_BINARY+" "+mydo,mysettings,debug=debug,free=1,logfile=logfile) File "/usr/lib/portage/pym/portage.py", line 1567, in spawn return portage_exec.spawn_bash(mystring,env=env,**keywords) File "/usr/lib/portage/pym/portage_exec.py", line 46, in spawn_bash return spawn(args,env=env,opt_name=opt_name,**keywords) File "/usr/lib/portage/pym/portage_exec.py", line 160, in spawn raise str(e)+":\n "+myc+" "+string.join(myargs) [Errno 2] No such file or directory: /bin/bash [glibc-2.3.4.20041102-r1] bash -c /usr/lib/portage/bin/ebuild.sh postrm !!! FAILED postrm: 1 </snip>
Created attachment 63022 [details] new ebuild: glibc-2.3.4.20041102-r2.ebuild fixes problem of comment #25 and some minor problems. I did the basic test to this ebuild. * Merge in the environment of 2005.0 * Upgrade to multilib environment from no-multilib profile It seems to operate appropriately. Would you check this ebuild ? After it was checked by you, we will do a more detailed test.
Created attachment 63023 [details] Difference of 2.3.5 to 2.3.4.20041102-r2
( use amd64 || use ppc64 ) should be { use amd64 || use ppc64 } Also, when youu commit the ebuild, you might also want to merge these hunks into the 2.3.5 and 2.3.5.XXX ebuild: @@ -274,7 +294,7 @@ # 2005.0 is setup properly, and this is executed as part of the # 2004.3 -> 2005.0 upgrade script. # It can be removed after 2004.3 has been purged from portage. - use amd64 && [ "$(get_libdir)" == "lib64" ] && ! has_multilib_profile && fix_lib64_symlinks + ( use amd64 || use ppc64 ) && [ "$(get_libdir)" == "lib64" ] && ! has_multilib_profile && fix_lib64_symlinks # it appears that /lib/tls is sometimes not removed. See bug # 69258 for more info. @@ -942,7 +963,8 @@ rm ${ROOT}/lib64 # now that lib64 is gone, nothing will run without calling ld.so # directly. luckily the window of brokenness is almost non-existant - /lib/ld-linux-x86-64.so.2 /bin/mv ${ROOT}/lib ${ROOT}/lib64 + use amd64 && /lib/ld-linux-x86-64.so.2 /bin/mv ${ROOT}/lib ${ROOT}/lib64 + use ppc64 && /lib/ld64.so.1 /bin/mv ${ROOT}/lib ${ROOT}/lib64 # all better :) ldconfig ln -s lib64 ${ROOT}/lib @@ -1040,7 +1062,7 @@ powerpc64*) export CFLAGS_ppc="${CFLAGS_ppc--m32}" export CHOST_ppc="powerpc-unknown-linux-gnu" - export CDEFINE_ppc="__powerpc__" + export CDEFINE_ppc="!__powerpc64__" export LIBDIR_ppc="lib" export CFLAGS_ppc64="${CFLAGS_ppc64--m64}" @@ -1295,12 +1317,18 @@ LIBDIR_x86="lib" fi + if [[ $(tc-arch) == "ppc64" && ${ABI} == "ppc" && $(get_libdir) != "lib" ]] && ! is_crosscompile; then + OLD_LIBDIR="$(get_libdir)" + LIBDIR_ppc="lib" + fi + toolchain-glibc_src_install - # Handle stupid lib32 BS on amd64 + # Handle stupid lib32 BS on amd64 and ppc64 if [[ -n ${OLD_LIBDIR} ]] ; then cd ${S} - LIBDIR_x86="${OLD_LIBDIR}" + [[ $(tc-arch) == "amd64" ]] && LIBDIR_x86="${OLD_LIBDIR}" + [[ $(tc-arch) == "ppc64" ]] && LIBDIR_ppc="${OLD_LIBDIR}" unset OLD_LIBDIR mv ${D}/lib ${D}/$(get_libdir) @@ -1308,7 +1336,8 @@ dodir /lib dodir /usr/lib mv ${D}/usr/$(get_libdir)/locale ${D}/usr/lib - dosym ../$(get_libdir)/ld-linux.so.2 /lib/ld-linux.so.2 + [[ $(tc-arch) == "amd64" ]] && dosym ../$(get_libdir)/ld-linux.so.2 /lib/ld-linux.so.2 + [[ $(tc-arch) == "ppc64" ]] && dosym ../$(get_libdir)/ld.so.1 /lib/ld.so.1 for f in ${D}/usr/$(get_libdir)/*.so; do local basef=$(basename ${f})
eradicator, I changed into { use amd64 || use ppc64 } from ( use amd64 || use ppc64 ). And I got the following messages. well... What did you want to change into ? Thank you. # ebuild glibc-2.3.4.20041102-r2.ebuild unpack /usr/portage/sys-libs/glibc/glibc-2.3.4.20041102-r2.ebuild: line 1375: syntax error: unexpected end of file !!! ERROR: sys-libs/glibc-2.3.4.20041102-r2 failed. !!! Function , Line 1702, Exitcode 1 !!! error sourcing ebuild !!! If you need support, post the topmost build error, NOT this status message. aux_get(): (0) Error in sys-libs/glibc-2.3.4.20041102-r2 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug)
Need a ';' in there ...
Created attachment 63310 [details] glibc-2.3.4.20041102-r2.ebuild right before commitment The code added recently was merged. And patches file name changed. glibc-2.3.4-patches-0.1.tar.bz2 --> glibc-2.3.4.20041102-patches-1.0.tar.bz2
(In reply to comment #30) > Need a ';' in there ... azarah, Thanks for your advice. I fixed this problem by your comment.
all merged to portage tree. thanks! ppc64 herds, please test glibc-2.3.4.20041102-r2 and glibc-2.3.5 . I made glibc-2.3.4.20041102-r2 based on ebuild of glibc-2.3.5. I think that we can mark stable if there is no mistake into ebuild since the source file is using the same thing as glibc-2.3.4.20041102-r1. And, it seemed to operate satisfactory when I tested recently glibc-2.3.5 simply. So, if you judges that 2.3.5 is stable, please mark stable not glibc- 2.3.4.20041102-r2 but 2.3.5.
I am running 2.3.5 *very* long now and don't have problems on my G5. Also I have positive reports on power3. I am currently testing on power5, but I'm looking forward that this does not break. So I vote for marking 2.3.5 stable, when we have testet it on a few more systems.
I tried to use multilib in accordance with your doc of "http://dev.gentoo.org/~nigoro/ppc64/multilib/", and failed with 'checking size of long double... configure: error: cannot compute sizeof (long double), 77' at 18th step(to emerge glibc for the second time). I looked at the config.log file, and it indicated that libsandbox.so could not be found. Actually libsandbox.so was in /usr/lib32 dir. What's wrong with it? Thank you. Dehua
Yang, check out: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=1 Yes, it's amd64, but maybe you're hitting one of the common problems listed at the bottom.
Yang, I'm sorry. My guide was old contents. I updated the guide. Please see it, when you shift to the multilib environment newly. I think that glibc is installable by the following methods from your report. # rm -rf /lib32 /usr/lib32 (Please make a backup copy, if you think that you are required.) # ACCEPT_KEYWORDS=~ppc64 emerge -v --oneshot '>=emul-linux-ppc-glibc- 2.3.4.20041102-r1' # FEATURES=-sandbox emerge sandbox # rm /lib32 /usr/lib32 # mkdir /lib32 /usr/lib32 # cp /emul/linux/ppc/usr/lib32/libsandbox.so /usr/lib32 # cp /emul/linux/ppc/usr/lib32/libc.so /usr/lib32 # cp /emul/linux/ppc/usr/lib32/libpthread.so /usr/lib32 # cp /emul/linux/ppc/usr/lib32/*crt*.o /usr/lib32 # env-update # ACCEPT_KEYWORDS=~ppc64 emerge -v --oneshot '=sys-libs/glibc-2.3.4.20041102- r2' # emerge unmerge emul-linux-ppc-glibc
