x86_64 Linux C/C++ Test

I use:

However, don’t go the websites, all of these are available in the (Default?) repositories, so you can either install them via yum, PackageKit or apt-get. Also note: RapidSVN and Meld are only needed if you want to use SVN. Even KDevelop is not required if you have another text editor that you prefer such as gedit/vi/emacs. If you want to create your provide your own make file then you don’t need cmake either.

Anyway, so a simple application that just tests that you can do a 64 bit compile is pretty straight forward.
1) Create your main.cpp file with a int main(int argc, char* argv[]); in it.

# Set the minimum cmake version
cmake_minimum_required (VERSION 2.6)
# Set the project name
project (size_test)
# Add executable called "size_test" that is built from the source file
# "main.cpp". The extensions are automatically found.
add_executable (size_test main.cpp)

2) Create a CMakeLists.txt that includes your main.cpp.

#include <iostream>
int main(int argc, char* argv[])
  int *int_ptr;
  void *void_ptr;
  int (*funct_ptr)(void);
  std::cout<<"sizeof(char):        "<<sizeof(char)<<" bytes"<<std::endl;
  std::cout<<"sizeof(short):       "<<sizeof(short)<<" bytes"<<std::endl;
  std::cout<<"sizeof(int):         "<<sizeof(int)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long):        "<<sizeof(long)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long long):   "<<sizeof(long long)<<" bytes"<<std::endl;
  std::cout<<"sizeof(float):       "<<sizeof(float)<<" bytes"<<std::endl;
  std::cout<<"sizeof(double):      "<<sizeof(double)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long double): "<<sizeof(long double)<<" bytes"<<std::endl;
  std::cout<<"sizeof(*int):        "<<sizeof(int_ptr)<<" bytes"<<std::endl;
  std::cout<<"sizeof(*void):       "<<sizeof(void_ptr)<<" bytes"<<std::endl;
  std::cout<<"sizeof(*function):   "<<sizeof(funct_ptr)<<" bytes"<<std::endl;
  std::cout<<"Architecture:        "<<sizeof(void_ptr)<<" bit"<<std::endl;
  return 0;

3) cd to the directory of your CMakeLists.txt and run “cmake .” and then “make”
4) ./size_test output:

sizeof(char):        1 bytes
sizeof(short):       2 bytes
sizeof(int):         4 bytes
sizeof(long):        8 bytes
sizeof(long long):   8 bytes
sizeof(float):       4 bytes
sizeof(double):      8 bytes
sizeof(long double): 16 bytes
sizeof(*int):        8 bytes
sizeof(*void):       8 bytes
sizeof(*function):   8 bytes
Architecture:        64 bit

As you can see this is specific to x86_64. The beauty of gcc is that by default it compiles to the architecture it is being run on. I had previously thought that it would be a world of pain, making sure that my compiler built the right executable code and linked in the correct libaries. I know this project doesn’t use any special libraries, but (because of cmake?) the process is exactly the same as using cmake under 32 bit to make 32 bit executables. You just make sure that they are there using Find*.cmake and then add them to the link step:

# Some of the libraries have different names than their Find*.cmake name
# Link our libraries into our executable

Note that we don’t actually have to specify the architecture for each package or even the whole executable. This is taken care of by cmake. Anyway, it is not some mysterious black magic, it is exactly the same as you’ve always been doing. Cross compiling is slightly different, but basically you would just specify -m32 and make sure that you link against the 32 bit libraries instead. If I actually bother creating another 32 bit executable in my life I’ll make sure that I document right here exactly how to do a cross compile from 64 bit.

