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 ;-) 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 =-). Again thanks both of you, both your comments will hopefully stop wasting the relatively expensive dvd media my burner has been devouring. Kind regards Joel W New Zealand On Mon, 2004-09-06 at 20:30, Andi Kleen wrote:

On Mon, Sep 06, 2004 at 10:17:40AM +0200, Joerg Schilling wrote:

...

Andi Kleen wrote:

...

An 32bit version of cdrecord should work on x86-64 in theory.

Correct for Solaris, not correct for Linux because of missing 64/32 bit support in the drivers :-(

You are wrong on this. We have pretty good 32bit emulation including most ioctls since many years (99+% coverage). In fact there are whole 64bit ports who usually run 32bit programs and 64bit only in special cases (like sparc64 or ppc64).

...

Things that need to be planned take a long time on Linux. Solaris offers full 64/34 bit support since 1997, let's see when Linux will come up with it....

The earliest copyrights in the 32bit emulation code of Linux (for sparc32/sparc64) date back to 1997 too.

The x86-64 32bit emulation is only a few years old, but builds heavily on the work of other architectures who do this much longer and is also quite mature.

-Andi