Re: [Fink-devel] cdat-4.0-1012 appears to have an unsatisfiable dependency graph

[Alexander H. <ale...@gm...>]

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