That might change! while my skills in the compile-SW improves, EG. For the moment that benefit is worth more to me than the loss of diskspace etc. configureĬompiles clean in 10.5 with gcc 4.3.3 I got your first error until I put FFLAGS in.My main reason to use a packagesystem is to benefit from the totally seperate directory - EG have it totally seperate from the APple-installed stuff. When I run configure on that (using the correct framework and 64-bit flags I get:ĬFLAGS="-m64" FFLAGS='-m64' LDFLAGS='-m64 -framework vecLib'. Without any flags I get:Ĭhecking for sgemm_ in -lcomplib.sgimath. This does not happen when I try it without the 32-bit flags, so it looks like something is wrong with the configure script. When I run configure on that (using the correct framework and 64-bit flags I get:Ĭhecking for unknown in -lcomplib.sgimath. Meep itself does not use any fortran, but it is a side library called harminv which I need to compute flux spectra. Yeah I needed to compile guile myself too. When I moved to Leopard I couldn't get that to build from Macports so I've been using self-compiled versions since then. However my code, like Meep, uses Guile, so the Guile libraries and their dependences (mpfr, gmp) must be compiled for x86_64. The compiler itself hasn't given me many problems because whether it is 32 or 64 itself, it can compile for x86_64 by passing -m64. (The main program is in C++.) Maybe something like CFLAGS=-m64 LDFLAGS=-64 -framework vecLib -lgfortran. The flags I need are -m64 to compile (for both gcc and gfortran) and -m64 -framework vecLib -lgfortran to link. My code has some pieces in Fortran and I've been building it for 64 bits since Tiger. I know I managed to do this when doing this 32 bit and all the supplied libraries have x86_64 parts, so I don't get what's going wrong. Thanks, I did manage to get a 64-bit fortran compiler, but I cannot get the configure script to understand the atlas/blas/lapack libraries that Apple helpfully supplies. I've actually had more luck building from source the past week than using MacPorts. If it doesn't have 64 bit the compiler is available as source. You end up with fewer surprises that way.ĭid you try the g45 beta that is on MacPorts? That's the gnu version of the compilers which includes Fortran. I tend to put /opt/localbin after my standard path, and then alias the specific ones that I want to use instead of Apple's binaries. So I guess the answer to your question is that it's all about the path. It kind of sucks having another whole tree, but it's only disk space really. Ie we used to regularly have problems with the openssl headers having the incorrect version number compared to the actual libraries, to name just one example. What's the best way to deal with the redundant packages? The ones that are already installed by SL that get installed again? Is it mostly an issue of the order they appear in the PATH, or is there something more complicated? Because last I checked, both Fink and Macports installed redundant packages on first install, no matter if you ask for them or not.įink and MacPorts both fulfill their dependencies internally, because historically we've seen it be really problematic to try and rely upon Apple's software for dependencies. ![]() Hopefully there's a way to do it without just wiping out Macports and reinstalling from the latest dmg.īuilding the base macports bits from an SVN checkout might work. I'm not sure what your options are for upgrading to that when your port command isn't working. The version they released on the 27th (1.8.0) is working fine. (file "/opt/local/bin/port" line 40) Has anyone else run into this, and if so, what's the best way to resolve it? I have a feeling that backing up /opt/local and rebuilding Macports (and all my packages) from scratch is going to be the way to go.Įdit: The solution appears to be to reinstall Macports using the Snow Leopard DMG on this page, then to follow the architecture migration procedure on this page. "load /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib" ![]() opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib: mach-o, but wrong architecture I had been using Macports with Leopard, and the upgrade to Snow Leopard seems to have broken it.ĭlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): no suitable image found.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |