Ok ok... I'll try using the smake build system again... and see what comes of it it was a few years ago that I last tried, when I was working at Weta Digital and was trying to get a DVD-writer working (at the point it was easier said than done)... Ok I don't want to continue adding coal to the fire here, and i'm not one to break up a good flame war =-). I think perhaps tho considering Andi has access to a rather large number of opteron build environments and Joerg needs a test system perhaps working together on this might be desirable. Joerg if you need an opteron test platform e-mail privately and I'll setup ssh access to mine... I can't gurantee the cleanliness of the environment tho. But it's a fresh kernel from kernel.org, gcc 3.3 with backported k8 extensions. I can see an easy resolution to this problem, but it involves working together, I'm guessing once Joerg has access to an opteron running linux, he can make a list of issues arising for someone (Andi?) who knows the amd64 linux arch far better than I from a coding level. Anyway, Again I thank both of you for continuing to acknowledge the issues revolving around this issue. Kind regards Joel W New Zealand On Tue, 2004-09-28 at 15:57 +0200, Joerg Schilling wrote:

Joel Wiramu Pauling wrote:

...

Thanks Guys for the Quick reply, I appreciate it.

So currently the Suse contributed fork uses 32bit system calls inside the 64bit binary anyway. So there will be no issue using a default cdrecord branch which now has dvd-/+ support, compiled as a i386 arch?? (Sorry for my lay understanding,) I'm a build monkey not a coder ;-)

Sorry, this is not corect: 64 Bit Linux on Opteron is unable to run non trivial programs like cdrecord. If you like to use cdrecord-ProDVD I would need to find a Linux-Opteron system to compile cdrecord.

...

Joerg, considering the explanations bellow, adding in x86_64 include definitions to your cdrecord make system wouldn't be too difficult then?? Always helps for people like me who tend to extract, readme, make, make install, and I prefer to have 64bit binarys where possible (even if they are making 32bit calls underneath... just cleaner that way =-).

You don't need them if you use 'smake' unstead of gmake.

In contrary to gmake, smake supports automake features.....

Jörg