Re: Effects of Fink / MacPorts [was: PCRE library requirement]

[Ben Abbott]

On Feb 1, 2011, at 7:26 AM, Richard Campbell wrote:

> On Feb 1, 2011, at 4:03, Jarno Rajahalme <address@hidden> wrote:
> 
>> On Feb 1, 2011, at 0:10 , ext Richard Campbell wrote:
>>> I am aware of Macports and Fink, third party package managers and 'port' 
>>> systems that have a truly horrifying effect on the operating system.
>> 
>> Could you please enlighten me a bit? I've been happy using macports on my 
>> system, and have not noticed any problems at all. Also, I like the fact that 
>> I can update the packages with a single command. So what exactly are these 
>> "truly horrifying effects"?
>> 
>> Jarno
> 
> We had ongoing problems with portability that we eventually traced to the 
> fact that two of my coworkers had multiple versions of gcc, gfortran, 
> libstdc++, etc on their machines. The ones from Fink and Macports all had 
> newer version numbers than the Apple variants but didn't support features 
> like universal binary construction. And depending on what user you were 
> logged in as, a different compiler would run when you typed 'gcc' on the same 
> machine. Additionally we had one machine where the presence of non universal 
> binary libstdc++ caused any third party OSX .app bundle which had been 
> compiled as 32-bit with c++ to not run.
> 
> When we got rid of Fink and Macports all of a sudden we could run the same 
> code with the same build process in all our OSX, Linux, and MinGW target 
> environments.
> 
> If the package managers don't install their own compilers then they're 
> probably fine. I just don't see how the benefits outweigh the potential 
> headaches, given that most projects build from source on OSX easily without 
> needing to be 'ported'.
> 
> But then again, before I ever used a Mac, I was on Slackware and I built 
> everything from source there too.
> 
> Campbell

I have little experience with MacPorts, but use Fink frequently.

For Fink your comments have merit. For example ...

$ echo $PATH
/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
$ which gcc
/usr/bin/gcc
$ ls /sw/bin/gcc*
/sw/bin/gcc-4  /sw/bin/gcc-fsf-4.4
$ which gfortran
/sw/bin/gfortran
$ ls /usr/bin/gfortran
/usr/bin/gfortran

The problem in this case is that I've added the patched gfortran from AT&T over 
Apple's gcc toolset. Had I limited myself to Xcode and Fink, then there would 
be no conflict of the naming of executables.

Linking to libraries is more problematic. Before libtool was introduced, I was 
in the habit of building fortran sources with gcc-4.4 and the c/c++ sources 
with gcc-4.2 (Apple's variant). With libtool this resulted in libstdc++ 
conflicts. Using the gfortran patched by AT&T, lets me build Octave again, but 
if I want to use gfortran from gcc-4.4, I need to point to the one with the 
version number appended.

$ ls /sw/bin/gfortran*
/sw/bin/gfortran  /sw/bin/gfortran-fsf-4.4

Currently Fink relies heavily on Apple's gcc (4.2) for building most apps and 
libraries.  However, since it does not have a gfortran-4.2 available, it is 
common to see linking of object code compiled with different versions of gcc 
... Apple's gcc-4.2 and gfortran-fsf-4.4 for example. I don't know what their 
plans are for resolving the implied problem with this practice and using 
libtool (or maybe there is a work around, I'm unaware of?).

I've been considering switching to MacPorts since it doesn't allow mixing of 
compiler versions (all dependencies are built with the same compiler). I don't 
think this was always the case. My impression is this changed with the release 
of Snow Leopard (just guessing really).

Ben