Re: numpy/scipy and mkl
Ryan Schmidt writes: >> On Jun 11, 2016, at 10:11 AM, Gideon Simpson >> wrote: >> >> I have an intel mkl license, and I know that numpy/scipy can be built >> against it for a performance boost. I was wondering two things: >> >> 1. Is it possible that we could have a variant of numpy/scipy that supports >> mkl, or is that fundamentally at odds with macports, since the mkl is >> commercial? > > I wouldn't be opposed to adding that option. MacPorts already contains > commercial software (like libxl, for which you must buy a license for certain > uses, and oracle-instantclient, which connects to a commercial database and > for which you must register and manually download the installer). I see there > are a number of ways we might get a copy of mkl for free to help us create > such a variant: > > https://software.intel.com/en-us/articles/free-mkl > > The question is whether all those packages contain the same or equivalent > software, such that a variant created for use with one of them would work > with the others as well. > > Another question is whether to code the variant to work with the files > installed by the Intel MKL installer in their normal locations, or whether we > should create a port for Intel MKL which would adjust the installation to > place the files inside the MacPorts prefix. This is quite challenging, actually. MKL would be a replacement for ATLAS or OpenBLAS, essentially but is insane to link against. You basically have to ask an Intel webapp for how to link with MKL: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor I could try to help if someone wants to go down this long rabbit-hole but I'm quite busy this summer. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: py-hgsubversion install fails
j. van den hoff writes: > on one of two machines (both running 10.10.5 and current `port') > installation of py-hgsubversion fails with (end of logfile): > > 8<-- > ... > CC='/usr/bin/clang' > CC_PRINT_OPTIONS='YES' > CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS' > CFLAGS='' > CPATH='/opt/local/include' > CXX='/usr/bin/clang++' > CXXFLAGS='' > F90FLAGS='' > FCFLAGS='' > FFLAGS='' > LDFLAGS='' > LIBRARY_PATH='/opt/local/lib' > MACOSX_DEPLOYMENT_TARGET='10.10' > OBJC='/usr/bin/clang' > OBJCFLAGS='' > :debug:build Assembled command: 'cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5" > > && > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 > setup.py --no-user-cfg build' > :debug:build Executing command line: cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5" > > && > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 > setup.py --no-user-cfg build > :info:build Traceback (most recent call last): > :info:build File "setup.py", line 106, in > :info:build from hgsubversion.svnwrap import svn_swig_wrapper > :info:build File > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py", > > line 198, in > :info:build commands.optionalrepo += ' svn' > :info:build AttributeError: 'module' object has no attribute 'optionalrepo' This seems like a mismatch with Mercurial. Which version do you have installed? Do you have Mercurial installed into /usr/local or something like that? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: py-hgsubversion install fails
j. van den hoff writes: > On Wed, 16 Mar 2016 19:41:39 +0100, Sean Farley wrote: > >> >> j. van den hoff writes: >> >>> on one of two machines (both running 10.10.5 and current `port') >>> installation of py-hgsubversion fails with (end of logfile): >>> >>> 8<-- >>> ... >>> CC='/usr/bin/clang' >>> CC_PRINT_OPTIONS='YES' >>> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS' >>> CFLAGS='' >>> CPATH='/opt/local/include' >>> CXX='/usr/bin/clang++' >>> CXXFLAGS='' >>> F90FLAGS='' >>> FCFLAGS='' >>> FFLAGS='' >>> LDFLAGS='' >>> LIBRARY_PATH='/opt/local/lib' >>> MACOSX_DEPLOYMENT_TARGET='10.10' >>> OBJC='/usr/bin/clang' >>> OBJCFLAGS='' >>> :debug:build Assembled command: 'cd >>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5" >>> && >>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 >>> setup.py --no-user-cfg build' >>> :debug:build Executing command line: cd >>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5" >>> && >>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 >>> setup.py --no-user-cfg build >>> :info:build Traceback (most recent call last): >>> :info:build File "setup.py", line 106, in >>> :info:build from hgsubversion.svnwrap import svn_swig_wrapper >>> :info:build File >>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py", >>> line 198, in >>> :info:build commands.optionalrepo += ' svn' >>> :info:build AttributeError: 'module' object has no attribute >>> 'optionalrepo' >> >> This seems like a mismatch with Mercurial. Which version do you have > > Mercurial Distributed SCM (version 3.7.2) > > $ which hg # ==> /opt/local/bin/hg > >> installed? Do you have Mercurial installed into /usr/local or something >> like that? > > no, I have not: everything is installed via macports. in fact, the problem > appeared during today's `sudo port selfupdate; sudo port upgrade outdated' > run. maybe the error is related to some other dependency? only guessing, > of course ... It must be picking up some python path because that error was introduced in aa73d6a5d9ea in hg: https://bitbucket.org/seanfarley/hg/commits/aa73d6a5d9ea But that commit was after the 3.7.2 release. Certainly strange. I wonder which path it's picking up. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: py-hgsubversion install fails
j. van den hoff writes: > if it helps, I'll type in everything you want (expect `/bin/rm -r' I mean > ;-)) to get more info and solve the issue. just let me know (possibly > off-list as well). My best guess at debugging would be to clean and extract the port: $ sudo port -v clean py27-hgsubversion $ sudo port -v extract py27-hgsubversion Then edit the file that has the stacktrace to print out all the python paths and modules (I forgot the variable names off the top of my head). After you've editing that (perhaps printing it to stderr), try to install again and hopefully it will print what it finds: $ sudo port -v install py27-hgsubversion Not sure what else to do besides that. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pypy 5.0.0 failing to build...
Carlo Tambuatco writes: > Uninstalling pypy @4.0.1_0 and installing pypy @5.0.0 seems to have done the > trick. > > What went wrong? It seems that pypy looks for an installed version. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pypy 5.0.0 failing to build...
Carlo Tambuatco writes: > Upgrading pypy @4.0.1_0 to pypy @5.0.0 fails with following error: > > Building pypy > Error: org.macports.build for port pypy returned: command execution failed > Please see the log file for port pypy for details: > > /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_pypy/pypy/main.log > Error: Unable to upgrade port: 1 > > Attached is the log file Ok, I added conflicts_build in r146539. Let me know if that works for you. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin on el capitan
Gideon Simpson writes: > Since vtk5 seems to be broken on el capitan, dolfin won’t install. Is it > possible to work around that? Is there a ticket for this? I have vtk5+python+tcltk installed just fine. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: py33-scipy problem
Jerry writes: > On Jan 21, 2016, at 9:20 PM, David Strubbe wrote: > > David, thank you for this explanation. Installing py33-scipy +gfortran > worked. However, I have these notes. > >> As the message says, you need to select a Fortran variant. You have not. You >> can see this from the fact that the file trying to be fetched is >> py33-scipy-0.16.1_0.darwin_13.x86_64.tbz2 not >> py33-scipy-0.16.1_0+gcc48.darwin_13.x86_64.tbz2. > > No, I can't see this because I'm not schooled in the arcania of MacPorts. I'm > just a semi-sophisticated user following the admonishment to update his > MacPorts installation. > >> Yes, you had py33-scipy +gcc48 installed previously, and macports will try >> to use the same variants you had selected before when upgrading. > > I never selected any variants; any installation of py33-scipy was handled by > the ports system. > >> However, there is no longer a variant +gcc48 (as below). Therefore, you must >> choose one of the four currently existing Fortran variants. e.g. sudo port >> install py33-scipy +gfortran. > > Why is this not handled automatically? If I can type sudo port install > py33-scipy +gfortran and the upgrade script recognizes the problem then why > can't the upgrade script handle it? > > I humbly submit that this is poor design, and wonder why it is not a bug. This is my fault and, indeed, a bug. I'll push a fix shortly. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IPython 4.0 and Jupyter in MacPorts
Fielding, Eric J (329A) writes: > I only use IPython occasionally, so I just now found out that the new version > of IPython 4.0 has major changes, and MacPorts has installed the new version > in one of my port upgrades. We used to run “ipython notebook” to get the > notebook version of IPython, but this has been removed and we are supposed to > use a new program called Jupyter. I installed what I guessed is required to > use Jupyter with port install py34-jupyter and py34-ipykernel. > > Is there something else I need to install to be able to run the new command > “jupyter notebook”? The “jupyter” program is not in my path. I found > /opt/local/bin/jupyter-3.4, but “jupyter-3.4 notebook” says it does not know > “notebook”. Looks like we need a `port select` group for the jupyter binaries. As for you issue, it appears to be this bug: https://github.com/jupyter/notebook/issues/448 which looks like the next release will fix. For now, you can run jupyter-notebook-3.4 (assuming py34-notebook is installed). > The Jupyter documentation > (http://jupyter.readthedocs.org/en/latest/install.html) says to use pip to > install Jupyter, but I understand that this will likely mess up the MacPorts > installation. Correct, please don't do that. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: New Mac OS Forge administrator
Ryan Schmidt writes: > Dear MacPorts users and developers, > > I'm pleased finally to be able to tell you that I have been hired to be your > new Mac OS Forge administrator. I have been involved in improving MacPorts > for years as a committer and as a manager, and now as a Mac OS Forge > administrator I will work on ensuring our infrastructure runs smoothly too. > > I apologize for the downtime we've experienced in the past months. My > priority right now is to resolve the existing issues, as I become familiar > with the systems. > > Please continue to report new problems with MacPorts infrastructure (server > not working) as you have before, using the server/hosting component in Trac > or via email to admin at macosforge dot org. And continue to report MacPorts > administrative issues (mailing list issues, commit access requests) to > portmgr at macports dot org. > > Thanks for your patience and support and thank you for using MacPorts. This is great for MacPorts! Congrats! ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts 2.3.4 has been released
Joshua Root writes: > The MacPorts Project is pleased to announce the release of version > 2.3.4. This is a bugfix release with small changes only. See the > ChangeLog [1] for the list of changes. Thanks man! ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: OS X 10.11 status
Dominik Reichardt writes: > Hi, > > I’m itching to switch but often need MacPorts. Do any of you have experience > yet with it *AND* MacPorts? Join the club :-( > In previous switches, I switched by using the development version of MacPorts > and following the migration steps of any major OS X upgrade, still the way to > go? Yep, still the way to go. Many things will have trouble building, fyi. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: ipython notebook problem
Peter Danecek writes: > Any news on this? > Or should I have a look at it? Ack, I completely forgot about this. If you can do it, that'd be great. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: ipython notebook problem
Peter Danecek writes: > Hi all, > should this thread become a ticket? > This issue was observed by a one of my colleagues as well. I have not YET run > into it. I was going to get around to doing it tonight at our python group meetup, if no one else got to it before then. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: ipython notebook problem
Gideon Simpson writes: > This appears to have something to do with the recent upgrade of > py27-jsonschema from 2.4.0 to 2.5.1. As soon as I downgraded this to the > earlier version, things ran as they had in the past. > -gideon Yep, it would seem there is a new dependency based on this commit: https://github.com/Julian/jsonschema/commit/e2a604f7ebc230e811ec6af15ac20551553b8a81 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin 1.5.0 and OS X 10.9
Gideon Simpson writes: > On one my machines I still have 10.9 installed and with the recent update to > dolfin (which works fine on my 10.10 machine), I now get errors during the > build: > > _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function > && /opt/local/bin/swig -python -module function -shadow -modern -modernargs > -fastdispatch -fvirtual -nosafecstrings -noproxydel -fastproxy -fastinit > -fastunpack -fastquery -nobuildnone -Iinclude/swig -DBOOST_UBLAS_NDEBUG > -DDOLFIN_SIZE_T=8 -DDOLFIN_LA_INDEX_SIZE=4 -DHAS_UMFPACK -DHAS_CHOLMOD > -DHAS_ZLIB -DHAS_MPI -DHAS_QT4 -DHAS_VTK -DNUMPY_VERSION_MAJOR=1 > -DNUMPY_VERSION_MINOR=8 -DNUMPY_VERSION_MICRO=2 > -DNPY_NO_DEPRECATED_API=NPY_1_8_API_VERSION -outdir > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function > -c++ > -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build > -I/opt/local/include -I/opt/local/include/QtGui -I/opt/ lo > cal/include/QtCore -I/opt/local/include/vtk-6.1 -I/usr/include/python2.7 > -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0 > -I/opt/local/include/libxml2 > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include > -I/opt/local/include/mpich-mp -I/opt/local/include/eigen3 > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include > > -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > -o > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function/modulePYTHON_wrap.cxx > > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/function/module.i > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/la/module.i:137: > Error: Unable to find 'dolfin/swig/la/docstrings.i' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/la/module.i:138: > Error: Unable to find 'dolfin/swig/nls/docstrings.i' > :info:build make[2]: *** [dolfin/swig/modules/la/modulePYTHON_wrap.cxx] Error > 1 > :info:build make[2]: Leaving directory > `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build' > :info:build make[1]: *** [dolfin/swig/modules/la/CMakeFiles/_la.dir/all] > Error 2 > :info:build make[1]: *** Waiting for unfinished jobs > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:78: > Error: Unable to find 'dolfin/swig/common/docstrings.i' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:79: > Error: Unable to find 'dolfin/swig/parameter/docstrings.i' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/common/module.i:80: > Error: Unable to find 'dolfin/swig/log/docstrings.i' > :info:build make[2]: *** [dolfin/swig/modules/common/modulePYTHON_wrap.cxx] > Error 1 > :info:build make[2]: Leaving directory > `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build' > :info:build make[1]: *** > [dolfin/swig/modules/common/CMakeFiles/_common.dir/all] Error 2 > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/mesh/module.i:160: > Error: Unable to find 'dolfin/swig/mesh/docstrings.i' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/dolfin/swig/modules/mesh/module.i:161: > Error: Unable to find 'dolfin/swig/generation/docstrings.i' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.5.0/build/d
Re: Processing of port freecad fails
Ryan Schmidt writes: > On Jan 9, 2015, at 1:34 PM, Sean Farley wrote: >> >> Ryan Schmidt writes: >> >>> On Jan 9, 2015, at 1:16 PM, Marius Schamschula wrote: >>>> >>>> freecad used to declare +gcc48 as the default variant until >>>> https://trac.macports.org/changeset/130949 was committed. Given that this >>>> change set deleted fortran related default variants for a number of >>>> packages, we will likely hear about these in the near future. >>> >>> Actually, in that revision, setting the default compiler variant was moved >>> from the individual portfiles to the compilers portgroup. >>> >>> Then in r130953 the default was changed from gcc48 to gcc49. But what about >>> the ports like freecad that don't have a gcc49 variant? >> >> Welp, that's unintended. In cases like these, I imagined portfile >> authors would override and add their own default variant. I'm a little >> busy now, so if someone feels encouraged they can add it back. >> >> A longer term fix would be to test for gcc49 and work backwards to >> gcc48, etc. >> >> Is there a reason why +gfortran was left out? > > My guess is that a gcc49 variant could be added to freecad and that it would > work fine. I guess gcc49 wasn't stable when freecad's default of gcc48 was > chosen. But if you're leaving it up to each port to decide which variants to > provide, then you have to either let each port decide which of them is the > default, or else have much more intelligent logic in the portgroup to pick > the "best" one as the default, and not make assumptions about which variants > exist. I agree. I'll update the portgroup accordingly. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Processing of port freecad fails
Ryan Schmidt writes: > On Jan 9, 2015, at 1:16 PM, Marius Schamschula wrote: >> >> freecad used to declare +gcc48 as the default variant until >> https://trac.macports.org/changeset/130949 was committed. Given that this >> change set deleted fortran related default variants for a number of >> packages, we will likely hear about these in the near future. > > Actually, in that revision, setting the default compiler variant was moved > from the individual portfiles to the compilers portgroup. > > Then in r130953 the default was changed from gcc48 to gcc49. But what about > the ports like freecad that don't have a gcc49 variant? Welp, that's unintended. In cases like these, I imagined portfile authors would override and add their own default variant. I'm a little busy now, so if someone feels encouraged they can add it back. A longer term fix would be to test for gcc49 and work backwards to gcc48, etc. Is there a reason why +gfortran was left out? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Yosemite buildbot?
Brandon Allbery writes: > On Sun, Oct 19, 2014 at 8:52 PM, Jason Mitchell > wrote: > >> Is there a buildbot in the works for Yosemite ports? I checked >> https://build.macports.org/buildslaves but didn't see anything for >> Yosemite yet. Maybe I've misunderstood the process, or am just being >> greedy? >> > > It was requested; they're waiting on Apple to provision it. Any update on this? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Installing Metis V4
Jeremy Lavergne writes: > It seems parmetis is still version 4.0.3. Unfortunately, parmetis is not the same as metis. George decided to keep two separate projects. I have done the leg work to make parmetis depend on metis. > On Oct 23, 2014, at 10:01 AM, L.Bryce Whitson Jr. wrote: > >> I have a need to install Metis V4 for a project that I am working on right >> now. I notice that the Metis in Macports is V5 and unfortunately the code I >> have won't compile under V5. Is there an easy way to install V4 using the >> Macports infrastructure? The upgrade isn't that bad, actually. Which project is this? If it's a C project, you can look at the SuiteSparse port to see how I patched it to work with metis 5.x. If it's fortran, take a look at mumps. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin & petsc
Gideon Simpson writes: > I have macports petsc 3.5.2 installed, and i tried installing sudo port > install dolfin +mpich +suitesparse +petsc +slepc. I got an error that looks > like there was some break in the functionality of Petsc, at least with regard > to dolfin: > > _opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.4.0/dolfin/la/STLFactory.cpp > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_dolfin/dolfin/work/dolfin-1.4.0/dolfin/la/PETScKrylovSolver.cpp:528:62: > error: use of undeclared identifier 'SAME_PRECONDITIONER' > :info:build ierr = KSPSetOperators(_ksp, _matA->mat(), _matP->mat(), > SAME_PRECONDITIONER); > > > The log file is a bit too large to attach. It looks like this is just outdated but I can't test because dolfin is currently broken due to scientific python (will be fixed in the next release). Either way, can you create a ticket for this so I can track it? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Error installing petsc
Daniel Watkins writes: > I attempted to install petsc using the command > sudo port install petsc +mpich +superlu +suitesparse > and was unsuccessful. The log file is attached. Ouch. This appears to be a compiler bug with clang. What OS and version of Xcode are you running? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin trouble
Gideon Simpson writes: > I did a port clean dolfin and port uninstall dolfin, and then followed it up > with sudo port install dolfin +gcc48 +mpich More than likely, it is this error: https://trac.macports.org/ticket/45157 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin issue
Gideon Simpson writes: > I did a port uninstall and a port clean, and I got the same error. Huh. I'll try to reproduce this, then. > I do have petsc/slepc installed with mpich, if that’s part of the problem. I > suspect that petsc is built as a C library, while dolfin is C++. Perhaps > that’s the incompatibility? It's perfectly fine to link C to C++. Dolfin has been doing this with PETSc for years. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dolfin issue
Ryan Schmidt writes: > On Sep 29, 2014, at 7:45 PM, Gideon Simpson wrote: >> >> I don’t seem to have that file > > Ok, looks like the compiler name is just being specified as "mpicc-mpich-mp", > without a path, and cmake is incorrectly inferring that it is in the build > directory. > > Do you have any of the mpich ports installed? > > port installed name:mpich > > Do any of them provide this file? The issue is that dolfin needs a clean configure. I don't know why it has trouble with this (do any cmake people know?). Try 'port clean dolfin' before attempting to build dolfin again. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: fortran compiler for f2py
Clemens Lang writes: > Hi, > >> Run "port select" to read the help message about the select mechanism. I >> would think it's also documented elsewhere in more detail, though not, >> apparently, via "port help select". > > It is, in 2.3.1, but not in trunk. See > > http://trac.macports.org/browser/branches/release_2_3/base/src/port/port-help.tcl > for the message you are looking for. I'm working on getting those manpages > written. Help very welcome. Quick question: is this going to finally remove the doc-new folder? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: can't upgrade py27-zmq
Comer Duncan writes: > I have today run across a failure to update py27-zmq. The output seems > non-instructive so I am hoping to get some help. I paste the output of my > attempt here: > > comermacpro:MarkFiniteDiffDerivativs comerduncan$ sudo port upgrade py27-zmq Ah, there's your problem: finite difference. All the cool kids use finite elements! ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts automake and python
Adam Mercer writes:
> On Thu, Mar 20, 2014 at 2:55 PM, Sean Farley wrote:
>
>> I tend to agree with you but need help seeing how this worked
>> before. What path did automake pick up before this change?
>
> If you look at the patch you can see the original paths:
>
> <http://trac.macports.org/browser/trunk/dports/devel/automake/files/patch-m4-python.m4.diff>
>
> The original paths are:
>
> AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
> AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
>
> Just to clarify this isn't the MacPorts prefix but the prefix for the
> running configure process.
Right, sorry, I meant more along the lines of:
Before: my project installed into /path/foo/a
After: my project installed into /path/foo/b
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts automake and python
Adam Mercer writes: > Hi > > Since automake was bumped to 1.14.1_1 it can't be used to build any > python software outside of MacPorts as it always tries to install the > python modules into MacPorts prefix. I understand why we want to > ensure that ports always installs modules into the MacPorts prefix, > but I can't understand why we would force this for everything using > MacPorts python. > > When I questioned this I was told that I should be using a non > MacPorts python if I don't want the modules to end up in the MacPorts > prefix? If that is the case what's the point of MacPorts? I was under > the impression that the goal of the project was to provide "an > easy-to-use system for compiling, installing, and upgrading either > command-line, X11 or Aqua based open-source software on the OS X > operating system". But now I'm getting told that I shouldn't be using > MacPorts but I should be installing things locally if I don't want to > install modules into the MacPorts prefix. > > This change seems like a very bad idea and is surely going to cause > problems down the line, in fact at work several users have already > been bitten by this. I tend to agree with you but need help seeing how this worked before. What path did automake pick up before this change? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: help on 'Xcode tool not installed'
Shiyuan writes: > Hi all, > I am on Mac 10.8.5 and Xcode 5.0.2 is installed. From Xcode > Preference/Downloads, I can see that the command line tool is installed. I > also installed again the command line too (released in 10/2013)l from the > following link > https://developer.apple.com/downloads/index.action# > > However, > when I try to run 'sudo port install py27-scipy', I got the error, > --- > Warning: The Command Line Tools for Xcode don't appear to be installed; > most ports will likely fail to build. > Warning: See http://guide.macports.org/chunked/installing.xcode.html for > more information. > ---> Computing dependencies for py27-scipy > Error: Dependency 'python27' not found. > To report a bug, follow the instructions in the guide: > http://guide.macports.org/#project.tickets > Error: Processing of port py27-scipy failed > > > I use svn instead of rsync for sources and `port -d sync` runs > successfully. > > Any help is appreciated. Have you accepted the license yet? This is the command: $ sudo xcodebuild -license ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: building my own ports of py27-matplotib and py27-numpy
On Thu, Nov 14, 2013 at 8:29 PM, Arturo Rinaldi wrote: > Il 15/11/13 01:37, Ryan Schmidt ha scritto: > > On Nov 14, 2013, at 15:27, Arturo Rinaldi wrote: > > Hi folks, I need some help to build my own port of these two packages. I > want to update them to their latest version (1.3.1 and 1.8.0 respectively) > and I was using as basis the original Portfile file, we all know that just a > few tweaks are necessary to achieve this goal. > > I only changed the version and the chekcsum in the Portfile, but it's not > enough….. > > That sounds like a good first step. Why didn’t it work? What error did you > receive? > > > > CRC error..there's a mismatch between the one detected by macports and > the one calculted by my checksum tool from the shell : > > $ shasum -a 256 numpy-1.8.0.tar.gz > > returns : > > 2764d0819acc77e9ff81b060fe7f69530b0d85c26ac9d162639b787cb227d253 > > for the tar.gz file which is not the one macpors asks for. I am attaching my > custom Portfile to show you my changes…. I've been busy with travel but am close to pushing the matplotlib changes (#40802). I'll look at the numpy changes soon as well. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Suggestion: Time to Use Trello?
On Wed, Jun 26, 2013 at 7:27 AM, Rainer Müller wrote: > On 2013-06-26 13:19, Rodolfo Aramayo wrote: >> Many projects out there are transitioning to trello >> >> https://trello.com/ > > What the heck does it do? The website tells me something about > organizing things. There seems to be an app, but also a web page, so is > it a service? Sorry, but I am unable to figure out what this is. > > Anyway, how would this be helpful in the context of using MacPorts? Changing topics a bit, has anyone here tried Phrabricator: https://phabricator.org It's the software used internally by Facebook and looks neat. It would aim at replacing the current Trac workflow. I've installed it on my own site to play around with and could configure it to link up with the macports subversion repo if anyone is interested in seeing it in action. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: emacs-mac-app port build failure
On Thu, Feb 14, 2013 at 4:04 PM, Lawrence Velázquez wrote: > On Feb 14, 2013, at 4:44 PM, Marion Dumas wrote: > >> I wanted to de-install and re-install Emacs on my mac (10.5.8). I >> de-installed Emacs.app by simply deleting the contents. I then downloaded >> the emacsformac dmg installer but it just doesn't work: the application >> crashes at launch. I tried installing through macports and it fails to build. >> >> Error: org.macports.build for port emacs-mac-app returned: command execution >> failed Please see the log file for port emacs-mac-app for details: >> >> Error: Processing of port emacs-mac-app failed > > You should file a ticket for this. Attach the main.log. > > http://guide.macports.org/chunked/project.html#project.tickets Yes, please do, Marion. That would help us keep track of issues with repository history. >> After that, I tried looking for other emacs related files on my computer in >> case they were conflicting with the new ones (so removing /usr/bin/emacs and >> /usr/share/emacs), but that didn't help. >> >> Thanks for any tips! I am befuddled > > You can start by ceasing your haphazard rampage through your system. You just > deleted the system emacs. Hope you didn't use "rm". Yes, totally agree with Lawrence here! ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: emacs-mac-app port build failure
Marion Dumas writes: > Hello, > > I wanted to de-install and re-install Emacs on my mac (10.5.8). I de- > installed Emacs.app by simply deleting the contents. I then downloaded > the emacsformac dmg installer but it just doesn't work: the > application crashes at launch. I tried installing through macports and > it fails to build. > > Error: org.macports.build for port emacs-mac-app returned: command > execution failed Please see the log file for port emacs-mac-app for > details: > > Error: Processing of port emacs-mac-app failed > > After that, I tried looking for other emacs related files on my > computer in case they were conflicting with the new ones (so removing / > usr/bin/emacs and /usr/share/emacs), but that didn't help. > > Thanks for any tips! I am befuddled > > I'm attaching the log file. Thanks for the report. It looks like I missed libxml, ncurses, and gnutls as dependencies. I'll try to get a fix out today (and also update to the newest version). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 8:25 PM, Lawrence Velázquez wrote: > On Jan 31, 2013, at 8:46 PM, Sean Farley wrote: > >> I just want to point out that this is where having a gui that is open >> source would really help: the responsibility wouldn't have to be >> shouldered by just one person. > > This is technically true, but GUI development is one broth that is *very* > easily spoiled by too many cooks. Yeah, that's a fair point. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 7:34 PM, Ian Wadham wrote: > On 01/02/2013, at 11:05 AM, Ryan Schmidt wrote: >> On Jan 31, 2013, at 16:53, Ian Wadham wrote: >>> I did "sudo port install -k -s pallet" >> >> Single-letter flags like -k and -s have no effect unless you put them >> immediately after the word "port". >> >> sudo port -k -s install Pallet > > Oops. That's what I actually "commanded" but not what I emailed. > >>> I am unfamiliar with both Objective C and the Macports structure … :-( >>> >>> However, I am familiar with C++, Qt and Qt Designer (a forms designer >>> and code generator for Qt-based GUIs). Is there a forms designer for >>> Mac, BTW? Hand-coding of widgets can be laborious ... >> >> Interface Builder. It's part of Xcode. >> >> http://en.wikipedia.org/wiki/Interface_Builder > > Thanks, Ryan. That looks good. It's not exactly lying around on the surface > in Xcode, though. FWICG, you have to use File->New… and ask for a XIB > file(?). > >>> Or maybe I could prototype in C++ and Qt while boning up on Xcode >>> and Cocoa … BTW I have OS X 10.7.5 Lion and Xcode 4.2.1. Would >>> those be OK as a platform, from Macports' point of view? >> >> Yes, but please update to Xcode 4.6. It's a free update for Lion or Mountain >> Lion users on the Mac App Store or at Apple Developer Connection. > > Will do. > >> My opinion is that cross-platform frameworks like Qt or wxWidgets or Java >> result in programs that don't look at home on any platform, especially not >> OS X which has a very specific interface design aesthetic, and which are >> also far larger and slower than if they had been written to the target OS >> directly. If cross-platform compatibility is your primary interest and you >> cannot afford to create separate native interfaces for each of your target >> platforms then so be it. But for a MacPorts GUI, which need only run on OS >> X, I strongly suspect that the best user experience will result from writing >> in Objective-C with Cocoa. > > I tend to agree in this case. No need for a Macports GUI to be > cross-platform. > > However, for me there is a learning curve to be climbed on Objective C, Cocoa > and Xcode. I don't know if I have the energy for that. I will be 75 next > month and > I wrote my first computer program about 50 years ago in Autocoder on a Ferrant > Sirius, which is now in a local museum. So don't expect too much … :-) I just want to point out that this is where having a gui that is open source would really help: the responsibility wouldn't have to be shouldered by just one person. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Using -std=c++11 with the macports gcc-4.7 compiler
On Wed, Jan 16, 2013 at 10:06 PM, Jeremy Huddleston Sequoia
wrote:
>
> On Jan 16, 2013, at 19:44, Sean Farley wrote:
>>>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>>>> dolfin.
>>>
>>> There are plenty of g++ bugs as well ;) … have you filed radars (or at
>>> least llvm bugzilla reports) about all of the clang issues you are finding?
>>> Can you point me to them?
>>
>> Unfortunately, 1) I didn't report them at the time (and can't
>> reproduce) and 2) some of the repos are private :-(
>
> With newer versions of clang, it will output the preprocessed source and a
> shell script to run to reproduce the issue with the preprocessed source. If
> it's not private, simply providing those two files (source and script) are a
> big help to the developers. If it is private, you can hopefully come up with
> a reduced test case within 10 minutes or so and submit that. Also, you may
> feel more comfortable submitting pseudo-private test cases to
> bugreport.apple.com rather than the llvm bugzilla as it will then be between
> you and Apple.
I did not know that. That's pretty awesome, actually. I'll have to
keep it in mind.
>>>> What makes this sentiment frustrating is the whole "use this
>>>> one version of the library with no optimization or debug control"
>>>> which is at odds with "try this library with {gcc,clang,etc.}'s
>>>> -O{1,2,3} and then write a paper about the results."
>>>
>>> I'm not really sure I know what you're referring to with the above sentence.
>>
>> Ah, I meant to explain the need for having multiple versions of a
>> library / program with different optimization levels for numerical
>> computation.
>
> Ok, so you're analyzing the effects of different optimizations or something …
> yeah… in that case, you can't really work around it by using a different
> compiler or optimization set because you want to test *THAT* set. That is
> certainly understandable. You're bound to run into bugs with any compiler at
> -O3 and above. Back when I was a Gentoo dev, I learned never to trust -O3
> and above, and that rule has served me well. Sometimes it's a corner case of
> a compiler bug, sometimes it's buggy source that "just works" without some
> strict optimizations… in general, if it's not widely tested, it's more likely
> to not work the way you want. I don't really have a good answer to give you
> to this problem, but a good first step is to always report the bug. Chance
> are you're one of a few people to ever trip over it based on your
> non-standard use case.
Agreed. We've filed many bug reports with Intel's compilers over the
years :-) In fact, Intel's -O3 _still_ crashes in some cases!
>>>> This actually was
>>>> my whole motivation for writing scienceports: provide a way to use a
>>>> library with gcc4X or clang3X and somehow manage the combinatorial
>>>> explosion of variants (the correct data structure, by the way, is a
>>>> DAG).
>>>
>>> How are you planning to manage the inherent difficulty with some clients
>>> using libstdc++ and libc++? It's possible for two separate libraries to
>>> use different C++ runtime versions so long as they're not passing objects
>>> back and forth, but most of the time, libraries that are implemented in C++
>>> provide C++ APIs to that library.
>>
>> You are right to point out that a DAG alone won't solve compatibility
>> issues. I just meant that it's impossible to do correct dependency
>> analysis without having (or having something isomorphic to) a DAG.
>
> Yeah, it would be great if dependencies were a nice tree, but they're not. =)
But! It is a graph! It's just sometimes a bad graph :-(
> Seriously though, if you're using C++ extensively in your ports, you should
> try intermixing some builds with clang++ using libc++ and see what happens.
> New symbol mangling will make interoperability difficult.
I have put off doing this due to time. I have some pure C++ projects
to incorporate in the next few weeks that might be good candidates.
> We may need to figure out a way to deal with this ABI compatibility issue in
> base … is there currently a way to query what configure.compiler was for
> another installed port?
I ran into this issue as well but couldn't find an easy answer. I
solved it by using custom variants, e.g. petsc +debug +gcc47, and then
writing my own tool to activate / deactivate all dependent ports of a
certain var
Re: Using -std=c++11 with the macports gcc-4.7 compiler
On Wed, Jan 16, 2013 at 9:32 PM, Ryan Schmidt wrote:
>
> On Jan 16, 2013, at 19:49, Sean Farley wrote:
>
>> On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia wrote:
>>>
>>> That being said, is there something wrong with clang++ that is causing you
>>> to try g++ instead?
>>
>> Jeremy, please understand that this is a frustrating position / stance
>> to have from the perspective of the user. In the scientific community,
>> it is *expected* to try out all the compilers you have access to.
>> Usually, this just means Intel, Portland Group, IBM, and gcc; but now
>> it also includes clang. Also, there are _tons_ of reasons that
>> projects use different compilers. The most common is fortran (don't
>> even get me started on Apple stripping out gfortran from gcc 4.2 AND
>> THEN providing a bogus mpif{77,90} wrapper). If your project has both
>> C++ and Fortran dependencies, then the only way to compile the Fortran
>> is to install gcc4X. Well, that usually means your configure script
>> will also pick up gcc4X's C/C++ compiler.
>>
>> The second most common reason I've seen is the one you mention: errors
>> in the C++ compiler. If Apple decides to update their Xcode clang
>> version to 3.1 or later anytime soon, then everyone on a mac will run
>> into this bug,
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14768
>>
>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>> dolfin. What makes this sentiment frustrating is the whole "use this
>> one version of the library with no optimization or debug control"
>> which is at odds with "try this library with {gcc,clang,etc.}'s
>> -O{1,2,3} and then write a paper about the results." This actually was
>> my whole motivation for writing scienceports: provide a way to use a
>> library with gcc4X or clang3X and somehow manage the combinatorial
>> explosion of variants (the correct data structure, by the way, is a
>> DAG).
>>
>> Ok, this rant is too long now. I hope no one is offended as I tried to
>> explain some of the science community's frustration.
>
> That's a valuable and valid viewpoint, and a totally reasonable answer to
> Jeremy's question. The need or want to compile some programs with different
> compilers or different compiler settings is a valid reason not to use clang.
> I'm guessing only a minority of our users are interested in that, and that
> only a minority of software would significantly benefit from such
> optimization, but that doesn't make it unimportant.
Thanks :-) There's a bit of a catch-22 here: most scientists don't use
macports because of the need to do this kind of operation; so there
could be more users that macports had. By the way, something like 90%
of the people working at Argonne have MacBooks (thank you, Taxpayers!)
You are right that most software wouldn't benefit from changing the
optimization level. It's even arguable about the numeric software but
that's another issue. Your domain is pretty much limited to dense
linear algebra or embarrassingly parallel data structures (e.g.
bioinformatics). That, of course, doesn't change people's minds that
they need it.
Anyway, if I understand it correctly, having multiple versions of a
library is basically equivalent to issue 126 :-) I was able to dance
around that issue by making a port group, though.
> But we must also understand Jeremy's viewpoint. You can see from his email
> address where he works. Clang is the compiler that OS X will use from now on;
> Xcode does not come with gcc anymore. So Apple clearly wants as much software
> to be compilable with Clang as possible, and wants to fix any bugs that are
> found with regard to that.
Sorry; I didn't mean to sound so critical. Perhaps it comes from the
long standing resentment about not including fortran and shipping a
broken mpi wrapper for two OS X versions :-( What I was more or less
trying to convey is the desire / need for easily switching compilers.
That will take much more discussion, though.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Using -std=c++11 with the macports gcc-4.7 compiler
On Wed, Jan 16, 2013 at 9:19 PM, Jeremy Huddleston Sequoia
wrote:
>
> On Jan 16, 2013, at 17:49, Sean Farley wrote:
>
>> On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
>> wrote:
>>>
>>> On Jan 15, 2013, at 8:52 AM, Sean Farley wrote:
>>>
>>>> On Mon, Jan 14, 2013 at 8:32 AM, David Barto wrote:
>>>>> fails because the /usr/lib/libstdc++.so is found first. What can I do to
>>>>> find the proper /opt/local/lib/libstdc++.so?
>>>>>
>>>>> I've not modified the search paths in any way, I'm just trying to compile
>>>>> a
>>>>> c++ program using the newer standard features.
>>>>
>>>> Hmm, I can't reproduce this error. Using no special environment
>>>> variables and just a vanilla install of gcc47 on Mountain Lion, I get:
>>>
>>>
>>>
>>> Yeah, all of the MacPorts gcc compilers should be using
>>> /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This
>>> should "just work" … if you're seeing something differnet, it would be
>>> helpful to see how ld is being called by the compiler. Run:
>>>
>>> g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v
>>>
>>> ---
>>>
>>> That being said, is there something wrong with clang++ that is causing you
>>> to try g++ instead?
>>
>> Jeremy, please understand that this is a frustrating position / stance
>> to have from the perspective of the user. In the scientific community,
>> it is *expected* to try out all the compilers you have access to.
>> Usually, this just means Intel, Portland Group, IBM, and gcc; but now
>> it also includes clang.
>
> Whoa … I'm simply asking if you're using g++ because you came across a bug in
> clang++ … there's no reason to get jumpy. I, myself, test with a huge
> variety of compilers in order to discover potential code generation issues
> before they effect average developers. Don't bite me for asking.
Apologies if that was too harsh. I didn't mean to sound like I was
biting back, but rather was trying to start a dialogue / point out a
different reasoning for multiple compilers. No offense / attack was
meant; sorry.
>> Also, there are _tons_ of reasons that
>> projects use different compilers. The most common is fortran (don't
>> even get me started on Apple stripping out gfortran from gcc 4.2 AND
>> THEN providing a bogus mpif{77,90} wrapper). If your project has both
>> C++ and Fortran dependencies, then the only way to compile the Fortran
>> is to install gcc4X. Well, that usually means your configure script
>> will also pick up gcc4X's C/C++ compiler.
>>
>> The second most common reason I've seen is the one you mention: errors
>> in the C++ compiler. If Apple decides to update their Xcode clang
>> version to 3.1 or later anytime soon
>
> XCode 4.5 (and I think 4.4) was based on llvm 3.1
>
>> , then everyone on a mac will run into this bug,
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14768
>
> The compiler distributed with Xcode has assertions disabled by default, so
> end users are likely to not trip over that assertion. What affect that
> actually has on generated code, I don't know… but thanks for pointing that
> out to me.
Ah, that would explain why there's no crash for the Apple compiler.
Thanks for explaining that.
>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>> dolfin.
>
> There are plenty of g++ bugs as well ;) … have you filed radars (or at least
> llvm bugzilla reports) about all of the clang issues you are finding? Can
> you point me to them?
Unfortunately, 1) I didn't report them at the time (and can't
reproduce) and 2) some of the repos are private :-(
>> What makes this sentiment frustrating is the whole "use this
>> one version of the library with no optimization or debug control"
>> which is at odds with "try this library with {gcc,clang,etc.}'s
>> -O{1,2,3} and then write a paper about the results."
>
> I'm not really sure I know what you're referring to with the above sentence.
Ah, I meant to explain the need for having multiple versions of a
library / program with different optimization levels for numerical
computation.
>> This actually was
>> my whole motivation for writing scienceports: provide a way to use a
>> library with gcc4X or clang3X and somehow manage the combinatorial
>> explosion of variants (the correct data structure, by the way, is a
>> DAG).
>
> How are you
Re: Using -std=c++11 with the macports gcc-4.7 compiler
On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
wrote:
>
> On Jan 15, 2013, at 8:52 AM, Sean Farley wrote:
>
>> On Mon, Jan 14, 2013 at 8:32 AM, David Barto wrote:
>>> fails because the /usr/lib/libstdc++.so is found first. What can I do to
>>> find the proper /opt/local/lib/libstdc++.so?
>>>
>>> I've not modified the search paths in any way, I'm just trying to compile a
>>> c++ program using the newer standard features.
>>
>> Hmm, I can't reproduce this error. Using no special environment
>> variables and just a vanilla install of gcc47 on Mountain Lion, I get:
>
>
>
> Yeah, all of the MacPorts gcc compilers should be using
> /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This should
> "just work" … if you're seeing something differnet, it would be helpful to
> see how ld is being called by the compiler. Run:
>
> g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v
>
> ---
>
> That being said, is there something wrong with clang++ that is causing you to
> try g++ instead?
Jeremy, please understand that this is a frustrating position / stance
to have from the perspective of the user. In the scientific community,
it is *expected* to try out all the compilers you have access to.
Usually, this just means Intel, Portland Group, IBM, and gcc; but now
it also includes clang. Also, there are _tons_ of reasons that
projects use different compilers. The most common is fortran (don't
even get me started on Apple stripping out gfortran from gcc 4.2 AND
THEN providing a bogus mpif{77,90} wrapper). If your project has both
C++ and Fortran dependencies, then the only way to compile the Fortran
is to install gcc4X. Well, that usually means your configure script
will also pick up gcc4X's C/C++ compiler.
The second most common reason I've seen is the one you mention: errors
in the C++ compiler. If Apple decides to update their Xcode clang
version to 3.1 or later anytime soon, then everyone on a mac will run
into this bug,
http://llvm.org/bugs/show_bug.cgi?id=14768
I personally have had clang++ bugs with libmesh, moose, armadillo, and
dolfin. What makes this sentiment frustrating is the whole "use this
one version of the library with no optimization or debug control"
which is at odds with "try this library with {gcc,clang,etc.}'s
-O{1,2,3} and then write a paper about the results." This actually was
my whole motivation for writing scienceports: provide a way to use a
library with gcc4X or clang3X and somehow manage the combinatorial
explosion of variants (the correct data structure, by the way, is a
DAG).
Ok, this rant is too long now. I hope no one is offended as I tried to
explain some of the science community's frustration.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Using -std=c++11 with the macports gcc-4.7 compiler
On Mon, Jan 14, 2013 at 8:32 AM, David Barto wrote:
> fails because the /usr/lib/libstdc++.so is found first. What can I do to
> find the proper /opt/local/lib/libstdc++.so?
>
> I've not modified the search paths in any way, I'm just trying to compile a
> c++ program using the newer standard features.
Hmm, I can't reproduce this error. Using no special environment
variables and just a vanilla install of gcc47 on Mountain Lion, I get:
$ g++-mp-4.7 -std=c++11 test11.cxx && ./a.out
Hello world
$ otool -L a.out
a.out:
/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.17.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
# shamelessly stolen from
http://www.cprogramming.com/c++11/c++11-lambda-closures.html
$ cat test11.cxx
#include
using namespace std;
int main()
{
auto func = [] () { cout << "Hello world" << endl; };
func(); // now call the function
}
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: running script error (eigen symmetric)
On Mon, Dec 17, 2012 at 3:46 PM, Amy Anderson wrote:
> Hi macport users,
>
> I am trying to run this script in python and the script is now working with
> the test data (eigen problem solved) but when I input my own data to be
> called by script I got the following errors.
>
> [moriaht-5:~/Desktop/pyClusterROI] moriah% python pyClusterROI_test.py
> tcorr connectivity subject2002.nii
>
> Traceback (most recent call last):
> File "pyClusterROI_test.py", line 89, in
> make_local_connectivity_tcorr( infiles[i], maskname, outname, 0.5 )
> File
> "/Users/moriah/Desktop/pyClusterROI/make_local_connectivity_tcorr.py", line
> 114, in make_local_connectivity_tcorr
> msk=csc_matrix((range(1,m+1),(iv,zeros(m))),shape=(prod(sz[1:]),1))
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/compressed.py",
> line 44, in __init__
> other = self.__class__( coo_matrix(arg1, shape=shape) )
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/coo.py",
> line 188, in __init__
> self._check()
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/sparse/coo.py",
> line 220, in _check
> raise ValueError('row index exceedes matrix dimensions')
> ValueError: row index exceedes matrix dimensions
>
>
> I was wondering if anyone might know what this error might mean or how to
> fix it?
Off the top of my head, no ideas besides the obvious "the index is
larger than the number of rows in the matrix" from the error message.
Since this error is coming from make_local_connectivity_tcorr, you'll
have to the authors of pyClusterROI.py to look into it, or better yet,
use a newer script (if available) from http://nipy.sourceforge.net.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Cairo Failed to Build
On Mon, Dec 10, 2012 at 12:01 AM, Jasper Frumau wrote: > Thanks Sean. Looking forward to the patch! Ok, I've just posted my patches to get it working here: https://trac.macports.org/ticket/37254 Hopefully, they can be tested and committed by a macports developer soon. Let me know if there are any other errors. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: py25-cairo Fails to build
On Mon, Dec 10, 2012 at 12:47 PM, Rodolfo Aramayo wrote: > I am experiencing problems building py25-cairo in all my computers > I am attaching the log file > Will wait for ideas before filing a bug report? This is due to py25-cairo needing to have an older version of py2cairo, as reported here: https://trac.macports.org/ticket/37254 I'm almost done with a patch now. Just testing it before submitting it. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Cairo Failed to Build
On Sun, Dec 9, 2012 at 11:55 PM, Jasper Frumau wrote:
> cairo failed to build. Here is the tail of the main log:
>
> tail -n 20
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/main.log
> :info:build ^
> :info:build SyntaxError: invalid syntax
> :info:build Command failed: cd
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/work/py2cairo-1.10.0"
> && /opt/local/bin/python2.5 setup.py --no-user-cfg build
> :info:build Exit code: 1
> :error:build org.macports.build for port py25-cairo returned: command
> execution failed
> :debug:build Error code: CHILDSTATUS 50928 1
> :debug:build Backtrace: command execution failed
> while executing
> "system -nice 0 $fullcmdstring"
> ("eval" body line 1)
> invoked from within
> "eval system $notty $nice \$fullcmdstring"
> invoked from within
> "command_exec build"
> (procedure "portbuild::build_main" line 8)
> invoked from within
> "$procedure $targetname"
> :info:build Warning: targets not executed for py25-cairo:
> org.macports.install org.macports.build org.macports.destroot
> :notice:build Please see the log file for port py25-cairo for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-cairo/py25-cairo/main.log
>
> Any idea why the command failed?
This is due to py25-cairo needing to have an older version of
py2cairo, as reported here:
https://trac.macports.org/ticket/37254
I'll send a patch for this hopefully tomorrow morning.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: ipython3 port not working ?
On Tue, Dec 4, 2012 at 12:25 PM, Trémouilles David wrote: > Maybe I was not precise enough. I meant py33-ipython > ipython version for python33. Are your running precisely > this version with the few patches you mentioned ? Yep, I understood. I still don't know how that path of yours got there /Volumes/macports/... and it looks like py33-ipython installs fine for me (and Chris). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: running script error (eigen symmetric)
On Mon, Dec 3, 2012 at 10:35 AM, Amy Anderson wrote:
> Dear macports-users,
>
> I am a new macports, python, and scipy user and I am looking for some help
> to troubleshoot an error I have been getting when trying to run a script in
> python. The script I am trying to run is called pyCluster ROI and it needs
> python, pynifti, scipy, and numpy to run. I have installed all these
> programs successfully using macports on Mac OS 10.8.
>
>
> I unarchived the scripts and ran the test script getting this error:
>
> $ python pyClusterROI_test.py
>
> Traceback (most recent call last):
>
> File "pyClusterROI_test.py", line 48, in
>
> from make_local_connectivity_scorr import *
>
> File
> "/Users/matthewnye/Downloads/pyClusterROI/make_local_connectivity_scorr.py",
> line 40, in
>
> from scipy.sparse.linalg.eigen.arpack import eigen_symmetric
>
> ImportError: cannot import name eigen_symmetric
>
>
> I have been trying to hunt down what this error may be and it seems that
> older versions of scipy might have used
> ‘scipy.sparse.linalg.eigen.arpack.eigen symmetric()’ where as new versions
> it has been renamed as "scipy.sparse.linalg.eigen.arpack.eigs()."
>
>
> Does anyone know what might be causing this error or if it is a version
> problem, is there any way to get an older version of scipy through macports?
> Also I have considered installing all these modules through a manual install
> but since i am a novice user I did not want to attempt that if there was a
> potentially simpler solution.
Woah, woah, woah now. Let's not go down the (more difficult) rabbit
hole of installing an older version of a port. For this issue, there
is a much easier solution (so please undo all the installations of an
older scipy, etc.). After scipy 0.9.0, the function 'eigen_symmetric'
was renamed to 'eigsh'. All you have to do is run,
$ perl -i -pe 's,eigen_symmetric,eigsh,g' *.py
in the pyClusterROI directory and you should get much further along.
Alternatively, attached is a patch if you would prefer that, which you
can run with,
$ patch -p1 < /path/to/eigen_symmetric.patch
For reference, I'm able to get to script to run on the test data and
produce subject{1,2,…,etc.}.nii.gz. Also, as a bonus, I was able to
get this pyClusterROI thing to work with the newer nibabel (which
replaces pynifty [macports devs:I'll create a ticket later today to
file these]). You can use the attached nibabel.patch to try it out.
Though, judging by the age of this script, you might find a suitable
replacement here (which is also where the pynifti replacement lives),
http://nipy.sourceforge.net
Hope that helps!
eigen_symmetric.patch
Description: Binary data
nibabel.patch
Description: Binary data
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: ipython3 port not working ?
On Mon, Dec 3, 2012 at 11:06 PM, Trémouilles David wrote: > Hello, > > Is ipython3 working for you ? I have a few patches that update ipython to 0.13.1 and correctly fixes a missing py-matplotlib dependency. That might be what you're seeing here, but I'm not 100% sure. (I'll be sending these patches tomorrow, hopefully) > I "sudo install py33-ipython" without any issue but > when I try to launch ipython3 I get an error: > ~ $ ipython3-3.3 > -bash: /opt/local/bin/ipython3-3.3: > /Volumes/work/macports/Library/Frameworks/Python.framework/Versions/3.3/bin/py: > bad interpreter: No such file or directory This looks odd to me: /Volumes/work/macports. You have /opt/local/bin/ipython3-3.3 installed but it's looking for something in /Volumes/.../macports? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: pandoc
On Sat, Nov 3, 2012 at 7:04 PM, Clemens Lang wrote: > On Sat, Nov 03, 2012 at 03:23:27PM -0400, Lenore Horner wrote: >> I see there is a ticket from a few weeks ago that may be related, but >> there's not closure or work-around suggested. >> https://trac.macports.org/ticket/36608 > > The solution is probably to update hs-utf8-string (and maybe pandoc, > too) to the latest version. This is necessary after updating ghc, which > we finally did a couple of weeks ago. > > I am aware of the problem but do not have time to solve it at the > moment. Feel free to provide a patch updating these broken ports (it > should be pretty straightforward if you start from a haskell-related > Portfile I recently updated, e.g., hs-HTTP). It was indeed pretty straightforward and I posted my changes here: https://bitbucket.org/seanfarley/scienceports/changesets/tip/keyword(%22pandoc%22)%20or%20keyword(%22hs-%22) Since it's 57 changesets, I'd rather not make all the tickets for them and would prefer if a macports developer could review them and merge them into macports-trunk. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Problem intalling Pandoc
On Fri, Sep 28, 2012 at 8:41 AM, Ryan Schmidt wrote: > > On Sep 28, 2012, at 06:27, Trémouilles David wrote: > >> ---> Fetching archive for hs-pandoc-types >> ---> Attempting to fetch hs-pandoc-types-1.8_0.darwin_11.x86_64.tbz2 from >> http://lil.fr.packages.macports.org/hs-pandoc-types >> ---> Attempting to fetch hs-pandoc-types-1.8_0.darwin_11.x86_64.tbz2.rmd160 >> from http://lil.fr.packages.macports.org/hs-pandoc-types >> ---> Installing hs-pandoc-types @1.8_0 >> ---> Activating hs-pandoc-types @1.8_0 >> Error: org.macports.activate for port hs-pandoc-types returned: command >> execution failed >> Error: Failed to install hs-pandoc-types > > Ok, so hs-pandoc-types failed to activate. Ryan, This is a deep rabbit hole, fyi. The gap between cabal and macports is non-trivial. I was able to get pandoc (and add a pandoc-devel port) that both work but since there are *so* many ports that are required to get pandoc to work, I've been lazy with filing the tickets for each one. I'll leave it to a macports dev to incorporate them [^1] :-) David, I don't know how comfortable you feel with using a local repository [^2] but feel free to try my repo [^3] out to get pandoc working for yourself. [^1]: https://bitbucket.org/seanfarley/scienceports [^2]: http://guide.macports.org/chunked/development.local-repositories.html [^3]: https://bitbucket.org/seanfarley/scienceports/wiki/Installation ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Mecurial
On Sat, Aug 4, 2012 at 11:35 PM, Phil Dobbin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > just a traceback further to this problem. Hope it helps: > > `$ hg log --traceback [snip] > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mercurial/demandimport.py", > line 58, in _load > mod = _origimport(head, globals, locals) > ImportError: No module named repo > abort: No module named repo!` This is all because of hg-git being out-of-sync with the new mercurial. It's fixed in the repo: https://bitbucket.org/durin42/hg-git/changeset/de618e24dcdd6cdb1fd1556b4789459e6e66a1b2 and I've updated my personal repo to use this dev version: https://bitbucket.org/seanfarley/scienceports/src/d65f56865e89/python/py-hggit/Portfile Though, ymmv. (I also had to update hgsubversion) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Oddity using Xcode 4.4 on OS 10.7.
> I'm curious if this is still happening. If anyone sees this issue when > initiating the install from XCode's preferences (*after* this email), please > let me know. I can try later this afternoon, if not before and let you (and the list) know. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Build Petsc with Shared Libraries
> I see that you use many variants in your Portfile. As a rule of thumb most > functionality should be enabled by default. Couldn’t most be enabled by > default (possibly as a default_variant)? Sure; I have no preference either way. My only note is that the --download-* options shouldn't be used for PETSc since that could lead to conflicting symbols. > I like your mpi PortGroup [1]. I can see that could be helpful for other > packages as well. Thanks :-) Yes, my goal with the MPI PortGroup was to unify the use of +gcc47, +mpi, etc. so that (hopefully) a portfile wouldn't need to specify any custom compiler variant (ala +gcc4X). I haven't decided on a nice way to specify that mpi is optional (similarly, how to specify fortran is optional). > Isn’t MPI support something that should be enabled by default for Petsc? It doesn't really matter one way or the other. If no MPI is specified to PETSc, then it will use its own internal MPI (via MPIUNI). > Is there any consensus within the MacPorts community on what should be the > default MPI implementation used in ports that require MPI? Good question. Due to the latest few releases of OpenMPI not being valgrind clean, PETSc recommends mpich2 (well, that and the fact that the mpich guys are on the next floor to the petsc team). Following up with mpi, it should be noted that lam, lammpi, and mpich are all deprecated (and should be removed / replaced_by). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Build Petsc with Shared Libraries
> Sean, it's up to the maintainers of those ports as to whether they would like > to incorporate your changes, and for the petsc port, I would encourage you to > file a bug report with a diff with these changes and explanations about why > the changes need to be made. That actually was my plan but most of the time when I interact with the MacPorts devs, I never hear back: https://trac.macports.org/ticket/33889 http://lists.macosforge.org/pipermail/macports-dev/2012-May/019203.html https://trac.macports.org/ticket/34831 https://trac.macports.org/ticket/34846 https://trac.macports.org/ticket/34933 As a new person to the MacPorts scene, I've found that it's mostly discouraging to try to submit patches for discussion. > In the case of our metis and SuiteSparse ports, they have no maintainers. You > can still file tickets with diffs and someone will review them and commit > them eventually. If the tickets don't get addressed in a timely manner you > can ping the macports-dev mailing list to remind us. > > None of the other ports you mentioned exist in MacPorts at this time. You > would be welcome to contribute your ports to us by filing tickets in the > issue tracker as usual. Note that for parmetis a port has already been > submitted; you could see if that one is the same as yours, or if not, submit > an updated version there: > > https://trac.macports.org/ticket/20844 How is a three-year old ticket that never got reviewed suppose to encourage someone that the MacPorts devs will even bother to respond? I would love to one day submit all my patches for review but I just don't have a clear message from the MacPorts community that the patches would even be reviewed; much less, constructively reviewed. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Build Petsc with Shared Libraries
> The libraries have not been linked correctly. I assume the first line in
> otool -L /opt/local/lib/petsc/lib/libpetsc.dylib contains the
> worksrcdir, which causes this issue when linking against it.
>
> Please file a bug so the maintainer can fix this.
The PETSc portfile is very wrong, particularly with the prefix
install. I've been meaning to submit a diff but for the time being,
here my own PETSc portfile that I use:
https://bitbucket.org/seanfarley/scienceports/src/5b57adccee2f/math/petsc/Portfile
Notable things that need to be fixed in the MacPorts version:
* don't use both --with-c-support and --with-c++-support
* unnecessary to use --with-python
* don't use --with-pic
* don't use --with-mpi=1
* don't pass ${destroot} to --prefix
* don't pass mpi compiler wrappers to --with-{cc,cxx}; just use
--with-mpi-dir=${prefix} (the correct compilers will be used based on
that)
* don't ever mess with blas/lapack options
* don't pass things to --LIB
If the devs at macports want, they could update metis, parmetis,
blacs, scalapck, mumps, ml, and SuiteSparse to my ports located at
bitbucket; they are the same ones that are used for
--download-{metis,parmetis,blacs,scalapack,mumps,ml,umfpack} and, as a
bonus, are all updated to the latest versions.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: gfortran with Xcode 4.3.2 unreliable
> There was a thread ~1 month ago regarding gfortran that was acting > strangely. Here's a link to that > thread: http://lists.macosforge.org/pipermail/macports-dev/2012-May/019098.html > > I haven't seen any responses or anything to this, and I was wondering if > anyone else had run into issues trying to use gfortran from any of the gcc4X > builds using Xcode 4.3.x on Lion. > > There seems to be something *seriously* wrong with the Fortran compiler > built with MacPorts -- in a very Fortran-heavy program suite, nearly half of > the tests are suddenly failing when built with these compilers even after > the selected_real_kind() issues are resolved. And the failures are not > blatantly ridiculous, they're subtle, but currently I'm wary of trusting > anything the MacPorts-built GCC compilers (at least the Fortran compilers) > spit out. Yes, you are correct that this is seriously wrong and very subtle. The issue is with gmp and causes gfortran to erroneously double the size of (at least) ints. I opened a ticket here with a patch: https://trac.macports.org/ticket/34491 that fixes the gmp issue and also fixes debuggers loading shared symbols; but haven't heard back from the macports devs at all on the issue. You should be able to apply the patch yourself and rebuild everything from source with the -s option: $ sudo port uninstall --follow-dependents gmp $ sudo port -vs install gcc47 or whichever gcc you have installed. Hope that helps! ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Trying to install ld64 port from source, but binaries installed instead?
> Right. We never really announced the availability of binaries, but they've > been available for Snow Leopard since last year and Lion since this year. > > Is there a reason why you want to build ld64 from source -- is there > something wrong with the binary on our server? If so, we need to know so we > can fix it. I can't speak for Tim, but I've pointed out that at the very least the gmp binary is wrong on the macport server: http://lists.macosforge.org/pipermail/macports-dev/2012-May/019098.html I'm not sure if ld64 is a root cause of this or not but this gmp issue is one major wrench for distributing gcc compilers (not to mention the missing .dSYM) files. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Trying to install ld64 port from source, but binaries installed instead?
> I just tried to "port install ld64", and instead of compiling from source, > it downloads a .tbz2 package from packages.macports.org which contains the > binaries. I guess I thought macports always built from source unless you > added "pkg" to the port command? Thanks for any help. This is a newer change; you'll need to add the '-s' option to signify that you want to build from source. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
re: strange gfortran problem
(cc'ing macports-dev) > The problem is actually with MacPorts 4.3.2. A little more accurately, this > is NOT an actual bug. The problem is that the behavior you are seeing is > allowed under the Fortran standard -- that's why selected_int_kind exists in > the first place. This is wrong. The Fortran standard, and in particular gfortran, call for the *smallest* integer type: http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fINT_005fKIND.html For selected_int_kind(5), this *must* be INTEGER*4 (4 bytes = 32 bits; pow(2,32)/2-1 will suffice 5 for digits) > I had to issue a patch for a piece of software that used > selected_real_kind(), but assumed that it would always return 8 as used. From > all the searching I did, I found that this behavior was perfectly within the > Fortran standard, and that we had to become compliant with it. > > My suggestion is to avoid roll-your-own precision to avoid problems like > this. If you need to use it, make sure you always use the enquiry intrinsics > (selected_real_kind and selected_int_kind), and never assume it will take a > particular value. That's what this piece of software does, actually (uses select_*_kind). > To reiterate, this behavior ONLY arose when I built all my ports with Xcode > 4.3.2, and never with older Xcodes (that is, if I built gcc4x with Xcode > 4.3.2, it would happen regardless of which FCC I built). > > I agree the behavior differs in my experiences with Linux, but there are > other OSes and compilers that behave differently as well (or so I read) There is a bug here but it's not with gcc / gfortran. It appears to be gmp; and it seems to occur when missing the 10.6 sdk. I don't know why it happens, but that look like the common failure (i.e. using MacPorts's gmp generated from the buildbot will expose this bug). Or it could be the +universal logic in the gmp Portfile. For my machine, I have the 10.6 sdk so I needed to uninstall gmp and build it from source (using the -s option): $ sudo port uninstall --follow-dependents gmp $ sudo port -vs install gcc47 (or gcc46, gcc48; all gcc ports experience this bug with gmp) This really, *really* needs to be fixed on the buildbot. Is there any particular reason the buildbot doesn't have the 10.6 SDK? The test case is easy to see with Victor's attached fortran test (which I reattached to this email). The output should be: $ ./a.out int4:4 int8:8 Are there any other macport devs that can test building gmp / gcc47 on their local machine to see if the output matches (e.g. just run my two above command that uninstalls gmp and its dependents, then install gcc47 and its dependencies from source)? Also, it would be nice if all compilers included their debug symbols (i.e. run dsymutil *.dylib in the destroot phase) which I put a patch here: https://trac.macports.org/attachment/ticket/33821/base-create-dsym.patch This would stop millions of warnings when using gdb with *anything* compiled by one of the compilers provided by MacPorts. The impact of including the .dSYM files is extremely low but saves so much frustration on the users. sizeof-ftn.f90 Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
