Hi,
I'm the maintainer of the ode package, which has had a history of
problems related to shlibs [1]. Luckily, ode now uses libtool, and it
also fixes a problem that was preventing successful builds on Leopard,
so I thought I'd hit two birds with one stone and upgrade Fink's
package for
On Sat, Jan 24, 2009 at 04:29:23PM -0500, Trevor Harmon wrote:
Hi,
I'm the maintainer of the ode package, which has had a history of
problems related to shlibs [1]. Luckily, ode now uses libtool, and it
also fixes a problem that was preventing successful builds on Leopard,
so I
On Jan 24, 2009, at 4:29 PM, Trevor Harmon wrote:
Hi,
I'm the maintainer of the ode package, which has had a history of
problems related to shlibs [1]. Luckily, ode now uses libtool, and
it also fixes a problem that was preventing successful builds on
Leopard, so I thought I'd hit
On Jan 24, 2009, at 5:33 PM, Daniel Macks wrote:
The validator messages and otool-L are all self-consistent: the
problem (and it *is* a problem) is that the lib is coded as if it
exists in /opt/ode instead of in %p.
Actually, the reason why otool reports /opt/ode is most likely because
I
On Jan 24, 2009, at 5:54 PM, Daniel Johnson wrote:
There are a couple of problems here. You have too many packages.
There only needs to be a -dev and a -shlibs package. The unnecessary
ode package only contains 2 files: libode.1.0.0.dylib, which needs
to be in ode-shlibs and libode.la,
On Jan 24, 2009, at 7:33 PM, Trevor Harmon wrote:
On Jan 24, 2009, at 5:54 PM, Daniel Johnson wrote:
There are a couple of problems here. You have too many packages.
There only needs to be a -dev and a -shlibs package. The
unnecessary ode package only contains 2 files:
In case anyone is interested, here are the improvements
we see in the Polyhedron 2005 fortran benchmarks in the
various gcc releases in fink (as measured on a MacPro).
gcc release
gcc 4.2.4 gcc 4.3.3gcc 4.4-pre gcc 4.3.3/ gcc 4.4-pre/
On Jan 24, 2009, at 10:15 PM, Daniel Johnson wrote:
libode.dylib needs to go in the dev package, not shlibs. It appears
that nothing currently depends on ode, yes? If so, I'd suggest
removing the ode-dev splitoff entirely, leaving all the dev files in
the main ode package. Make it
I forgot to mention that all of those gcc polyhedron 2005
benchmarks are for -ffast-math -funroll-loops -msse3 -O3.
Jack
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell
