Re: [Fink-devel] Dependencies on gcc49?
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 re...@altimetrics.com wrote: 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 remain a back mess for users like me, who use a lot of gfortran related packages, like netcdf-fortran5. In case of fftw3 this was only a packaging update, not a version change, so I do not understand why the necessity to change from gcc48 to gcc49? Granted, for fftw3 it is a BuildDepends only, but still, what’s the rush, particularly since gcc49 is still at 4.9.0, and might not be stable yet. I would suggest to either revert fftw3 back to gcc48 or start a consolidated effort to upgrade all packages depending on gcc48 to gcc49. Regards, Remko -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ 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
[Fink-devel] Dependencies on gcc49?
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 remain a back mess for users like me, who use a lot of gfortran related packages, like netcdf-fortran5. In case of fftw3 this was only a packaging update, not a version change, so I do not understand why the necessity to change from gcc48 to gcc49? Granted, for fftw3 it is a BuildDepends only, but still, what’s the rush, particularly since gcc49 is still at 4.9.0, and might not be stable yet. I would suggest to either revert fftw3 back to gcc48 or start a consolidated effort to upgrade all packages depending on gcc48 to gcc49. Regards, Remko -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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
Re: [Fink-devel] r-base215. r-base-30 and r-base31
On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ 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
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ 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
Re: [Fink-devel] r-base215. r-base-30 and r-base31
(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 files to see exactly which headers are being loaded to see if it's matched. dan On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 dma...@netspace.org wrote: (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 files to see exactly which headers are being loaded to see if it's matched. dan On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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/https://lists.sourceforge.net/lists/listinfo/fink-devel -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: (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 files to see exactly which headers are being loaded to see if it's matched. dan On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free.
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 Howarth howarth.at.f...@gmail.com wrote: 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 howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: (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 files to see exactly which headers are being loaded to see if it's matched. dan On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the -
Re: [Fink-devel] r-base215. r-base-30 and r-base31
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 dma...@netspace.org 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 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 Howarth howarth.at.f...@gmail.com wrote: 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 howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: (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 files to see exactly which headers are being loaded to see if it's matched. dan On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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 dma...@netspace.org wrote: 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 again. dan On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth howarth.at.f...@gmail.com wrote: 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, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks dma...@netspace.org wrote: On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth howarth.at.f...@gmail.com 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-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60: 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} ${R_BATCH_OPTIONS} ${out} 21 Error: testing 'utils' failed Execution halted The failure appears to be due to an unresolved __pcre_valid_utf (or similarly named) symbol in libR.dylib. The R library is trying to use a private symbol in libpcre by guessing what it's called (and what its parameters are) in various different libpcre versions, but our most recent libpcre dropped that symbol altogether. Obviously a fragile situation to rely on undocumented non-public content. One useful change we can make is to patch out the -undefined dynamic_lookup from the configure script. That flag causes undefined symbols to be ignored by the linker, leaving them to cause problems at runtime. By removing the flag, the linking itself fails right away rather than leaving a possibly mis-built library. ..which reveals that util.dylib is missing -llzma in even in r-base30 and r-base31 (ones that do not have the pcre problem). dan -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs - ___ 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 -- Daniel Macks dma...@netspace.org - -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Re: [Fink-devel] work-in-progress branch to install all compiler wrappers in the .deb
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. This isn't 100% reliable, though. I've generated a work-in-progress branch in the fink github repository (i.e. I don't think it's quite ready to be a pull request) called compiler_wrapper_in_deb. As the name suggests, in this branch all of the compiler wrappers get installed in the .deb. Fink::PkgVersion hasn't been altered, because I haven't had time to explore the full ramifications of altering the wrapper generation there (not well commented or documented). For example, are temporary wrappers generated to build dpkg-bootstrap? Also, in the event of user error, in principle the various ensure* functions will attempt to regenerate the compiler wrappers, which is useful. Though I'd argue that it's poor from a maintenance standpoint to have separate copies of the wrapper scripts stored as heredocs within PkgVersion.pm and as normal files, which is what we've been doing for a while now. Anyway, feedback is appreciated. One virtue that just occurred to me about having the wrappers in the .deb vs. the current approach is that it that one can do modifications locally via a simple edit and then use fink reinstall fink to revert them back, as opposed to having to inject a new fink version. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ 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