Ubuntu 11.04 and MATLAB x64 C, C++ and Fortran libraries

MatLab requires the use of libraries (think translation dictionaries) to run code that is outside of it’s native realm (a hybrid C).

The most common of computing languages are those of C and Fortran (an old machine code).

The problem is that old code runs typically on 32 bit (a way of addressing memory), whereas most modern operating systems are now running 64 bit.

If you run a 64 bit Linux distro then you cannot run 32 bit MATLAB and you will be forced to install and run x64 MATLAB (there are some work around for Windows).

Added complication comes from the fact that you need 32 and 64 bit libraries to run some code. This is due to some of the 64 bit compilers being unable to effectively mimic a 32 bit environment.

The best analogy I can think of is trying to read French in English knowing no French and having only an Ancient Latin dictionary as a reference. But if you then have an Ancient French to Ancient Latin dictionary as well you can have a fair stab at comprehension, even if it’s through Ancient French to Latin to English.

This whole process is further complicated, as by default Ubuntu will not let you have 2 versions of the same library. By installing the 32 bit library you replace the 64 bit.

In Fedora it is assumed that whilst the OS is 64 bit you’ll want to use 32 bit libraries. As a result, Fedora has both /usr/lib64 and /usr/lib32.

Ubuntu does not. Ubuntu gives you /usr/lib. What we need to do is install all the 64 bit libraries which is automatically linked, then create a /usr/lib32, install the 32 bit libraries and then symbolically link the 32 bit libraries into /usr/lib. However, we first need to install a repository that gives us the facility to run more than one library, so that the 32 bit links don’t overwrite the 64 bit links.

Go to System > Administration > Symantic Package Manager.

Using the Quick Filter install:

  • gfortran-4.5 (or newer)
  • gfortran-4.5-multilib
  • libgfortran3
  • lib32gfortran3
  • fort77
  • ratfor
  • f2c

Apply these updates and close.

Open a Terminal window. Now we need to install a few other things

Java compiler

1
sudo apt-get install gcj

GNU autotools

1
2
sudo apt-get install autoconf
sudo apt-get install automake

Intel Compiler Suite

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
sudo apt-get install gcc
sudo apt-get install build-essential
sudo apt-get install libc6-dev
sudo apt-get install ia32-libs
sudo apt-get install g++-multilib
sudo apt-get install libc6-dev-i386
sudo apt-get install alien
sudo apt-get install rpm
sudo apt-get install libstdc++5
sudo apt-get install libstdc++5-3.3-dev

Now everything should be installed. Now we need to install the x32 without overwriting the x64 in /usr/lib. So we need to manually download the library, unpack them and link manually.

So, download the 32 library (link) (Update: latest version is 4.5, give it a Google)

Extract it:

1
dpkg --extract libstdc++5_3.3.6-18_i386.deb  ./

Change the version number if you’ve downloaded a different version

Note that a /usr folder has been created wherever you downloaded the folder to. We need to now copy this file to /usr/lib32

1
2
cd usr/lib
cp libstdc++.so.5.0.7 /usr/lib32

Now link the x32 library to your system

1
2
cd /usr/lib32
ln -s libstdc++.so.5.0.7 libstdc++.so.5

Update your system:

1
sudo apt-get update

Now MATLAB should be working with all the required libraries in 32 and 64 bit.

Referenced from Intel and Ubuntu docs

DeerAnalysis

To further get DeerAnalysis working requires 2 more lines of code in terminal:

1
2
3
cd [path to DeerAnalysis]
gfortran -o ftikreg_r_new.out ftikreg_r_new.f
gfortran -o ftikreg_r_old.out ftikreg_r_old.f

Thanks to Gunnar Jescke

Older post

Peakfinder

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.