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
