Quoting Pasi Pirhonen <upi@xxxxxx>:
> that would be the part, i said about 'running machine can't be
> configured as build machine'.
>
> For starters there are command 'sparc32bash', which will partly hide
> the fact machine running 64bit kernel. Same thing applies for ppc64
> where the userspace is 32bit.
>
> Secondly it's much more easy to compile stuff as sparc32 when one
> alters the /etc/rpm/platform from sparc64-redhat-linux to
> sparc-redhat-linux. I really don't yet know how to handla all this
> _properly_. This is something to be resolved before actual release
> time.
>
> The sparc32/sparc32bash is basic stuff under sparc/sparc64 compilation.
Oh well... I guess I'll be hacking those files by hand if/when building my
custom RPMs on 4.2beta. The sparc32/sparc32bash alone wasn't sufficient. I
tought it was as simple as choosing the default (like i386 is default arch on
IA-32). Guess I was wrong ;-). I was kinda surprised when --target=sparc
hasn't worked like I expected it to work.
> Anothet thing is that i intentionally left out all the other bits and
> pieces of 64bit userspace than glibc/glibc-devel. I have to do some
> work on this area and sort out what bits and pieces i am actually
> inclusing on installation media and what is pushed to extras or
> something. Some of those are runtime and some ofg those are just parts
> that are really needed to be able to build 64bit parts. Even then i
> have to play tricks for some parts of 64bit to make it build.
I guess most of libraries, at least. Vast majority of applications don't
benefit from huge addresss space, but from time to time there's something user
might want to compile in 64bit mode (and than he'll cry if there's no 64bit
version of library xyz).
BTW, just out of curiousity I attempted to compile "hello world" program with
-m64, just to find out it can't be linked. Would it be possible to include
libgcc_s_64.so in next update (I guess it would be libgcc.sparc64
package)? Not really possible to compile much in 64-bit mode without it
(well, you can
compile, but not link) ;-)
Ah, I always hated mixed 32/64bit systems. I perfectly understand
reasoning why
they exist, and probably would do the things the same if I were
decision maker,
but I hate them anyhow. From time to time I'm getting into the mood "ok, let
it give more disk and memory, and let it run a bit slower, but give me pure
64bit system, so I don't have to tweak things constantly" ;-). Actually that
was the thing I always loved about Alpha and OSF/1 (or Tru64 as it is called
these days). It was clean, pure 64-bit system from day one, with no 32-bit
past dragging around. There was no "this part is 32-bit, that part is 64 bit,
oh no I don't have nn-bit version of that library" mambo jumbo. Just
couple of
buggy applications that assumed sizeof(int) == sizeof(void *), but that
was easy
to fix most of the time. Maybe it would be even a bit faster if they made it
mixed 32/64-bit, but it was fast enough that nobody really cared ;-)
> Most of those are needs for 64bit gcc to build. These days the damn
> thing needs about half of the universe to even build.
Yeah I know. I don't look forward to recompiling gcc even on
relatively recent
Intel hardware. Guess on old(er) Sparcs it is ten times worse (at least).
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
