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

[Richard Campbell]

On Feb 1, 2011, at 8:08 AM, Ben Abbott wrote:

> 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
> 

If you can convince the package managers to install to /usr/local by default, 
and build everything as a universal binary, then the problems would probably go 
away. /usr/local has nothing installed to it on a vanilla OSX installation, but 
it IS in the default path, so the only issues would be if you have different 
versions of the same code in /usr and /usr/local.

The gfortran-4.2 released by r.research.att.com is built using a very slightly 
modified version of Apple's gcc build scripts, which is why it supports 
universal binary creation. I don't know how Fink and Macports do it now, but 
the gfortran build from hpc.sourceforge.net doesn't support universal binary 
creation so you're limited to being able to compile to either 32 or 64-bit. 
Since it replaces libgfortran this is a bigger problem, as it screws with 
existing code which links to libgfortran. Hence, having the universal binary 
version of gfortran installed is probably safest.