Why pip does not use gcc and g++ automatically? (Mountain Loin)

[Peng Yu]

On Fri, Oct 19, 2012 at 5:09 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Oct 19, 2012, at 16:31, Peng Yu wrote:
>
>> I have the following ports installed and I setup virtualenv correctly.
>>
>> sudo port -v install python27
>> port select python python27
>>
>> sudo port install py27-pip
>> sudo port install py27-virtualenv
>> sudo port install py27-virtualenvwrapper
>>
>> But when I install a package within a virtual environment, I have to
>> explicit specify the compiler as the following. Otherwise clang or
>> clang++ will be used and the installation will yield error. Is it
>> because macports was compiled by clang and clang++. Is there a way to
>> that pip use g++/gcc as the default?
>>
>> CXX=g++ CC=gcc FFLAGS=-ff2c pip install scipy
>
> There is *no* gcc in Xcode 4.2 and later. In those versions of Xcode, the programs "gcc" and "g++" are *not* gcc; they are symlinks to llvm-gcc-4.2 and llvm-g++-4.2.
>
> If a port does not compile correctly with clang, that is a bug and you should file a bug report in our issue tracker. It wasn't clear to me from what you wrote above what MacPorts port was not compiling properly with clang. It sounded like maybe you were talking about software that you install manually, not using a port. If so, take the matter up with the developers of that software.

What I did was the following (besides installing the port packages as
shown in the first email).


mkdir $HOME/.virtualenvs

Add the following to ~/.bashrc

export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_VIRTUALENV=/opt/local/bin/virtualenv-2.7
. /opt/local/bin/virtualenvwrapper.sh-2.7

source ~/.bashrc

mkvirtualenv --distribute py

workon py

You will see a prompt "(py)"

Under "(py)", run 'CXX=g++ CC=gcc FFLAGS=-ff2c pip install scipy'. It
will finish successfully. If you just run 'pip install scipy', it will
fail (I have closed the window, so I can not show the error message).

My understanding is these python packages assume gcc but not clang,
some options available to gcc are not available to clang. So it cause
errors if clang is used. Would you please take a look if you can
reproduce the same problem?

-- 
Regards,
Peng