The advantages of 64 bit are mmm, not so great unless you deal with really big files/memory ie. more than 4 GB. Perhaps more practical are the extra and upgraded to 64 bit registers so you may see an increase in speed or parallelisation of 64 bit operations, for example a game may want to use 64 bit colours (ie. 4x 16 bit floats instead of 4x 8 bit ints to represent an rgba pixel.

Things to watch out for:
int is still 32 bit! If I were implementing the x86_64 version of C++ standard/gcc/in a perfect world this would have been changed to 64 bit, ie. “int” would be your native int size, it’s logical, it makes sense. However, I do understand that this would have broken a lot of code. The problem is, if int != architecture bits, then why have it at all, why not drop it from the standard and just have int32_t and int64_t and be done with it. Then if a program chooses it can have:

typedef int32_t int;


typedef int64_t int;

as it sees fit. Anyway.
Pointers are now 64 bit! So you can use them with size_t but cannot use them with int
Under linux x86_64 gcc sizeof(int*) == sizeof(function*), however, this is not guaranteed anywhere. It may change on a certain platform/compiler. Don’t do stuff like this:

int address = &originalvariable;

gcc should warn you (you may need to turn on these warnings -Wformat -Wconversion).

All in all, if you have been writing standard code and using make/cmake it should be relatively pain free to upgrade to 64 bit.

Linux x86_64

I have been dipping my toe into x86_64 waters sporadically over the last couple of years. On each of the previous occasions it always seemed too immature, packages were way to hard to come by (I prefer precompiled binaries), half my hardware didn’t work, strange crashes etc. Seeing as this episode has been 100% successful, I thought this time I would document it.


My favourite distribution is Fedora due to it’s rapid development and ease of use. I downloaded via BitTorrent. (Obviously) make sure you get the x86_64 version. I always like to run the sha checksum to rule out that as the problem if something does arise later. I also make sure that my DVD verifies in my burning program after it has been burnt.

Now we are ready to install. Unless you have something really exotic you should not need any special drivers or anything (At least not until after the install), it should just work. The important parts of my hardware are:
Asus A8V-E SE (Not awesome, my awesome motherboard blew up causing me to downgrade to this one I had lying around) AMD Socket 939
AMD Athlon 64 X2 4800+ CPU
nVidia GeForce 8600 GT 256MB PCIe

I use the onboard LAN and sound card, as well as 2 SATA drives, an IDE drive and an IDE CDROM.

So I installed Fedora from the DVD. You can again choose to verify the media, weirdly (And in previous versions as well) this check always seems to fail even though the sha check and burning software verification succeed, so either the check is broken or the motherboard/drive is broken. I have never seen this verification succeed in my life. Anyway, I skip it now and the options I select (At appropriate times) are fresh install onto a blank drive, “Software Development” profile/packages (You can probably turn off the other profiles, you can install any required packages individually later on when you are in the OS anyway). Next time I do an install I would love to try an upgrade install.

That should all install (You don’t have to get too serious about selecting the right packages right now, I find it easier to install “generally” what I need (“Software Development”) and then customise later) and you should now be logging into a fresh install of Fedora 10.

Initially I had some problems with an additional PCI sound card I had present due out of habit because I had never gotten my on board sound to work for any motherboard under Linux. Some programs were using the onboard and some where then using the PCI one, so I rebooted and went into the bios to disable the onboard one. Both still get detected. Apparently this is a common problem with this motherboard. I went to update the bios and wouldn’t you believe it, the bios updater is Windows only. Anyway, because the onboard sound card was being detected I just removed the PCI one and enabled the onboard one again. That fixed it up awesomely and I had audio, yay. Also removing PulseAudio can “unconfuse” applications and force them to use ALSA,
yum remove alsa-plugins-pulseaudio

I then noticed that I had some issues with audio playback stuttering, cycling through normal speed and then fast for a second and then normal again. I fixed it by following this tutorial.

Add the Livna repo by downloading and running the add repo rpm, it is not linked to on the main page, but the url can be built from the other releases. Add the RPMFusion repo by downloading and running both the free and non-free add repo rpm.
For my information:
RPMFusion provides additional packages that are not in the base Fedora repos.
Livna provides the same packages as RPMFusion, but also provides the libdvdcss package for watching DVDs.

I have never had much luck with ATI drivers for Linux. I had heard the nVidia ones were easier to install and configure and apparently faster to boot. Before you install drivers, you might want to get a benchmark of your FPS in glxgears before installation:

I downloaded and installed the nVidia (Binary, proprietary) driver:
sudo yum install kmod-nvidia

Now reboot (It’s the easiest way to restart X). Test that hardware accelerate rendering is happening by looking for in the output of this command:
glxinfo | grep direct

And your glxgears FPS should be above 2000:

Adobe recently released an x86_64 Linux version of Flash so we don’t have to mess around with nswrapper etc. any more. I downloaded it from here, extracted, su, cp ./libflashplayer.so /usr/lib64/mozilla/plugins, restarted Firefox. You may want to test it also.


For my benefit for next time, I also like:
Neverball and Neverputt
Open Arena
Urban Terror


I have not provided any links to these as they are all present in PackageKit which comes with Fedora 10.

Also for my information:
Firefox Add Ons
Adblock Plus
PDF Download

Nightly Tools

Net Usage Item

Open links in Firefox in the background
Type about:config into the address bar in Firefox, then look for the line browser.tabs.loadDivertedInBackground and set it to true.

Automatic Login
su gedit /etc/gdm/custom.conf

And adding this text:
# http://live.gnome.org/GDM/2.22/Configuration

NTFS Drives
Gnome automatically finds and mounts NTFS drives/partitions, however in Fedora 9 and later, ownership is now broken. Each partition (And every sub folder and file) seems to default to ownership so even though some operations work such as moving files around, even adding and deleting, some programs will complain (I found this problem through RapidSVN not working). Nautilus reports that you are not the owner and even if you run Nautilus as root you cannot change to owner to anything other than root. The way I solved this was to install ntfs-config and run with:
sudo ntfs-config

You should now have valid entries in /etc/fstab:
sudo cp /etc/fstab /etc/fstab.bak
gksudo gedit /etc/fstab

Something like this (One for each partition, the ones you are interested in are any with ntfs-3g):
UUID=A2D4DF1DD4DEF291 /media/DUMP ntfs-3g defaults,nosuid,nodev,locale=en_AU.UTF-8 0 0

I then edited each ntfs-3g line like so:
UUID=A2D4DF1DD4DEF291 /media/DUMP ntfs-3g defaults,rw,user,uid=500,gid=500,umask=0022,nosuid,nodev,locale=en_AU.UTF-8 0 0

Where uid=youruserid and gid=yourgroupid. You can find these out via System->Administration->Users and Groups (There is probably a command to find this out, actually I would say there is definitely a command for finding this out, but I’m pretty lazy). If you log in with different users perhaps changing to a common group would be better? Reboot to let these settings take effect. If you now to view your partition in Nautilus, File->Properties->Permissions should now list you as the owner with your group.

You now have a pretty well set up Fedora 10 installation. These steps should be pretty similar for future versions. I will probably refer back these when I install Fedora 11 or 12 in a year or two. I love Fedora because it is the total opposite of Windows. With Vista, Microsoft stagnated, waiting a year or two longer than they should have to release a product that by that time was out of touch with the target audience. In contrast, I had been planning to install Fedora 9 this time around after installing 8 only 6-12 months ago, but I was pleasantly surprised to find that 10 had been released. I would also like to try Ubuntu as I haven’t really used it much apart from at work, so I might give that a shot next time. x86_64 has certainly matured over the last 2 or 3 years, I would say it is definitely production server ready and probably has been for at least a year. The quality and variety of packages available for Linux is amazing, the community just keeps on giving. Fedora just keeps on amazing me. The future is bright, I can’t wait.