Hi,
I am switching all of my packaging efforts over
from fink to MacPorts and had a question which I
haven't quite found the answer to in the MacPorts
documentation. My initial attempt was going to be
a port of the molmol molecular modelling program.
The fink packaging script uses an
On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote:
I'm not sure it makes sense to symlink the manpages into the doc
directory. Manpages should be in the share/man directory so that the man
command can find them. Speaking of which, would the man command find
manpages in
On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote:
Ok, looks like a shell script with some variable substitution. MacPorts
portfiles have (more verbosely-named) variables for the same kinds of
things, but portfiles are Tcl scripts, not shell scripts.
Ryan,
One question on
I am having problems with the correct syntax for
adding checksums for multiple distfiles in a Portfile.
My first attempt so far at a new port looks like...
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
# $Id$
On Sat, Sep 12, 2009 at 09:14:34AM -0400, Jack Howarth wrote:
I am having problems with the correct syntax for
adding checksums for multiple distfiles in a Portfile.
My first attempt so far at a new port looks like...
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c
I have run into an issue that is unclear on MacPorts. In fink
we often would put placekeepers in a patch such as @FINKPREFIX@
and use the command...
sed 's|@FINKPREFIX@|%p|g' %{PatchFile} | patch -p1
to replace the @FINKPREFIX@ with the actual fink installation directory.
How do you handle
On Sat, Sep 12, 2009 at 07:38:12AM -0700, David Evans wrote:
Jeremy Lavergne wrote:
I have run into an issue that is unclear on MacPorts. In fink
we often would put placekeepers in a patch such as @FINKPREFIX@
and use the command...
sed 's|@FINKPREFIX@|%p|g' %{PatchFile} | patch -p1
I've done some more testing and the glw package in MacPorts
looks okay. Using the opensolar.c sample code from
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0640db=bkssrch=fname=/SGI_Developer/OpenGL_Porting/sgi_html/ape.html
I was able to build a working sample program that
Jeremy,
I've pretty much convinced myself that the breakage in molmol
is in the X support in MacPorts and not the build. I resorted to
a basic build of the molmol sources in /usr/local/molmol. In one
case I modified the makedefs file to use the MacPorts includes
and libraries (but nothing in
On Sat, Sep 12, 2009 at 03:45:54PM -0500, Ryan Schmidt wrote:
On Sep 12, 2009, at 05:52, Jack Howarth wrote:
On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote:
Ok, looks like a shell script with some variable substitution.
MacPorts
portfiles have (more verbosely-named
On Sat, Sep 12, 2009 at 05:08:01PM -0500, Ryan Schmidt wrote:
On Sep 12, 2009, at 16:53, Ryan Schmidt wrote:
So GLwMDrawA.h was expected but not found.
Ok, that's in the glw port, so add a dependency on port:glw. Now it
builds, and when I open it, I see some rather empty windows and a Tip
Is there a general conf setting I can change
so that port output is always verbose during the
build (or just a specific phase)? It is nice that
port spews out the compilation when a compile time
error is hit but while working up packaging I would
like to see the actual build in detail.
Is there anyway to prescan a Profile for validity?
In fink, there is 'fink validate foobar.info which
will report obvious syntax and policy errors without
building. Do we have anything like that in fink for
either the Portfile or packages produced?
Also, I noticed the proposed pymol
I was until a couple days ago the maintainer of the gcc4x packages in
fink. Looking at your broken gcc44 package I noticed some major lapses in
logic that is fouling the build and the multilib. The current packaging
doesn't pass explicit --host,--target and --build triplets to configure
yet
If anyone is wondering about the form of the patch to config.guess...
--- config.guess.orig 2009-09-12 20:13:05.0 -0400
+++ config.guess2009-09-12 20:14:07.0 -0400
@@ -1259,6 +1259,24 @@
*:Darwin:*:*)
UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
Can someone explain what I am doing wrong here? I find that
when I attempt to build...
# $Id: Portfile 57375 2009-09-10 08:16:41Z ryandes...@macports.org $
PortSystem 1.0
namegcc44
epoch 2
version 4.4.1
platforms darwin
On Sat, Sep 12, 2009 at 09:36:44PM -0400, Jeremy Lavergne wrote:
Does running tar jft indicate that this produces the directory build ?
It would seem the wrong directory is being extracted since you can't cd
to it.
On Sep 12, 2009, at 9:34 PM, Jack Howarth wrote:
/opt/local/var/macports
On Sat, Sep 12, 2009 at 09:36:44PM -0400, Jeremy Lavergne wrote:
Does running tar jft indicate that this produces the directory build ?
It would seem the wrong directory is being extracted since you can't cd
to it.
On Sep 12, 2009, at 9:34 PM, Jack Howarth wrote:
/opt/local/var/macports
Okay, you do have something else strange going on in the gcc44
package that I never saw in fink...
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-apple-darwin10.0.0/libgcc
configure: creating cache ./config.cache
checking for
On Sat, Sep 12, 2009 at 10:06:18PM -0400, Jack Howarth wrote:
Okay, you do have something else strange going on in the gcc44
package that I never saw in fink...
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-apple-darwin10.0.0/libgcc
configure: creating cache
On Sat, Sep 12, 2009 at 10:13:28PM -0400, Jeremy Lavergne wrote:
I'll have to think about this for awhile. From config.log in
/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/
build/x86_64-apple-darwin10.0.0/libgcc
something is passing CFLAGS='-g -O2 -arch x86_64'. You
On Sun, Sep 13, 2009 at 12:48:42PM +1000, Joshua Root wrote:
On 2009-9-13 12:06, Jack Howarth wrote:
something is passing CFLAGS='-g -O2 -arch x86_64'.
You commented out the clearing of configure.*_archflags...
- Josh
Josh,
The last posted Portfile change on the ticket fixed
What options do we have in the Portfile syntax to
to extract out the darwin release? On fink we used...
darwinvers=`uname -r|cut -f1 -d.`
in a bash shell script. I ask because the 32-bit
compiler build is unoptimized unless we manage to get...
if {[info exists build_arch] ${os.platform} ==
On Sat, Sep 12, 2009 at 11:45:47PM -0400, Jack Howarth wrote:
What options do we have in the Portfile syntax to
to extract out the darwin release? On fink we used...
darwinvers=`uname -r|cut -f1 -d.`
in a bash shell script. I ask because the 32-bit
compiler build is unoptimized unless
On Sat, Sep 12, 2009 at 11:52:40PM -0400, Jeremy Lavergne wrote:
On Sep 12, 2009, at 11:51 PM, Jack Howarth wrote:
but I need some syntax that will allow me to determine the numerical
darwin release there...ie darwin8, darwin9, darwin10, etc.
You can use platform darwin X blocks.
Okay
On Sun, Sep 13, 2009 at 03:24:24AM -0500, Ryan Schmidt wrote:
Jack,
Thank you for your willingness to help us fix things. I think you have a
much greater knowledge of compilers than I do, because a lot of your
comments are going right over my head. Is there a specific change you're
I should explain to everyone here the situation with
i386 fink on 10.6 and x86_64 fink on 10.5 so it is clearer
what is possible in packaging binaries of a different
architecture than the default and the costs involved.
Chronologically, i386 fink on 10.6 came first during
the Snow Leopard
After reading through the current MacPorts documentation, I am not
seeing any reference to the ability to set a specific version/revision
for particular dependencies in a Portfile. I can imagine a number of
instances were this could be a problem. For example, in fink
the gcc44 package has
On Sun, Sep 13, 2009 at 06:20:23PM +0200, Anders F Björklund wrote:
Jack Howarth wrote:
If MacPorts is willing to junk the idea of building i386 packages
as a default on 10.6, the config.guess fix is really the way to go.
When patched this way, all programs that use config.guess
On Sun, Sep 13, 2009 at 08:14:54PM +0200, Anders F Björklund wrote:
Jack Howarth wrote:
Anders,
Where exactly are the packages files created by port stored? I
don't
see anything obvious in /opt/local's subdirectories. Also, are the
architecture of the packages present
On Sun, Sep 13, 2009 at 09:12:40PM +0200, Rainer Müller wrote:
On 2009-09-13 20:37 , Anders F Björklund wrote:
ps I can imagine that this might in concept be solved by
requiring the user to do a selfupdate instead, however you
would still need a mechanism to stage the build order in
a
On Sun, Sep 13, 2009 at 10:41:38PM +0200, Rainer Müller wrote:
On 2009-09-13 21:30 , Jack Howarth wrote:
It certainly would be nice to have some sort of basic
version/revision tracker for at least the buiild process of
MacPort.
Of course I do not disagree that dependencies
On Sun, Sep 13, 2009 at 06:20:23PM +0200, Anders F Björklund wrote:
You probably want to fix the ${os.arch} as well,
since that will affect e.g. how packages are named:
set archive.file ${name}-${version}_${revision}${portvariants}.[option
os.arch].${archive.type}
set unarchive.file
Back to one of the first bugs I found in
MacPorts 1.8.0 when building test packaging for
the molmol molecular modelling program. I have
determined that the glw component is working
fine but have some concerns about the missing
gui widgets in the motif interface of molmol
being due to an
On Mon, Sep 14, 2009 at 02:44:23AM -0500, Ryan Schmidt wrote:
On Sep 14, 2009, at 02:03, Anders F Björklund wrote:
I guess that's what you get from upgrading on yearly rather than
weekly basis.
Yes, we must must must release new versions more frequently. :-/
On Mon, Sep 14, 2009 at 10:07:53AM +0200, Anders F Björklund wrote:
Ryan Schmidt wrote:
I guess that's what you get from upgrading on yearly rather than
weekly basis.
Yes, we must must must release new versions more frequently. :-/
Actually I meant *me* upgrading my packages, and it's
On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote:
This Ars Techica thread has a survey about package managers on Snow Leopard,
and an accompanying thread regarding some of these 64bit issues.
On Mon, Sep 14, 2009 at 11:02:08AM -0500, Ryan Schmidt wrote:
On Sep 14, 2009, at 11:00, Ryan Schmidt wrote:
On Sep 14, 2009, at 10:50, Jack Howarth wrote:
Actually one reason I asked the question was that
while trying to debug the problems I am seeing with
my test packaging of the molmol
On Mon, Sep 14, 2009 at 10:22:57AM -0400, Jack Howarth wrote:
On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote:
This Ars Techica thread has a survey about package managers on Snow Leopard,
and an accompanying thread regarding some of these 64bit issues.
http
On Mon, Sep 14, 2009 at 09:49:03AM -0500, Ryan Schmidt wrote:
We have the python_select script. Ideally ports would not require the
user to have selected a particular python, and would work with $
{prefix}/bin/python24 or whatever directly.
I believe the original idea was to avoid forcing
On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote:
On Mon, Sep 14, 2009 at 07:22, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote:
This Ars Techica thread has a survey about package managers on Snow
Leopard
On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote:
Our current approach (passing -arch) seems to be working fine - I
think both of your suggestions are bit heavy-handed considering *most*
ports work just fine with -arch flags.
- Toby
Toby,
I would also suggest reading...
On Mon, Sep 14, 2009 at 11:30:41AM -0700, Toby Peterson wrote:
On Mon, Sep 14, 2009 at 11:19, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote:
Our current approach (passing -arch) seems to be working fine - I
think both of your
On Mon, Sep 14, 2009 at 10:21:42PM +0200, vincent habchi wrote:
Le 14 sept. 2009 à 22:15, Daniel J. Luke a écrit :
On Sep 14, 2009, at 4:08 PM, vincent habchi wrote:
K64 makes no difference - config.guess uses uname -p, which is
i386 on
K32 and K64. The fact is that arch/uname aren't the
On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote:
On 2009-9-15 06:08, vincent habchi wrote:
K64 makes no difference - config.guess uses uname -p, which is i386 on
K32 and K64. The fact is that arch/uname aren't the correct tools for
determing the answer to this particular
On Mon, Sep 14, 2009 at 02:07:51PM -0700, Toby Peterson wrote:
On Mon, Sep 14, 2009 at 14:03, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote:
On 2009-9-15 06:08, vincent habchi wrote:
K64 makes no difference - config.guess uses
On Mon, Sep 14, 2009 at 02:08:41PM -0700, Toby Peterson wrote:
On Mon, Sep 14, 2009 at 14:03, Jack Howarth howa...@bromo.med.uc.edu wrote:
Apple decided to tether uname -m and uname -p to the kernel code
execution (hence this problem goes away when running the 64-bit kernel).
Also, as I
On Mon, Sep 14, 2009 at 02:30:49PM -0700, Toby Peterson wrote:
On Mon, Sep 14, 2009 at 14:28, Jeremy Lavergne
jer...@lavergne.gotdns.org wrote:
I don't think you're understanding me at all. If a project updates its
config.guess and things work fine with the new output, that's fine.
On Mon, Sep 14, 2009 at 05:28:32PM -0400, Jeremy Lavergne wrote:
I don't think you're understanding me at all. If a project updates its
config.guess and things work fine with the new output, that's fine.
However, changing MacPorts base would have many unexpected effects
that we'd be better off
In case any of the other MacPorts developers are
interested, I have uploaded proposed packaging for
pymol-1.2r1-1 on ticket #21376. Unlike the previously
proposed package on ticket #17419 which tried to use
the broken configure in pymol (that creates dylibs
instead of .so python modules), this
Reading through the commits on the configure.build_arch feature
in port, I am rather surprised that invoking that doesn't also
set the triplets for configure as well as passing the -m32 or
-m64 compiler flags. Wouldn't you at least want to set
--target= to the appropriate value so that
Could we please get an expert opinion on the proper
approach for handling the darwin10 targets with configure.
As darwin10 is a hybrid OS which runs a 32-bit kernel but
executes 64-bit binaries on EMT64 capable hardware, the reported
architecture returned by the current config.guess can
be in
On Tue, Sep 15, 2009 at 04:26:36PM -0700, Toby Peterson wrote:
On Tue, Sep 15, 2009 at 16:20, Jack Howarth howa...@bromo.med.uc.edu wrote:
Only booting the 64-bit kernel returns
coherency to the situation with uname and arch reporting x86_64.
This is not true. Jack, I've corrected you
On Tue, Sep 15, 2009 at 04:26:36PM -0700, Toby Peterson wrote:
On Tue, Sep 15, 2009 at 16:20, Jack Howarth howa...@bromo.med.uc.edu wrote:
Only booting the 64-bit kernel returns
coherency to the situation with uname and arch reporting x86_64.
This is not true. Jack, I've corrected you
On Tue, Sep 15, 2009 at 04:33:02PM -0700, Toby Peterson wrote:
Patch feedback:
(1) Wouldn't it be easier to grep the output of $CC -E -dM -xc /dev/null ?
Yes, that is what the gcc compiler developers wanted but Ben Elliston
objects since the -dM option is a gcc extension and wouldn't
On Tue, Sep 15, 2009 at 04:33:02PM -0700, Toby Peterson wrote:
(1) Wouldn't it be easier to grep the output of $CC -E -dM -xc /dev/null ?
(2) sysctl check is wrong, as that sysctl is exported regardless. I
suggest checking the output of sysctl -n hw.cpu64bit_capable, it'll
be 0 or 1.
On Tue, Sep 15, 2009 at 07:20:20PM -0400, Jack Howarth wrote:
+ else
+ if sysctl -a | grep -c hw.cpu64bit_capable/dev/null 21 ;
then
+ UNAME_PROCESSOR=x86_64
Please execuse the error in the previously posted patch...I grabbed an older
copy
On Tue, Sep 15, 2009 at 05:18:32PM -0700, Toby Peterson wrote:
On Tue, Sep 15, 2009 at 17:05, Mike Alexander m...@umich.edu wrote:
--On September 15, 2009 4:01:43 PM -0700 Toby Peterson t...@macports.org
wrote:
For the few ports that actually care, only --build makes any sense. We
don't
On Tue, Sep 15, 2009 at 08:21:20PM -0400, Mike Alexander wrote:
--On September 15, 2009 5:18:32 PM -0700 Toby Peterson
t...@macports.org wrote:
On Tue, Sep 15, 2009 at 17:05, Mike Alexander m...@umich.edu wrote:
--On September 15, 2009 4:01:43 PM -0700 Toby Peterson
t...@macports.org
On Tue, Sep 15, 2009 at 05:25:56PM -0700, Toby Peterson wrote:
No. From configure's perspective, cross-compiling means building for
an architecture that your build system can't run. A 64-bit Snow
Leopard machine can run x86_64, i386, and ppc (with Rosetta).
Normally...but name me another
On Wed, Sep 16, 2009 at 02:44:48AM +0200, Rainer Müller wrote:
On 2009-09-16 02:10 , Jack Howarth wrote:
On Tue, Sep 15, 2009 at 07:20:20PM -0400, Jack Howarth wrote:
+ else
+ if sysctl -a | grep -c hw.cpu64bit_capable/dev/null
21
I just finished porting the current apbs-1.1.0
packaging from fink to MacPorts. It works fine to
generate the electrostatic surfaces on molecules
in the pymol-1.2r1 packaging that I posted last
night. I haven't bothered yet to enable the python
support in abps yet. If anyone here has a
On Tue, Sep 15, 2009 at 11:52:35PM -0500, Bob Friesenhahn wrote:
On Tue, 15 Sep 2009, Jack Howarth wrote:
ps Isn't darwin10 the very first hybrid OS which the configure machinary has
been
faced with? I am unaware of any other operating systems that ever differed
the
architecture
On Wed, Sep 16, 2009 at 12:06:24AM -0500, Bob Friesenhahn wrote:
On Tue, 15 Sep 2009, Jack Howarth wrote:
Rainer,
Well taken. It really wasn't my idea to add that test. Ben wants to
decouple from having a c compiler. I'll mention this issue. Still I
think SL it will be a vast improvement
On Wed, Sep 16, 2009 at 09:00:46AM +0200, Anders F Björklund wrote:
Jack Howarth wrote:
Reading through the commits on the configure.build_arch feature
in port, I am rather surprised that invoking that doesn't also
set the triplets for configure as well as passing the -m32 or
-m64
On Wed, Sep 16, 2009 at 10:16:48AM -0400, Daniel J. Luke wrote:
... so relatively few ports, then?
The proposed change to config.guess only effects the
case where the architecture detected by 'uname -p' is
i386. In that case, the compiler code generation
is tested for __LP64__ being defined
On Wed, Sep 16, 2009 at 04:45:09PM +0200, Anders F Björklund wrote:
Passing a --target to configure is reasonable, and different from
patching config.guess to return something not from uname(1)...
(Maybe it changed in Snow Leopard, but it used to detect something
like i386-apple-darwin10.0.1
On Wed, Sep 16, 2009 at 08:38:50AM -0700, Toby Peterson wrote:
If you prefer how fink does things, go use fink.
I am just trying to involve the folks here in the
eventual changes implemented upstream so they everyone
has some feedback into this. It can only be helpful
if the autoconf folks
On Wed, Sep 16, 2009 at 09:47:39PM +0200, Anders F Björklund wrote:
It just seems that the value of `uname -p` isn't useful for
determining the true architecture of the Mac operating system,
whether it's on ppc-apple-darwin8 (that might run ppc64 too)
or i686-apple-darwin10 (that might run
On Wed, Sep 16, 2009 at 10:17:49PM +0200, Anders F Björklund wrote:
Jack Howarth wrote:
does that make more sense?
Not really (don't think I'd change --build but --target),
but then again Fink (or RPM) can do stuff their way...
It is my understanding that neither Apple nor MacPorts
is going
The attached patch for config.guess should cover all
of the bases for darwin10 and I've sent this to Ben
Elliston for review. If a system compiler exists, the
default triplet for on Intel darwin is set to the
default code generation. In the absence of a compiler,
if the system is on darwin10
I've noticed an oddity while building local ports
under MacPorts 1.8.0 with the archiving feature enabled.
It appears that if one is modifying the Portfile without
constantly bumping the revision number that the 'clean'
command is insufficient to purge the previous tgz archive
of the package.
I ported the sparky 3.115 NMR assignment program
using the same build approach from fink (where I
maintained the package). I am unclear on whether I
need to code the Portfile to support more than just
builds against tcl/tk 8.5 (which is what MacPorts
1.8.0 installed on my Snow Leopard box).
On Wed, Sep 16, 2009 at 10:52:33PM -0500, Ryan Schmidt wrote:
On Sep 16, 2009, at 22:41, Jack Howarth wrote:
I ported the sparky 3.115 NMR assignment program
using the same build approach from fink (where I
maintained the package). I am unclear on whether I
need to code the Portfile
I am starting to wonder if the breakage I am
seeing with my proposed molmol package isn't in
fact due to the usage of Mesa glut in MacPorts.
Why exactly are we using Mesa glut instead of
freeglut (which I thought almost all linux distros
had standardized on)? I will try creating a
freeglut
FYI, the config.guess change has been comitted to the
up
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
?
This is fine. I have committed it to the master git repository:
commit ccf975556a0f6797fe80395cd6f314682a770f15
Author: Ben Elliston b...@gnu.org
Date: Fri Sep 18 11:04:25 2009 +1000
2009-09-18 Jack Howarth howa...@bromo.med.uc.edu
* config.guess (*:Darwin:*:*): Handle 64-bit
Just a heads up for the gcc4x package maintainers here
that due to the P1 regressions in exception handling on
darwin10 for current gcc trunk (4.5), darwin may lose its
primary target status...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31
I have also discovered some things about
There is hope! We have an analysis of the exact
breakage in eh under 10.6 for gcc trunk...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html
The breakage in gcc trunk is due to the additional epilog
On Fri, Sep 18, 2009 at 11:46:57PM +, Eric Hall wrote:
On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote:
There is hope! We have an analysis of the exact
breakage in eh under 10.6 for gcc trunk...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
On Sat, Sep 19, 2009 at 12:19:38AM +, Eric Hall wrote:
On Fri, Sep 18, 2009 at 07:57:53PM -0400, Jack Howarth wrote:
On Fri, Sep 18, 2009 at 11:46:57PM +, Eric Hall wrote:
On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote:
There is hope! We have an analysis
On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote:
Given current reality, you're probably better off contributing to
llvm-gfortran... or better yet, a native fortran front-end for llvm.
FSF gcc is barely relevant on our platform these days.
- Toby
Toby,
I created the fink
Toby,
If you are interested, here are the
results for Polyhedron 2005 benchmarks
(the reference set used for testing
fortran compilers) for the x86_64
code generated by gcc 4.2.4 and
llvm-gcc 4.2.1's gfortran compilers
respectively on darwin9...
On Sat, Sep 19, 2009 at 03:03:58AM +0200, Olivier Le Floch wrote:
Is there a reason there's ongoing discussion of
gcc 4.x on a macports related list instead of on a gcc
list?
Seing as there are numerous math-related ports that depend on gcc-
related ports, I'd think raising this issue
On Sat, Sep 19, 2009 at 09:01:42AM +0200, vincent habchi wrote:
Jack,
http://www.nabble.com/x86_64-apple-darwin-Polyhedron-2005-benchmarks-td25108861.html
These figures are very interesting, but I don't understand why they lack
the gcc 4.2.4 -m64 performance; was that unavailable at that
On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote:
On Fri, Sep 18, 2009 at 17:43, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote:
Given current reality, you're probably better off contributing to
llvm-gfortran
Oh, I should clarify how I measure the first stable release.
Until about gcc 4.2, gfortran was in an unstable development
mode that exempted it from the normal commit rules (ie when
the gcc release was branched only commits for regression fixes
and bugs were allowed). It was in such a primordial
I am running into an issue with MacPort's that
seems rather odd. My system shell is set to tcsh
and and I have the normal entries in my .cshrc of...
##
# Your previous /Users/howarth/.cshrc file was backed up as
/Users/howarth/.cshrc.macports-saved_2009-09-11_at_18:03:54
##
# MacPorts
On Sun, Sep 20, 2009 at 05:12:57AM +, Eric Hall wrote:
Did you bother to check your PATH in those
terminal windows where things didn't work? If you
did, did it have /opt/local/bin:/opt/local/sbin
in it? If so, then that's a bit odd, but at a shell
and/or system level, not
On Sun, Sep 20, 2009 at 01:53:22PM -0400, Jeremy Lavergne wrote:
MacPorts was already installed, so the path was already available.
The problem is that after a rehash of the path, the new binaries weren't
available.
I have a question posted on fink-devel to try to find out
if the fink
On Tue, Sep 22, 2009 at 04:43:14PM -0500, Brian Barnes wrote:
Regarding the discussion about gcc 4.5.0 problems on darwin and the
back-and-forth between Toby and Jack:
I have just now caught up on this thread, and I want to echo my support
of pretty much everything Jack Howarth has said
On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote:
On Tue, Sep 22, 2009 at 14:43, Brian Barnes bcbar...@gmail.com wrote:
The llvm/clang community appears to have nobody / very few people interested
in implementing a Fortran front-end
Only one way to change that...
Toby,
I
On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote:
Or, perhaps let's hope that people exist with motive, means and
opportunity to contribute to gcc and keep it working on OS X, and are
able to do so. I would rather not lose future updates to the only fast,
free Fortran
On Tue, Sep 22, 2009 at 04:00:31PM -0700, Toby Peterson wrote:
On Tue, Sep 22, 2009 at 15:53, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote:
Or, perhaps let's hope that people exist with motive, means and
opportunity
On Tue, Sep 22, 2009 at 06:41:04PM -0500, Brian Barnes wrote:
Well, except for the fact that development of a llvm-based replacement
is not proceeding, no plans exist for it to proceed, would have to be
started from scratch, may not be free, and would take years... but
you're still
On Tue, Sep 22, 2009 at 05:13:22PM -0700, Toby Peterson wrote:
Still failing to see relevance here. I'm sorry that the gcc devs are
causing you this inconvenience, but the fact remains that gcc is not a
viable option moving forward. More importantly, it's not relevant to
this mailing list.
On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote:
Anyway, please go use Fink if you find MacPorts insufficient for your needs.
- Toby
Toby,
Do you realize how idiotic that response sounds. A rational answer would a
request
for more scientific ports. No, you treat this like
On Tue, Sep 22, 2009 at 05:27:52PM -0700, Toby Peterson wrote:
On Tue, Sep 22, 2009 at 17:24, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote:
Anyway, please go use Fink if you find MacPorts insufficient for your
needs.
Do
On Tue, Sep 22, 2009 at 08:32:01PM -0400, Eric Tiffany wrote:
At the risk of jumping into the middle of a dog fight... I only have a
peripheral interest in these issues, but I'd just like to ask:
Jack: what do you want the people on this list to do? I (for one) am
convinced that this is an
On Fri, Oct 02, 2009 at 08:06:31PM -0700, James Kyle wrote:
I've been working on the numpy and scipy ports for python26. I've
succeeded at accomplishing the following for both:
- default build against gcc43 toolchain
- default build links against macports atlas/lapack/blas libraries
1 - 100 of 264 matches
Mail list logo
