Martin Costabel wrote: > Alexander Hansen wrote: > [] >> The following package will be installed or updated: >> cdat >> The following 2 additional packages will be installed: >> scientificpython-py24 scipy-core-py24 > [] >> dpkg: considering removing f2py-py24 in favour of scipy-core-py24 ... >> dpkg: yes, will remove f2py-py24 in favour of scipy-core-py24. > [] >> While trying to install: >> f2py-py24-2.45.241-1004 >> >> The following inconsistencies found: >> scipy-core-py24 conflicts with f2py-py24, but f2py-py24 is installed > [] >> Fink isn't sure how to install the above packages safely. You may be >> able to >> fix things by running: >> >> fink scanpackages >> sudo apt-get update >> sudo apt-get install f2py-py24=2.45.241-1004 > [] >> I was curious whether anybody happened to know if the functionality of >> f2py has been subsumed into scipy-core, and if we therefore could just >> kill that dependency. > > Actually, scipy-core-pyXX provides f2py-pyXX. The virtual package > could suffice if the dependency wasn't versioned. > >> Also, it looks this is powerpc-only due to the historical lack of a g77 >> for Intels, which has since been remedied. > > Seems so. For building cdat, you need to remove "Architecture: > powerpc" also from languages/pyfort-py, sci/ioapi, graphics/xgks. In > addition, xgks needs a configure flag "CC=/usr/bin/cc" in order to > build, otherwise it picks up /usr/bin/c89 and gets very confused. > Great. That's what I found, too, and gave up when I hit the conflict. > Likewise, cdat needs "export CC=/usr/bin/cc". It then still didn't > build, with the following main errors: > >> mkdir: illegal option -- - >> usage: mkdir [-pv] [-m mode] directory ... > > (perhaps harmless) and > >> ld: library not found for -ldapclient >> collect2: ld returned 1 exit status > > The latter indicates a missing builddep on libdap8 instead of libdap3, > if libdap8-shlibs is installed. Changing libdap3 to libdap8 made the > build finally go through for me (10.5/intel). > I'll probably push that to libdap9, to go along with the current libnc-dap3. Part of my motivation here was to deprecate the older libdaps. > There are still lots of "incompatible implicit declaration of built-in > function 'foo'" warnings, with foo=malloc,strlen,strcpy,memcpy etc, > indicating a couple of missing #includes. > I don't know if I'm prepared to go that far yet. :-) I wasn't planning on taking it over.
-- Alexander Hansen Fink User Liaison ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel
