Hi,
If you can't be bothered doing the compilation yourself, I see:
$ otool -L libdfftw.2.0.7.dylib
libdfftw.2.0.7.dylib:
/sw/lib/libdfftw.2.dylib (compatibility version 3.0.0, current version
3.7.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)
$
This is from the /sw/lib directory, and I haven't removed any shared
libraries from the list.
Regards,
Edward
On 13 April 2012 17:24, Alexander Hansen <alexanderk.han...@gmail.com> wrote:
> On 4/13/12 12:17 AM, Edward d'Auvergne wrote:
>>
>> On 12 April 2012 19:34, Alexander Hansen<alexanderk.han...@gmail.com>
>> wrote:
>>>
>>> On 4/12/12 8:24 AM, Edward d'Auvergne wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am the lead developer of the project relax
>>>> (http://pdb.finkproject.org/pdb/package.php/relax-py27,
>>>> http://www.nmr-relax.com) and am having a problem installing the
>>>> xmgrace software (http://pdb.finkproject.org/pdb/package.php/grace).
>>>> The Xmgrace graphing software is used by relax to display certain
>>>> results. The installation of relax pulled in gcc-4.6, as relax
>>>> requires wxPython, which requires wxGTK, etc. The problem is that
>>>> xmgrace depends on fftw-shlibs which in turn depend on gcc-4.4! So
>>>> this is an indirect dependency clash. There is no need to install
>>>> gcc-4.4 on the system to compile fftw-shlibs when gcc-4.6 is present.
>>>> But installing gcc-4.4 removes openmpi-dev which is required by mpi4py
>>>> which itself is a relax dependency. Why does fink not detect this and
>>>> use the perfectly working gcc-4.6?
>>>
>>> Because we don't work by detection. We work by prescription because we
>>> want
>>> packages to build the same way for everybody regardless of what they have
>>> installed.
>>
>> Should all the info files in the 10.4 tree then be updated to gcc-4.6
>> to avoid dependency tree clashes? Anyway, if I have any other gcc
>> version problems, I'll just post here.
>>
> Both sound like good ideas to me.
>
>>>> Why does the fftw-shlibs info file
>>>>
>>>>
>>>> (http://fink.cvs.sourceforge.net/fink/dists/10.4/stable/main/finkinfo/sci/fftw.info?view=markup)
>>>> say that gcc44 is a dependency and not just specify a generic gcc
>>>> version?
>>>
>>> Because that doesn't always work. It is often the case that libraries
>>> built
>>> with gcc4N in turn link to libraries from the particular gcc4N with which
>>> they were built, so the general assumption people make when doing
>>> packages
>>> that use gcc4N is that they must carry a dependency on gcc4N-shlibs.
>>> That
>>> appears not to be the case here, however.
>>
>> So a fink installation tree with everything built using gcc-4.5 should
>> continue to be built against gcc-4.5 rather than the 4.4 or 4.6
>> specified in the info file of one of the packages on a remote branch
>> of the dependency tree. Can the info file not have 'gcc4' or 'gcc4N'
>> rather than gcc46? This would make it future proof once the new
>> gcc-4.7 is pulled into fink and a few info files are updated to this
>> version. Is the gcc dependency needed at all in the info file?
>>
> (gcc47 is in Fink already)
>
> For some packages, it is _mandatory_ that a particular choice of gcc4N be
> made.
>
> Example:
>
> $ otool -L /sw/lib/octave/3.6.1/liboctinterp.1.dylib
> /sw/lib/octave/3.6.1/liboctinterp.1.dylib:
> ...
> /sw/lib/gcc4.6/lib/libstdc++.6.dylib (compatibility version 7.0.0,
> current version 7.16.0)
> ...
>
> Octave explicitly links to a particular gcc4N, and so both a build
> dependency on gcc46-compiler and a dependency on gcc46-shlibs are specified.
> Other packages do the same thing.
>
> In some cases a package doesn't _link_ to gcc4N at all, and so it is
> possible to specify a choice of gcc44, gcc45, gcc46, and gcc47. fftw might
> be a case where we could do this--I'll take a look.
>
> If one doesn't specify a gcc4N in the .info file, then
>
> 1) there's no guarantee that it will even be installed at build time
> 2) there is also no guarantee that the package will even _find_ all of
> the appropriate files, because our gcc4N packages install their headers,
> libraries and some executables in private locations to ensure that packages
> are being built with Xcode's compilers unless we specifically ask them to
> use gcc4N.
>
>>> In any case, the -shlibs packages (containing the libraries) for gcc44
>>> and
>>> gcc46 _don't_ clash. When a package's dependency tree winds up bringing
>>> in
>>> multiple versions of the same library, this can indeed cause annoyances
>>> when
>>> building the package, such as having to restart the build procedure.
>>> However, this typically doesn't lead to any runtime issues.
>>
>> True, but as I have gcc46 built, I'm not waiting around for gcc44 and
>> its dependencies to compile ;) Thank you for updating the info file.
>>
>>
>>> The real issue here is that fftw is unmaintained and it didn't get
>>> updated
>>> to use gcc46 instead of gcc44 for builds on OS 10.5 and OS 10.6. I'm
>>> assuming you're on one of those, since you didn't say, and because fftw
>>> uses
>>> gcc46 on OS 10.7 because we banned having an earlier gcc4N there. I have
>>> updated fftw for OS 10.5 and 10.6 to use gcc46.
>>
>> I'll post here for any other 10.4 tree packages I find which seem to
>> need updating. I am using a 10.6.8 system as I am providing compiled
>> software as a Mac application within a DMG file as 3-way universal
>> binaries (http://www.nmr-relax.com/download.html#Mac_OS_X), on top of
>> the fink relax packages
>> http://pdb.finkproject.org/pdb/package.php/relax-py27, and some users
>> are using ppc7400 systems and will be for the foreseeable future. I
>> gave a slight hint to the system I am using with the info file link
>> into the 10.4 tree ;)
>
>
> True :-)
>
>>
>> Cheers,
>>
>> Edward
>>
>>
>> --
>> Edward d'Auvergne, PhD
>> lead developer of the projects relax, minfx, and bmrblib
>> http://www.nmr-relax.com
>> http://gna.org/projects/minfx
>> http://gna.org/projects/bmrblib
>>
>
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
> http://finkakh.wordpress.com/2012/02/21/got-job/
>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
