# Is is really necessary to rebuild all ports after upgrading?



## mariourk (Apr 10, 2014)

I just went from 9.1 to 9.2 to 10.0. All that's left, is rebuilding the installed ports. I wonder, is this really necessary, or is it a mere precausion? If everything functions normal and I see no errors in the logs, do I still need to rebuild everything?

How do you guys handle this?


----------



## SirDice (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

Yes, it's necessary. After a major version upgrade _always_ rebuild or reinstall all ports.


----------



## kpa (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

The technical reason is that the so called ABI (application binary interface) has changed with the newer version of the operating system. It now contains a different set of shared libraries and in some cases a different set of system calls that differ from what the old version offered. You can think the ABI as a "contract" that is valid only on the same major version of the OS. When moving to next higher major version of the OS the contract is no longer valid and any binary programs that were compiled on the older version of the OS are no longer guaranteed to work. Programs that are part of the base system have to be also updated of course but this update is covered by `make installworld`. There's also a small set of programs that are guaranteed to work with a kernel from the next higher major version to make sure the upgrade of world can be done in single user mode after booting the new kernel the first time.


----------



## mariourk (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

Isn't there a way to check if there are programs affected by abi breakages, so only those need to be recompiled? If not, shoudn't this be a feature? Or is this way too complex to do?


----------



## kpa (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

It could be done with symbol versioning but it's way too complex to catch all edge cases like making sure the the minimal set of programs I mentioned still works with the next major version of the kernel. Also the binutils that FreeBSD still uses is old and buggy and who knows if it would actually work. Maybe when we get the binutils from the LLVM project it could all change.


----------



## mariourk (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

Let's hope so. Rebuilding everything is kind of ridiculous, in my opinion. A more efficient and smooth transition between releases would be nice!


----------



## SirDice (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

As a stop-gap measure you can install misc/compat9x but you really should rebuild everything.


----------



## kpa (Apr 10, 2014)

*Re: Is is really necessary to rebuild all ports after upgrad*

Even if you could detect the changes in the ABI the need to rebuild would still stay and the amount of programs that need to be rebuilt wouldn't be any less. That's the price we have to pay from certain decisions. For example almost every single UNIX program still uses the dynamic linking in a "direct" way which is basically loading a shared library and letting the dynamic linker resolve the unsolved references. This is basically ok but leads to what is known as a "DLL Hell" when different versions of the same shared library with multiple versions of the same API are needed by different programs. 

There are solutions to this problem available and one of them is called CORBA that is kind of a broker system for programming APIs offered by sofware components. With CORBA you don't directly link to a DLL that offers the correct API with the correct version but you ask the CORBA system for a reference (pointer) to a specific API with a specific version and the system returns that to your program and your program doesn't have know any of the details how the actual loading/linkage happened. Sadly nobody seems to use CORBA or any equivalent system in their projects but keep using the rapidly aging UNIX shared library interface.


----------

