View previous topic :: View next topic |
Author |
Message |
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Tue Apr 18, 2006 2:48 pm Post subject: Change CHOST: sparc -> sparc64 ? |
|
|
It took ages to set up my Blade 2000 using gentoo, now everything works but first time I tried to use 64bit features and to access more than 2GB RAM ... narf!
I forgot to change the CHOST from sparc-unknown-linux-gnu to sparc64-unknown-linux-gnu
Is it save/advisable to change this and run emerge -e system/world afterwards?
Thanks for suggestions ... |
|
Back to top |
|
|
gust4voz Retired Dev
Joined: 09 Sep 2003 Posts: 373 Location: Buenos Aires, Argentina
|
Posted: Tue Apr 18, 2006 6:47 pm Post subject: |
|
|
If you change the CHOST you're in completely unsupported land.... _________________ Gustavo Zacarias
Gentoo/SPARC monkey |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Wed Apr 19, 2006 8:03 am Post subject: |
|
|
gust4voz wrote: | If you change the CHOST you're in completely unsupported land.... |
Thought so. Anything else I can do to get 64bit binaries? Especially for dev-lang/R?
Edit:
That is: besides bootstrapping my own compiler in a private directory and recompiling R outside of portage (as I earlier did on Solaris) ...
Edit2:
crossdev, anyone? Currently bootstrapping sparc64-unknown-linux-gnu compilers from sparc-unknown-linux-gnu. let's see |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Thu Apr 20, 2006 11:22 am Post subject: |
|
|
Update: filed bug #130467 -- the toolchain can't be build due to issues with glibc.
That's my luck ^^ |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Sun Apr 23, 2006 11:05 am Post subject: |
|
|
Another update:
* crossdev was a dead end
* just discovered the "multilib" (32 + 64 bit binaries) use-flag for gcc, but can't enable it due to the profile
* found: /usr/portage/profiles/default-linux/sparc/sparc64/dev/multilib/ profile, the README is promising ...
Update of another update:
I did as the README advised but now I'm lost ... (yes, changing CHOST is unsupported, I know).
Nevertheless, anyone seen this before and knows how to handle it (happens during configure of gcc/libiberty)?
Code: | configure:4982: checking for working fork
configure:5005: sparc-unknown-linux-gnu-gcc -o conftest -O2 -pipe conftest.c >&5
/usr/bin/ld: warning: sparc:v9 architecture of input file `/var/tmp/portage/gcc-3.4.5/temp/cctmDRAx.o' is incompatible with sparc:v8plus output
configure:5008: $? = 0
configure:5010: ./conftest
/var/tmp/portage/gcc-3.4.5/work/gcc-3.4.5/libiberty/configure: line 5011: 25903 Segmentation fault ./conftest$ac_exeext
configure:5013: $? = 139
configure: program exited with status 139
configure: failed program was:
| /* By Ruediger Kuhlmann. */
| #include <sys/types.h>
| #if HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| /* Some systems only have a dummy stub for fork() */
| int main ()
| {
| if (fork() < 0)
| exit (1);
| exit (0);
| } |
|
|
Back to top |
|
|
Weeve Retired Dev
Joined: 30 Oct 2002 Posts: 641
|
Posted: Mon Apr 24, 2006 12:11 am Post subject: |
|
|
IIRC, multilib was designed for 64 bit architectures where you would want a majority of binaries built in 64 bits but occasionally there'd be some 32 bit binaries you might want to build and/or support as well. On SPARC64, we're in the opposite situation where typically we'll want 32 bit binaries unless there is something that requires only 64 bit binaries to work right (i.e. bridge-utils, xfsprogs). As such, multilib may create some interesting issues. |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Mon Apr 24, 2006 6:14 am Post subject: |
|
|
Interesting issues, that's a way to name it, yes ... I'm fighting those for days now.
Weeve wrote: | On SPARC64, we're in the opposite situation where typically we'll want 32 bit binaries unless there is something that requires only 64 bit binaries to work right |
Errr, we do want 32bit binaries? That's counter intuitive, isn't it? Why purchasing 64bit hardware, if I'm still dancing the 32bit boogie? In my case, I need support for more than 2GB RAM per process (as mentioned, especially for de-lang/R). Is there an recommended way to achieve this? Am I wasting my time?
Btw, is "eradicator" still an active developer? He wrote in the README, that one could contact him if problems arise, but didn't specify how ... |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Mon Apr 24, 2006 8:31 am Post subject: |
|
|
Yet Another Update: I just broke my system completely. After (successfully?) building multilib glibc, the merge failed. It seems that everything was removed, but nothing was merged.
After loads of !mtime obj XY (XY mostly includes, buffer ran out) and !empty dir D (D mostly locales), I got this ...
Code: | Traceback (most recent call last):
File "/usr/bin/emerge", line 3210, in ?
mydepgraph.merge(portage.mtimedb["resume"]["mergelist"])
File "/usr/bin/emerge", line 1912, in merge
retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug,tree="porttree")
File "/usr/lib/portage/pym/portage.py", line 2771, in doebuild
return merge(mysettings["CATEGORY"],mysettings["PF"],mysettings["D"],mysettings["BUILDDIR"]+"/build-info",myroot,mysettings,myebuild=mysettings["EBUILD"],mytree=tree)
File "/usr/lib/portage/pym/portage.py", line 2946, in merge
return mylink.merge(pkgloc,infloc,myroot,myebuild)
File "/usr/lib/portage/pym/portage.py", line 6984, in merge
return self.treewalk(mergeroot,myroot,inforoot,myebuild,cleanup=cleanup)
File "/usr/lib/portage/pym/portage.py", line 6628, in treewalk
self.unmerge(oldcontents,trimworld=0)
File "/usr/lib/portage/pym/portage.py", line 6427, in unmerge
a=doebuild(myebuildpath,"postrm",self.myroot,self.settings,use_cache=0,tree=self.treetype)
File "/usr/lib/portage/pym/portage.py", line 2651, in doebuild
return spawn(EBUILD_SH_BINARY+" "+mydo,mysettings,debug=debug,free=1,logfile=logfile)
File "/usr/lib/portage/pym/portage.py", line 1615, in spawn
return portage_exec.spawn_bash(mystring,env=env,**keywords)
File "/usr/lib/portage/pym/portage_exec.py", line 48, in spawn_bash
return spawn(args,env=env,opt_name=opt_name,**keywords)
File "/usr/lib/portage/pym/portage_exec.py", line 164, in spawn
raise str(e)+":\n "+myc+" "+string.join(myargs)
[Errno 2] No such file or directory:
/bin/bash [glibc-2.3.5-r3] bash -c /usr/lib/portage/bin/ebuild.sh postrm
close failed: [Errno 9] Bad file descriptor
!!! FAILED postrm: 1 |
Together with an unusable system:
Code: | $>ls
-bash: /usr/bin/ls: No such file or directory |
In addition: no more remote logins possible. Great.
Any hints besides "getting drunk" left?
Edit:
I know what happend: glibc was built successfully -- but 64-bit versions only. During merge, 32-bit libc.so was removed. Then, everything else, including emerge, broke. I will replace the missing libraries and try to figure out why I didn't get multilib ...
Another Edit:
I didn't get multilib since the multilib flag is still disabled by profile, i.e. (-multilib), although I have added it to my global USE-flags.
Therefore, everything is "right" for a given definition of right ... but, why the hell is multilib still disabled?!
Yet Another Edit:
Had to add -multilib to /usr/portage/profiles/default-linux/sparc/sparc64/dev/multilib/use.mask, now even portage reports multilib enabled. Ok, back to (compiling) buisiness ... btw, why wasn't multilib enabled by default?! |
|
Back to top |
|
|
Weeve Retired Dev
Joined: 30 Oct 2002 Posts: 641
|
Posted: Mon Apr 24, 2006 11:51 pm Post subject: |
|
|
As for "why would we want 32 bit binaries by default on a 64 bit architecture?" question, due to the way Sun architected their processors, its actually slower to run a 64 bit binary of a given application over the 32 bit equivalent. I don't have the exact details handy at the moment unfortunately.
As for the problem of more than 2GB of RAM per process, I'm not sure how to get around that at the moment.
Multilib is masked currently as eradicator started working on it but it never got into a state that we felt was worth giving to users, both from a usability/quality standpoint and a "keeping the noise down on bugs.gentoo.org" standpoint. It wasn't finished up yet as eradicator was working on making multilib work in a way that would better suit sparc64 and ppc64.
I believe eradicator is still active to some degree, though reaching him by email may be your best bet. His email is eradicator at gentoo dot org. |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Wed Apr 26, 2006 12:13 pm Post subject: |
|
|
Weeve, thanks for your reply. I got a mail from eradicator stating about the same as you.
Nevertheless, believe it or not, I'm alnost there. I bootstrapped a working 64-bit vanilla(!) toolchain (compiled by hand). After patching binutils-config and gcc-config, I could inject them into the system. Now I switched CHOST to sparc64-unknown-linux-gnu. Next step: re-emerging system/world to native 64-bit applications. I'll delay this until tomorrow ... if someone has helpful comments about this step, please let me know
Regards |
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon May 01, 2006 7:14 pm Post subject: |
|
|
I have not been as active as I would like this past year, and that is part of the problem this has remained so unstable. I remember trashing a half dozen chroots doing "conversion" and tried to document it as best I could.
Firstly, use eselect-compiler if you're not already. I know it's in package.mask, but that's because I haven't gotten around to writing code to upgrade gcc-config-1.x systems seamlessly. Then, you should try using crossdev to emerge a cross-compiling sparc64-* toolchain, then switch to CHOST=sparc64-* and switch the make.profile directory. Then emerge --oneshot glibc, then emerge binutils gcc, then unmerge the cross-* stuff. After that, you can emerge -ev world to pull in everything in 64bit. Do this in a chroot so your main install is stable and 32bit.
Please let me know what works/doesn't as I'd like to spend time this summer getting the multilib toolchain tools completed (eselect-compiler and eselect-binutils). _________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
TheDebugger Apprentice
Joined: 30 Aug 2005 Posts: 159 Location: Germany
|
Posted: Wed May 10, 2006 6:40 pm Post subject: |
|
|
eradicator wrote: | I have not been as active as I would like this past year, and that is part of the problem this has remained so unstable. I remember trashing a half dozen chroots doing "conversion" and tried to document it as best I could. |
Eradicator,
thanks for your post. I was offline for a couple of days and could not reply earlier. I didn't know about eselect-* until now, but I tried crossdev first. IIRC it stalled compiling glibc. Later, I dismissed crossdev and manually built a vanilla toolchain. From my point of view, the main point I missed was the chroot environment. I learned far too late about it (already screwed everything up). Unfortunately, I could not find a description/howto to follow. All I could unearth was catalyst. At this point, I stalled and cancelled all further activities since I am going to leave the company this month. The sparc machine is already "confiscated" and gentoo will eventually replaced by solaris
Nevertheless, thanks for your help and your time. If I can find another sparc machine at my new work place, I will start over
Regards |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|