Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Change CHOST: sparc -> sparc64 ?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc
View previous topic :: View next topic  
Author Message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Tue Apr 18, 2006 2:48 pm    Post subject: Change CHOST: sparc -> sparc64 ? Reply with quote

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
View user's profile Send private message
gust4voz
Retired Dev
Retired Dev


Joined: 09 Sep 2003
Posts: 373
Location: Buenos Aires, Argentina

PostPosted: Tue Apr 18, 2006 6:47 pm    Post subject: Reply with quote

If you change the CHOST you're in completely unsupported land....
_________________
Gustavo Zacarias
Gentoo/SPARC monkey
Back to top
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Wed Apr 19, 2006 8:03 am    Post subject: Reply with quote

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 :D
Back to top
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Thu Apr 20, 2006 11:22 am    Post subject: Reply with quote

Update: filed bug #130467 -- the toolchain can't be build due to issues with glibc.
That's my luck ^^
Back to top
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Sun Apr 23, 2006 11:05 am    Post subject: Reply with quote

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
View user's profile Send private message
Weeve
Retired Dev
Retired Dev


Joined: 30 Oct 2002
Posts: 641

PostPosted: Mon Apr 24, 2006 12:11 am    Post subject: Reply with quote

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
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Mon Apr 24, 2006 6:14 am    Post subject: Reply with quote

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
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Mon Apr 24, 2006 8:31 am    Post subject: Reply with quote

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? :D


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
View user's profile Send private message
Weeve
Retired Dev
Retired Dev


Joined: 30 Oct 2002
Posts: 641

PostPosted: Mon Apr 24, 2006 11:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Wed Apr 26, 2006 12:13 pm    Post subject: Reply with quote

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 :D

Regards
Back to top
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon May 01, 2006 7:14 pm    Post subject: Reply with quote

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
View user's profile Send private message
TheDebugger
Apprentice
Apprentice


Joined: 30 Aug 2005
Posts: 159
Location: Germany

PostPosted: Wed May 10, 2006 6:40 pm    Post subject: Reply with quote

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 :D

Regards
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Sparc All times are GMT
Page 1 of 1

 
Jump to:  
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