Re: Linking 'gfortran' command to compiler in gcc43
On 2010-10-07 03:37 , Mark wrote: 1) What is the difference between gfortran vs gcc vs gfortran-mp-*.*? GCC is the Gnu Compiler Collection. It contains compilers for C, C++, Objective-C and others. As that is a modular approach, not everything is always included. For example, Apple does not ship gfortran or gcj with the gcc included in Xcode Developer Tools. 2) If nothing, why do people download gfortran? See above. 3) Since gcc comes with the mac's developer tools, why use macports (is it because it's easier to keep up to date). MacPorts provides newer versions of gcc than Apple (due to a license change to GPLv3). But Apple's version is also highly patched (for example it accepts multiple -arch settings at once). 4) Finally, what's the best course of action in terms of getting rid of clutter and having the best compiler(s)? If you do need gfortran you have to install one of the MacPorts provided gcc versions as Apple does not ship it. Otherwise, Apple's compiler shipping with Xcode Developer Tools is the best choice for Mac OS X. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gedit
On 10/6/10 1:59 PM, Ryan Schmidt wrote: I don't know what to say about the theme icon message. This is also a warning message only and can be safely disregarded. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Mailman/Postfix and the dreaded group mismatch
Hi folks,
I'm putting some of the final touches on my most recent server and
have run into the dreaded Mailman group mismatch problem.
Before getting into that though, I'm curioius as to why MacPorts
spreads the pieces of Mailman around to at least three different
locations - /opt/local/var, /opt/local/share, and /opt/local/libexec
- rather than in one convenient location as the 'normal' mailman
installs do? I can't see a whole lot of advantage to doing that
besides confusing those of us who are transitioning from a
non-MacPorts install.
Down to the problem. We're running the latest OS 10.6 (client). I'm
using Fetchmail (MacPorts install) to retrieve the mail from the 3rd
party server and deliver it to Mailman, and then sending out via the
existing Postfix server. The error I'm seeing when running
Fetchmail is:
fetchmail: IMAP A0008 OK Success
fetchmail: IMAP A0009 FETCH 2 BODY.PEEK[TEXT]
Group mismatch error. Mailman expected the mail
wrapper script to be executed as group _mailman, but
the system's mail server executed the mail script as
group staff. Try tweaking the mail server to run the
script as group _mailman, or re-run configure,
providing the command line option `--with-mail-gid=staff'.
fetchmail: IMAP * 2 FETCH (BODY[TEXT] {25}
(25 body octets) *
and though it appears that fetchmail is logging in correctly and
seeing the mail there, it's not downloading to Mailman because of the
mismatch.
I went into the Mailman portfile and added --with-mail-gid=staff to
the configure, port uninstalled and reinstalled. I'm still getting
the same error. Do I need to do something else to 'clean' the
install of the old settings?
Or do any of you know what to change on the Postfix end in order to
tweak the mail server to run the script as group '_mailman'?
Thanks in advance.
--
Bill Christensen
http://greenbuilder.com/contact/
Green Building Professionals Directory: http://directory.greenbuilder.com
Sustainable Building Calendar: http://Calendar.SustainableSources.com
Green Real Estate: http://www.greenbuilder.com/realestate/
Straw Bale Registry: http://sbregistry.greenbuilder.com/
Books/videos/software: http://bookstore.greenbuilder.com/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
missing build dependency on sbcl
Hi, my attempted upgrade of s...@1.0.42_0+html to 1.0.43_0+html failed due to a missing build dependency on some texlive port. More precisely, I do have texlive installed but not via macports; therefore the build did not find the required texi2dvi. (I know macport's policy that it does not rely on software installed by other means.) The sbcl portfile does not declare this dependency and therefore the missing dependency was not installed; rather the build failed. I filed ticket #26762 for this issue. Regards, Christoph -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Messed up Perl
How is having a *_select problem going to be easier for people than using the full path to the binary they want or having the user modify their $PATH to do what they want? Because the select is done by macports when installed; the user just runs the program, and now gets the macports version. What you're not understanding is that the situation you are describing is the minority situation. Your proposal is to change things to make it work the way you want at the expense of everyone who wants it to work the other way. From experience for the project, many more people are confused by the way you describe than are confused by the way it is now. If you have an idea that doesn't involve inconveniencing the people who like the 'it just works' nature of the current solution, then I for one would be excited. There are, fundamentally, three types of programs. 1. Programs that I want installed from Macports, where I want the macports to override the system. 2. Programs that some other program wanted installed, where that program explicitly calls the new one; I don't want the system program overridden by default. If I want it overridden, I'll explicitly request installing that program. 3. Programs that came with the system. In general, if I have something working, then I have something working. You seem to be saying that you want the authority to change something/anything in my environment that I did not ask, want, or know would be changed. What I am saying is: Class 2 (programs installed by something as a dependency) should not override the system by default. If I say port echo requested, and it doesn't show up, give me the system version. What you are saying seems to be: We did this before, before we had a way to track what was requested. We get very few complaints, so most people must prefer this way. So first, am I understanding you correctly? That few complaints are received, and the assumption is that few complaints means Preferred, rather than acceptable? If not, then let me turn this around: Is there a reasonable way to let program X installed dependency Y, and yet still let me use system version of Y? Python is complex enough that there is an explicit select package for it. Apparently the same is true for gcc (based on what I've seen come across the list; I haven't installed a new gcc from macports). Now it seems that Perl is a known complex and every packaging system has to deal with this, which gets right back to needing a select thingie for it. If you have an idea that doesn't involve inconveniencing the people who like the 'it just works' nature of the current solution, then I for one would be excited. Plain and simple: Want to use macports Y by default when it's currently just a dependency? sudo macport setrequested Y. Because now you are requesting it. Let all the complexities of package_select be handled for the normal, default case by macports. Install a new python? Fine, python_select it by default. Install a new perl? Fine, perl_select it by default. Install a new svn? Fine, svn_select it by default. Install wonder_utility that wants perl-oddball-special_hooks? Don't change the default perl. -- Political and economic blog of a strict constitutionalist http://StrictConstitution.BlogSpot.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Messed up Perl
On Oct 7, 2010, at 9:53 PM, Michael_google gmail_Gersten wrote: If not, then let me turn this around: Is there a reasonable way to let program X installed dependency Y, and yet still let me use system version of Y? Do you have an idea? You have written several long emails, but I haven't seen an idea on how to do this any better than the way things are. If you have an idea for how to make it work, we're happy to hear it. Python is complex enough that there is an explicit select package for it. Apparently the same is true for gcc (based on what I've seen come across the list; I haven't installed a new gcc from macports). Now it seems that Perl is a known complex and every packaging system has to deal with this, which gets right back to needing a select thingie for it. except that a 'select thingie' won't work unless (like python) we also have a duplicate every p5-* port for each version of perl. If you're volunteering to maintain all of them, then I guess that's a possibility ;-) If you have an idea that doesn't involve inconveniencing the people who like the 'it just works' nature of the current solution, then I for one would be excited. Plain and simple: Want to use macports Y by default when it's currently just a dependency? sudo macport setrequested Y. Because now you are requesting it. Let all the complexities of package_select be handled for the normal, default case by macports. Install a new python? Fine, python_select it by default. Install a new perl? Fine, perl_select it by default. Install a new svn? Fine, svn_select it by default. so each port gets a 'select' that only gets run some of the time? And every piece of software gets patched to look for the non-select'ed file (or look in some place that isn't in $PATH)? ... or you could just remove the $PATH modification that Macports put there. (one of these solutions seems simpler). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
