Remko,
That is the plan. We always migrate fink to the latest gcc4x
packaging but this takes time to execute.
Jack
On Tuesday, April 29, 2014, Remko Scharroo wrote:
> Dear Fink Developers,
>
> Today I saw the first dependency on gcc49 in fftw3.info.
>
> This is a major pain since (a
Dear Fink Developers,
Today I saw the first dependency on gcc49 in fftw3.info.
This is a major pain since (as far as I know) all other package require at most
gcc48.
When that introduction does not go paired with upgrading ALL packages that now
require gcc48 to be requiring gcc49 this will rem
On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks wrote:
On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
> wrote:
> > The r-base214 packaging seems to have test suite issues when built
> > against Xcode 5.1 on darwin12…
> >
> > Testing examples for package ‘utils’
> > /sw/src/fink.build/r-base21
Daniel,
Isn't the real problem that r-base in fink is being built with
--with-system-pcre but the fink lib pcre.1.dylib ends up linked into libR.
I assume we need a BuildConflicts on libpcre1 in order to have the system
pcre used.
Jack
On Tuesday, April 29, 2014, Danie
Using (apparently-)undocumented, internal implementation details that
are known to change in different versions is *always* a problem. Any
solution that doesn't involve actually not-doing-that is merely
deferring the same failure from occurring again in the future when
those details change agai
Isn't this just a header mismatch? We have both a build depends on libpcre1
and --with-system-pcre which is illogical. I am testing with
--with-system-pcre changed to --with-pcre=%p. FYI, macports doesn't pass
either flag and incorrectly ignores pcre.
On Tuesday, April 29, 2014, Daniel Macks wrot
(sorry if this email goes out twice!)
I don't think that's the meaning of "system". R appears to have
optional onboard/internal sources of various dependencies as an
alternative to using ones existing "on the system". *Where* on the
system is a different issue. You can probably check the .d fil
Well, empirically it fixed the r-base214 build on 10.8 for me by just
changing --with-system-pcre to --with-pcre=%p. It would be highly irregular
for the --with-system-pcre option not to be pushing the headers in
/usr/include to be used.
On Tuesday, April 29, 2014, Daniel Macks wrote:
> (sorry i
Okay, I now see that disables the use of pcre. Guess someone should open a
PR upstream, no? Do we really gain anything of use by having R-base build
against pcre?
On Tuesday, April 29, 2014, Jack Howarth wrote:
> Well, empirically it fixed the r-base214 build on 10.8 for me by just
> changing --
Why would they want a bug report against such an old version? Are newer
versions not-broken? I'm pretty sure I already mentioned exactly what
change they made in newer versions to avoid trying to access the
internals of the external libpcre.
dan
On Tue, 29 Apr 2014 13:44:34 -0400, Jack Howart
My mistake. I thought you had said the problem existed in the newer
versions but was latent rather than fixed.
On Tuesday, April 29, 2014, Daniel Macks wrote:
> Why would they want a bug report against such an old version? Are newer
> versions not-broken? I'm pretty sure I already mentioned exac
On 4/28/14, 8:24 AM, Alexander Hansen wrote:
> The current Fink release (0.36.4.1) dynamically generates the compiler
> wrappers for clang/clang++ (via functions in Fink::PkgVersion). We
> currently remove the wrappers when updating fink, and new ones are
> generated for the next build operation.
12 matches
Mail list logo
