Re: Broken links detected...to ApplicationServices ?
On Jan 10, 2016, at 10:57 AM, Craig Treleaven wrote: > Aha! Did some careful checking and it appears that '-framework > ApplicationServices’ was missing from the linker flags. Adding that appears > to have cured the problem. > > Sorry for th noise. It's strange problem! I don't understand why omitting that flag would have the effect you described; I would have expected instead for a failure at link time due to undefined symbols. But regardless, I'm glad you found a solution. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Removal of perl 5.20
On 1/10/16 1:56 PM, Mojca Miklavec wrote: > Hi, > > First of all thanks to everyone involved in the process ... we have > made a successful transition to 5.22. As expected it took us 6 months > again, so I'm glad that we didn't start switching to 5.20 which would > require us to repeat the exercise again (for another 6 months?). > Thanks again to everyone for your contributions and I sincerely > apologise if I made some mistakes along the way. > > Now we have to remove old perl branches both in ports providing > +perl5_16 as well as for p5.16-foo. I would certainly like to remove > support for 5.16 and 5.18. I'm not yet sure about 5.20, but I'm in > favour of removing support for Perl 5.20 as well unless there are > known problems. > > Question(s): > > ** Does anyone know for any reason to keep the branch for 5.20 alive > or can we remove support for 5.20 as well? Should we perhaps wait a > bit longer to see if any new issues show up before removing support > for 5.20 and if so: for how long? I don't think there is any reason to treat 5.20 as a special case. The goal has been to switch to perl5.22 and remove support for any earlier versions. We've had six months experience with 5.22 with no major problems so I don't see any reason to keep 5.20 around after 5.16 and 5.18 have been removed. Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Removal of perl 5.20
Hi, First of all thanks to everyone involved in the process ... we have made a successful transition to 5.22. As expected it took us 6 months again, so I'm glad that we didn't start switching to 5.20 which would require us to repeat the exercise again (for another 6 months?). Thanks again to everyone for your contributions and I sincerely apologise if I made some mistakes along the way. Now we have to remove old perl branches both in ports providing +perl5_16 as well as for p5.16-foo. I would certainly like to remove support for 5.16 and 5.18. I'm not yet sure about 5.20, but I'm in favour of removing support for Perl 5.20 as well unless there are known problems. Question(s): ** Does anyone know for any reason to keep the branch for 5.20 alive or can we remove support for 5.20 as well? Should we perhaps wait a bit longer to see if any new issues show up before removing support for 5.20 and if so: for how long? (By the time we finish that, 5.24 might be out anyway, so we'll soon end up with two branches again.) See http://trac.macports.org/ticket/50245 N.B.: Please note that we are not discussing any major changes in packaging of Perl yet. Please make suggestions and discuss about changes in: http://trac.macports.org/ticket/5 This particular question is just about getting your opinion about removal of support for perl 5.20. The perl5.20 port would stay, only modules and branches would go. Mojca (Was: Migrating to Perl 5.20/5.22) On 14 July 2015 at 11:37, Mojca Miklavec wrote: > Hi, > > The modules for Perl 5.20 and 5.22 are basically ready by now (and > thanks to David nearly all are also up-to-date). They haven't > undergone much testing, but there is no way we can do extensive > testing on 1000++ modules. > > We should start migrating other ports that depend on Perl to a newer > version of Perl, but the question is: should we go to 5.22 or 5.20? > David proposed to go to 5.20 because 5.22 might be too new and not so > well tested yet. > > But my fear is that given how much time it takes us to do the > migration, 5.20 might become unsupported by the time we finish the > transition and then we'll have to start it all over again to the new > version (5.22 or maybe ever 5.24 by then). If Perl 5.22 doesn't work > for some ports, they could go for 5.20 (or an earlier version for that > matter) or wait until a particular problem gets resolved. Once all > ports migrate off 5.16, we could do an automatic upgrade from 5.16 to > 5.2x. > > Any thoughts? > > Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Broken links detected...to ApplicationServices ?
> On Jan 10, 2016, at 9:02 AM, Craig Treleaven wrote: > >> On Jan 10, 2016, at 12:18 AM, Ryan Schmidt wrote: >> >> >> On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote: >> >>> I’m working on a new version of MythTV (0.28) and I’m stymied on the >>> following. Every program (23), and every library and filter (28) is >>> reported by MacPorts to have a linking error similar to the following: >>> >>> ---> Scanning binaries for linking errors >>> … >>> Incompatible library version: /opt/local/bin/mythavtest requires version >>> 64.0.0 or later, but >>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >>> provides version 1.0.0 >>> DEBUG: Marking /opt/local/bin/mythavtest as broken >>> >>> Web searches and whatnot have not turned up any promising leads so I beg >>> the indulgence of those more experienced than I. >>> >>> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools. >> >> What do you get when you run: >> >> otool -L >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >> >> >> On my 10.10 and 10.11 systems, the first two lines are: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices: >> >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >> (compatibility version 1.0.0, current version 48.0.0) >> >> So, the OS provides ApplicationServices version 48.0.0 which is >> backward-compatible with 1.0.0. I'm not sure where you would have >> encountered a version 64.0.0 of ApplicationServices; it doesn't appear Apple >> has released any version that high yet. >> > > I get the same as you: > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices: > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > (compatibility version 1.0.0, current version 48.0.0) > > Perhaps it is just a coincidence, but I noticed the next line, CoreGraphics, > references “version 64.0.0”: > > /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics > (compatibility version 64.0.0, current version 600.0.0) > > >> Also, what do you get when you run: >> >> otool -L /opt/local/bin/mythavtest >> > > It links to 61 libraries/frameworks. I’ll try attaching a file. > >> Maybe you have DYLD_LIBRARY_PATH set to a value that is causing the wrong >> libraries to be used. >> > Don’t think so: > > $ printenv |grep -i LIB > PATH=/opt/local/bin:/opt/local/sbin:/opt/local/lib/mariadb/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin > Aha! Did some careful checking and it appears that '-framework ApplicationServices’ was missing from the linker flags. Adding that appears to have cured the problem. Sorry for th noise. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Broken links detected...to ApplicationServices ?
> On Jan 10, 2016, at 12:18 AM, Ryan Schmidt wrote: > > > On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote: > >> I’m working on a new version of MythTV (0.28) and I’m stymied on the >> following. Every program (23), and every library and filter (28) is >> reported by MacPorts to have a linking error similar to the following: >> >> ---> Scanning binaries for linking errors >> … >> Incompatible library version: /opt/local/bin/mythavtest requires version >> 64.0.0 or later, but >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices >> provides version 1.0.0 >> DEBUG: Marking /opt/local/bin/mythavtest as broken >> >> Web searches and whatnot have not turned up any promising leads so I beg the >> indulgence of those more experienced than I. >> >> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools. > > What do you get when you run: > > otool -L > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > > > On my 10.10 and 10.11 systems, the first two lines are: > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices: > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > (compatibility version 1.0.0, current version 48.0.0) > > So, the OS provides ApplicationServices version 48.0.0 which is > backward-compatible with 1.0.0. I'm not sure where you would have encountered > a version 64.0.0 of ApplicationServices; it doesn't appear Apple has released > any version that high yet. > I get the same as you: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) Perhaps it is just a coincidence, but I noticed the next line, CoreGraphics, references “version 64.0.0”: /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0) > Also, what do you get when you run: > > otool -L /opt/local/bin/mythavtest > It links to 61 libraries/frameworks. I’ll try attaching a file. /opt/local/bin/mythavtest: /opt/local/lib/libmythswscale.dylib (compatibility version 3.0.0, current version 3.1.101) /opt/local/lib/libmythavformat.dylib (compatibility version 56.0.0, current version 56.40.101) /opt/local/lib/libmythswresample.dylib (compatibility version 1.0.0, current version 1.2.101) /opt/local/lib/libmythavutil.dylib (compatibility version 54.0.0, current version 54.31.100) /opt/local/lib/libmythavcodec.dylib (compatibility version 56.0.0, current version 56.60.100) /opt/local/lib/libmythtv-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythupnp-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythbase-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythui-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmyth-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythmetadata-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythservicecontracts-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythprotoserver-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythfreemheg-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libmythhdhomerun-0.28.0.dylib (compatibility version 0.28.0, current version 0.28.0) /opt/local/lib/libtag.1.dylib (compatibility version 1.0.0, current version 1.14.0) /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1256.1.0) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0) /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0) /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility ver
