Jump to content

X86_64 architecture: 10.1 troubles


Ishark
 Share

Recommended Posts

Hi everybody :)

 

I'd like to share experiences with other users attempting to run Mandrake 64bit on an x86_64 system.

10.0official seems to install and run ok (lots of software is unavailable), but the 10.1official has been quite problematic. In particular:

- raid support is missing in the installer, I had to resort to install to a non-raid partition and then move the stuff to a raid partition (and generate manually an initrd supporting a raid1 root partition).

- a ton of software is missing, more than 10.0, it seems (Windowmaker, rox-filer, .....)

- weird behaviour (e.g. galeon locks up on exit eating 100%, the default install of mozilla-firefox does not even start up).

 

It's quite evident that right now the x86_64 architecture is not supported as well as IA32, I have an i586 10.1official running without any trouble on the PC, should I take the time (and problems) to move to 64bit for a slight speed increase or I'd better stay with my current setup?

Is there an ongoing effort somewhere to recompile the RPMS from the source for the x86_64 machines? Is this actually doable?

 

Thanks in advance for any answer.

Link to comment
Share on other sites

"Is there an ongoing effort somewhere to recompile the RPMS from the source for the x86_64 machines? Is this actually doable?"

 

Well, that's exactly how the x86_64 port is built in the first place. All MDK versions are generated from the same set of .src.rpms.

 

WindowMaker and rox-filer do seem to be missing, yeah. Maybe they have trouble compiling under x86-64 at present?

Link to comment
Share on other sites

Well, that's exactly how the x86_64 port is built in the first place. All MDK versions are generated from the same set of .src.rpms.

This does not seem to be the case, since all the libraries can coexist in two versions: libXXX and lib64XXX in order to be able to run both 32 and 64 bit applications. I think that this is one major source of headache, since the i586 RPMS can't be simply rebuilt and dropping the 32bit libraries guarantees to break all non-free/binary-only applications (e.g. acroread).

I'm thinking about giving a try of rebuilding everything from the i586 SRPMS dropping any attempt at 32bit compatibility, if I have the time during the holidays. I also want to try gentoo to see how they tackle the problem.

Link to comment
Share on other sites

Well, that's exactly how the x86_64 port is built in the first place. All MDK versions are generated from the same set of .src.rpms.

This does not seem to be the case, since all the libraries can coexist in two versions: libXXX and lib64XXX in order to be able to run both 32 and 64 bit applications. I think that this is one major source of headache, since the i586 RPMS can't be simply rebuilt and dropping the 32bit libraries guarantees to break all non-free/binary-only applications (e.g. acroread).

I'm thinking about giving a try of rebuilding everything from the i586 SRPMS dropping any attempt at 32bit compatibility, if I have the time during the holidays. I also want to try gentoo to see how they tackle the problem.

 

 

I find it pretty poor.... I just gave up basically what I got on the CD's with 9.2 AMD64 was OK but everything else is a pain to install, find deps and is unstable.

 

As far as I can see there is no free version of AMD64 to download its pay only.. and surprise ... noone would pay for it once they have tried it in a home environment (IMHO)

 

Having said that suse was about the same just a lot more professional ... Mandrake lost the advantage it has over Suse in terms of flexibility and using urpmi becuase so much is broken outside the official RPM's.

 

Gentoo was the closest i got to a working system but even then stuff like 32bit libraries need to be used in a chroot environment for simple stuff like the firefox plugins etc.

Link to comment
Share on other sites

There's no such thing as an 'i586 .src.rpm'. .src.rpm's, by definition, have no architecture. The 64-bit and 32-bit packages *are* built from the same .src.rpm's; the different files that result are not proof to the contrary. If you follow the Mandrake Cooker changelog you'll see many updates to packages which consist of nothing but 64-bit fixes. The reason some things just can't be rebuilt straight from the existing .src.rpm's is because code can be 'broken' in such a way that it compiles fine for a 32-bit architecture but not for a 64-bit architecture. These problems need to be fixed before a 64-bit package can be built. For e.g., OpenOffice currently will not build correctly as a 64-bit application due to coding problems.

