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

[Ben Abbott]

On Feb 1, 2011, at 8:18 AM, Richard Campbell wrote:

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

Fink can be installed anywhere the user desires. As you say, the default is 
"/sw", not "/usr/local". My understanding is that this is done to avoid using 
manually installing packages over the top of Fink's packages.

Regarding 32/64 bit, with Fink you have to pick one or the other. Reading the 
MacPorts FAQ it appears possible to build universal apps (Intel/PPC as well as 
32/64bit).

        http://trac.macports.org/wiki/FAQ#universal

Ben