Link to comment
Share on other sites

gowator: the AMD64 version of 10.1 is freely downloadable on several mirrors. The ISOs have not yet been made publicly available but you should be able to do a network install from any mirror with a 10.1 AMD64 tree.

Hmm... that kinda means I would be stuck if they turned out to be incomplete...

 

I guess if I was doing that I'd reinstall 9.2AMD64 first then update it... but it looks like mandrake missed the boat on that one. They left the poor PPC people stuck in archaic versions and I guess they will do the same with AMD64....

 

They are already so far behind the IA32

 

Apart from that they are IMHO being very dishonest over this... if they haven't made ISO's is to force people to buy and although I have no prob paying for a working product 9.1 wasn't a working product for home....so why would i trust them on 10.2?

 

Have you actually tried this becuase i guess they weill miss some vital parts that you need to download but the idea being people give up and buy thge Cd's...

Link to comment
Share on other sites

There's no such thing as an 'i586 .src.rpm'. .src.rpm's, by definition, have no architecture. The 64-bit and 32-bit packages *are* built from the same .src.rpm's; the different files that result are not proof to the contrary.

 

I'm not sure I understand: from what I know a src.rpm contains everything needed to generate a given packet, on any architecture. When you compile it for a specific architecture you get a binary RPM for the architecture. If the libkdecore .src.rpm generates libkdecore.so then it will do it both on i586 and on x86_64, except that in one case it's a 32bit library and in the other 64bit. Having all the 64bit libraries renamed to lib64xxxxx and having them placed in /lib64 means modifying all the RPM spec files to do the job, which means a lot more stuff to check/debug. Together with the compilation problems on the 64bit architecture, this certainly does not help in making life easy for the distributions....

For the moment I'm staying on the 32bit side, but I have both distribs installed and I'll keep checking the progress of the 64bit to decide when it's time to switch.

Link to comment
Share on other sites

Ishark:

that is what I found, there was so much work involved i just gave up....

Even with this some of the stuff seems to be explicitly looking in /lib and not /lib64.

 

adamw: Its like this, it would taken them a short time to make an ISO from the directories ... they haven't and haven't said why. My experience of 9.1 was it was a complete pig...

 

The 64 bit sites seem to come and go, I couldn't even get updates most of the time when running 9.1 AMD64 so I feel the chance of a full network install working before the mirrors change or fsck up is small.

 

the deps are not worked out..as Ishark says... because the RPM has the 32bit dep listed in many cases

 

I found mandrake64 very very poor. The best part of mandrake for me was/is urpmi and I couldn't even get a lib64dvdcss2 ... I ended up feeling everything needed to be installed from source and if Im going to do that then I'd go gentoo...

alternatly if I just wanted a 'wroking' distro I would have kept the suse64 on it...

 

 

As usual mandrake are fsck'ing themself. They don't make the iso available because they don't have 'enough interest' and they don't have enough interest because they haver no ISO... I think the real reason is they haven't sorted out half the deps!!

Link to comment
Share on other sites

ishark: that's exactly my understanding, and I thought my post said the same thing! a .src.rpm cannot 'have an architecture' because, as you said, all it contains is source and it can potentially be built on many architectures. And yes, the spec file is where all the magic to make the 64-bit RPMs and distribution takes place, and yes it is quite a lot of work. But there's only *one* set of Mandrake .src.rpms, and they contain all the stuff to build both the x86 and x86-64 versions.

 

gowator: for a mirror, try anorien. It's got everything, it's very up to date and reliable, and pretty fast.

 

I doubt the deps are the reason there's no ISOs yet, because they're already selling the product, and if they weren't confident in it you'd hope they wouldn't do that. It's probably just a time issue; MDK does not have a lot of employees and the ones it has are very busy. I agree the ISOs should be released as soon as possible, though. BTW, there's nothing to stop you building your own ISOs - download a full copy of the x86-64 tree and use mkcd. That's how the official ISOs are built, in any case.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...