Re: [MacPorts] #42672: x264 @20130823_0: universal build failure on Apple clang, i386 issues.
On Tuesday March 04 2014 18:36:51 MacPorts wrote: --+--- Comment (by devans@…): +asm marked conflicts +universal in r117592 for now. some questions: - any idea/estimation on the performance gains the +asm variant allows - I'm not at my Mac, but are you sure +asm isn't a dependency of ffmpeg (I have the +gpl2+nonfree+universal variant)? - If it is (and I realise this may seem overly kludgy), would it be possible (for now ;) ) to drop +asm in the 32bit build of +asm+universal (which would just introduce another performance loss for 32bit compared to 64 bit)? I think ffmpeg+universal is build already through separate i386 and x86_64 builds lipoed together at the end (so the infrastructure is there to combine asm and non asm builds into a single universal file), am I correct? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: [MacPorts] #42672: x264 @20130823_0: universal build failure on Apple clang, i386 issues.
On Mar 5, 2014, at 02:07, René J.V. Bertin wrote: - If it is (and I realise this may seem overly kludgy), would it be possible (for now ;) ) to drop +asm in the 32bit build of +asm+universal (which would just introduce another performance loss for 32bit compared to 64 bit)? I think ffmpeg+universal is build already through separate i386 and x86_64 builds lipoed together at the end (so the infrastructure is there to combine asm and non asm builds into a single universal file), am I correct? That is correct, ffmpeg does use the muniversal portgroup, so it is possible for a port author to use different arguments and environment variables to build each architecture, if desired. It is not possible to specify different variants for each architecture; variants apply to the port as a whole. Is it the case that the asm variant only works for the x86_64 architecture? If so, my proposed fix would be that the asm variant only be selectable if x86_64 is within the architectures that will be built, and if so, to only apply to that architecture and not any others. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
IconServiceAgent
Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don’t know how to find the temporary folder for a “no login” user like macports. Anyhow, I might be saying stupid things. My apologies if it’s the case. Not an expert in computers. Anyhow, if someone could let me know if it’s a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IconServiceAgent
What system are you running on? I do not have that daemon on my system... Anyway, to deal with unkillable daemons, you usually have to mess with launchd via launchctl, but I am not sure how you would do that for the macports user, seeing as it is a no login user as you mentioned... On Wed, Mar 5, 2014 at 9:49 AM, Ghyslain Leclerc ghlecl...@gmail.comwrote: Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don't know how to find the temporary folder for a no login user like macports. Anyhow, I might be saying stupid things. My apologies if it's the case. Not an expert in computers. Anyhow, if someone could let me know if it's a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IconServiceAgent
Hi, I've seen this myself, once or twice. If you search the web for com.apple.IconServicesAgent you will find plenty of reports. For instance http://kieranhealy.org/blog/archives/2014/01/07/an-issue-in-mavericks-with-com-dot-apple-dot-iconservicesagent/ It is seemingly more a glitch in OSX 10.9 w.r.t. temporary folders, than anything to do with macports, although macports for some reason seems prone to triggering it. In my case I just removed (using sudo) the temporary directories that where causing the problem (use Console to find out what those are for you), rebooted the system and it went away. Haven't seen it come back for a while now. Chris On 05/03/14 15:45, Eric Gallager wrote: What system are you running on? I do not have that daemon on my system... Anyway, to deal with unkillable daemons, you usually have to mess with launchd via launchctl, but I am not sure how you would do that for the macports user, seeing as it is a no login user as you mentioned... On Wed, Mar 5, 2014 at 9:49 AM, Ghyslain Leclerc ghlecl...@gmail.com mailto:ghlecl...@gmail.com wrote: Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don’t know how to find the temporary folder for a “no login” user like macports. Anyhow, I might be saying stupid things. My apologies if it’s the case. Not an expert in computers. Anyhow, if someone could let me know if it’s a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org mailto:macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IconServiceAgent
Hello. Thank you to you both for your comments. Eric : I am running on OSX 10.9.2. I don’t know what to answer about the deamons. I have not done anything with that. Chris : I have seen this post. Thus my comment about the temporary folders. I have rebooted without deleting any folder and it changes nothing. I must, I’m afraid, admit I have never worked much with the Console application. I know it’s for viewing logs, but I can’t navigate it very well. I will try, but if you could spare a few moments more to nudge me in the right direction, it would be appreciated. I would be happy to try and delete or create the appropriate folders. I had gathered as well that it was a OSX problem more than a Macports one, but did not know where to get help. Don’t know if it makes any sense, but the first time I ran into the problem (OSX version 10.9.1), the IconServicesAgent would launch after a selfupdate. I think it might be because after the rsync, OSX wants to update the icon for every file in the tree. I might make no sense at all. Just a thought. Anyhow, thanks again to you both. Ghyslain On Mar 5, 2014, at 10:52, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, I've seen this myself, once or twice. If you search the web for com.apple.IconServicesAgent you will find plenty of reports. For instance http://kieranhealy.org/blog/archives/2014/01/07/an-issue-in-mavericks-with-com-dot-apple-dot-iconservicesagent/ It is seemingly more a glitch in OSX 10.9 w.r.t. temporary folders, than anything to do with macports, although macports for some reason seems prone to triggering it. In my case I just removed (using sudo) the temporary directories that where causing the problem (use Console to find out what those are for you), rebooted the system and it went away. Haven't seen it come back for a while now. Chris On 05/03/14 15:45, Eric Gallager wrote: What system are you running on? I do not have that daemon on my system... Anyway, to deal with unkillable daemons, you usually have to mess with launchd via launchctl, but I am not sure how you would do that for the macports user, seeing as it is a no login user as you mentioned... On Wed, Mar 5, 2014 at 9:49 AM, Ghyslain Leclerc ghlecl...@gmail.com mailto:ghlecl...@gmail.com wrote: Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don’t know how to find the temporary folder for a “no login” user like macports. Anyhow, I might be saying stupid things. My apologies if it’s the case. Not an expert in computers. Anyhow, if someone could let me know if it’s a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org mailto:macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IconServiceAgent
Hi, On 5 Mar 2014, at 05:56 pm, Ghyslain Leclerc ghlecl...@gmail.com wrote: Hello. Thank you to you both for your comments. Eric : I am running on OSX 10.9.2. I don’t know what to answer about the deamons. I have not done anything with that. Chris : I have seen this post. Thus my comment about the temporary folders. I have rebooted without deleting any folder and it changes nothing. I must, I’m afraid, admit I have never worked much with the Console application. I know it’s for viewing logs, but I can’t navigate it very well. I will try, but if you could spare a few moments more to nudge me in the right direction, it would be appreciated. I would be happy to try and delete or create the appropriate folders. Start the console application, and just take a look at the main system log all entries. Search for any entries relating to this and they will tell you the paths that need removing. If you are unsure post here. I had gathered as well that it was a OSX problem more than a Macports one, but did not know where to get help. Don’t know if it makes any sense, but the first time I ran into the problem (OSX version 10.9.1), the IconServicesAgent would launch after a selfupdate. I think it might be because after the rsync, OSX wants to update the icon for every file in the tree. I might make no sense at all. Just a thought. Anyhow, thanks again to you both. Ghyslain On Mar 5, 2014, at 10:52, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, I've seen this myself, once or twice. If you search the web for com.apple.IconServicesAgent you will find plenty of reports. For instance http://kieranhealy.org/blog/archives/2014/01/07/an-issue-in-mavericks-with-com-dot-apple-dot-iconservicesagent/ It is seemingly more a glitch in OSX 10.9 w.r.t. temporary folders, than anything to do with macports, although macports for some reason seems prone to triggering it. In my case I just removed (using sudo) the temporary directories that where causing the problem (use Console to find out what those are for you), rebooted the system and it went away. Haven't seen it come back for a while now. Chris On 05/03/14 15:45, Eric Gallager wrote: What system are you running on? I do not have that daemon on my system... Anyway, to deal with unkillable daemons, you usually have to mess with launchd via launchctl, but I am not sure how you would do that for the macports user, seeing as it is a no login user as you mentioned... On Wed, Mar 5, 2014 at 9:49 AM, Ghyslain Leclerc ghlecl...@gmail.com mailto:ghlecl...@gmail.com wrote: Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don’t know how to find the temporary folder for a “no login” user like macports. Anyhow, I might be saying stupid things. My apologies if it’s the case. Not an expert in computers. Anyhow, if someone could let me know if it’s a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org mailto:macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: IconServiceAgent
Hi again, I use a non administrator user for day to day things, so I could not see the main system log. That was the reason I did not find it when I went looking the first time. Knowing what to look for, I realized I did not have the admin rights. Sorry. Went into Console, found the problematic temp directory, removed it. Rebooted and no sign of the problem so far (after 10 minutes). I have not updated Macports, so I wouldn’t say everything is OK yet, but at least, now, the IconSerivcesAgent is not restarting as soon as I reboot the computer. So progress and I am very much happy. Thought I would write it here so that if someone else is looking for the info, they know what happened to me. Thanks for your advice and most importantly your precious time (sure you’re just as busy if not more than me). Very much appreciated. Ghyslain On Mar 5, 2014, at 13:10, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, On 5 Mar 2014, at 05:56 pm, Ghyslain Leclerc ghlecl...@gmail.com wrote: Hello. Thank you to you both for your comments. Eric : I am running on OSX 10.9.2. I don’t know what to answer about the deamons. I have not done anything with that. Chris : I have seen this post. Thus my comment about the temporary folders. I have rebooted without deleting any folder and it changes nothing. I must, I’m afraid, admit I have never worked much with the Console application. I know it’s for viewing logs, but I can’t navigate it very well. I will try, but if you could spare a few moments more to nudge me in the right direction, it would be appreciated. I would be happy to try and delete or create the appropriate folders. Start the console application, and just take a look at the main system log all entries. Search for any entries relating to this and they will tell you the paths that need removing. If you are unsure post here. I had gathered as well that it was a OSX problem more than a Macports one, but did not know where to get help. Don’t know if it makes any sense, but the first time I ran into the problem (OSX version 10.9.1), the IconServicesAgent would launch after a selfupdate. I think it might be because after the rsync, OSX wants to update the icon for every file in the tree. I might make no sense at all. Just a thought. Anyhow, thanks again to you both. Ghyslain On Mar 5, 2014, at 10:52, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, I've seen this myself, once or twice. If you search the web for com.apple.IconServicesAgent you will find plenty of reports. For instance http://kieranhealy.org/blog/archives/2014/01/07/an-issue-in-mavericks-with-com-dot-apple-dot-iconservicesagent/ It is seemingly more a glitch in OSX 10.9 w.r.t. temporary folders, than anything to do with macports, although macports for some reason seems prone to triggering it. In my case I just removed (using sudo) the temporary directories that where causing the problem (use Console to find out what those are for you), rebooted the system and it went away. Haven't seen it come back for a while now. Chris On 05/03/14 15:45, Eric Gallager wrote: What system are you running on? I do not have that daemon on my system... Anyway, to deal with unkillable daemons, you usually have to mess with launchd via launchctl, but I am not sure how you would do that for the macports user, seeing as it is a no login user as you mentioned... On Wed, Mar 5, 2014 at 9:49 AM, Ghyslain Leclerc ghlecl...@gmail.com mailto:ghlecl...@gmail.com wrote: Hello. Sorry if this is a known problem. Been Googling for hours now and searching the archive up to 6-7 months back to no avail. I would like to know if someone else has a problem with Macports and the IconServicesAgent process. I have a com.apple.IconServicesAgent process running as the macports user (confirmed via Activity Monitor) which takes 100% CPU for one of my core (almost, confirmed via Activity Monitor and the ps command on the terminal) and which I cannot kill. Actually, I cannot force quit it in activity monitor, but I can kill it with the kill command in Terminal, but it comes back right away. I have looked everywhere for a solution. I have found that creating a temporary folder where the service can work solved to problem for regular users, but I don’t know how to find the temporary folder for a “no login” user like macports. Anyhow, I might be saying stupid things. My apologies if it’s the case. Not an expert in computers. Anyhow, if someone could let me know if it’s a known problem and if there is a solution or if I should just accept that my machine now as one less core. Thanks Ghyslain P.S. : Sorry for my English. Not my first language. ___ macports-users mailing list macports-users@lists.macosforge.org
Re: source-highlight error after upgrade to 10.9
On Mar 4, 2014, at 17:33 , Ryan Schmidt ryandes...@macports.org wrote: On Mar 4, 2014, at 18:05, Jean-François Caron wrote: Hi, I finally caved in and upgraded to 10.9 from 10.7 in order to get reasonable C++11 support. One of the not-unexpected side-effects is random other problems coming up because of it. I have the environment variables LESS and LESSOPEN set for less to use source-highlight (e.g. http://superuser.com/questions/71588/how-to-syntax-highlight-via-less). With the upgrade, now I get this error whenever I use less: dyld: Symbol not found: __ZN5boost13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS5_12maybe_assignERKS9_ Referenced from: /opt/local/lib/libsource-highlight.4.dylib Expected in: /opt/local/lib/libboost_regex-mt.dylib in /opt/local/lib/libsource-highlight.4.dylib /opt/local/bin/src-hilite-lesspipe.sh: line 4: 15153 Trace/BPT trap: 5 source-highlight --failsafe --infer-lang -f esc --style-file=esc.style -i $source I did rebuild all my ports after upgrading, and all the other ones that I tested work. Is this because source-highlight is a GNU (thus libstcxx) program and 10.9 uses libcxx? Or some other problem? It works fine for me on Mavericks. I do believe the error occurred because boost and source-highlight were not both compiled with clang and thus libc++ on your system. If you really did uninstall and reinstall all ports, as per the wiki Migration page, then the only reason that should happen is if you requested that, by overriding configure.compiler. Did you? My boost was build with options +no_static+python27+no_single, using the default compiler afaik (I did not change configure.compiler). Boost does have variants in order to build it with different compilers, so I tried re-building it with +clang32 (since I already have clang32 installed for something else), but the error message remains. Is there a config file or log that I could provide for more precise diagnostic? Jean-François ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: source-highlight error after upgrade to 10.9
On Mar 5, 2014, at 15:13, Jean-François Caron wrote:
On Mar 4, 2014, at 17:33 , Ryan Schmidt wrote:
On Mar 4, 2014, at 18:05, Jean-François Caron wrote:
Hi, I finally caved in and upgraded to 10.9 from 10.7 in order to get
reasonable C++11 support. One of the not-unexpected side-effects is random
other problems coming up because of it.
I have the environment variables LESS and LESSOPEN set for less to use
source-highlight (e.g.
http://superuser.com/questions/71588/how-to-syntax-highlight-via-less).
With the upgrade, now I get this error whenever I use less:
dyld: Symbol not found:
__ZN5boost13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS5_12maybe_assignERKS9_
Referenced from: /opt/local/lib/libsource-highlight.4.dylib
Expected in: /opt/local/lib/libboost_regex-mt.dylib
in /opt/local/lib/libsource-highlight.4.dylib
/opt/local/bin/src-hilite-lesspipe.sh: line 4: 15153 Trace/BPT trap: 5
source-highlight --failsafe --infer-lang -f esc --style-file=esc.style -i
$source
I did rebuild all my ports after upgrading, and all the other ones that I
tested work. Is this because source-highlight is a GNU (thus libstcxx)
program and 10.9 uses libcxx? Or some other problem?
It works fine for me on Mavericks.
I do believe the error occurred because boost and source-highlight were not
both compiled with clang and thus libc++ on your system. If you really did
uninstall and reinstall all ports, as per the wiki Migration page, then the
only reason that should happen is if you requested that, by overriding
configure.compiler. Did you?
My boost was build with options +no_static+python27+no_single, using the
default compiler afaik (I did not change configure.compiler). Boost does
have variants in order to build it with different compilers, so I tried
re-building it with +clang32 (since I already have clang32 installed for
something else), but the error message remains.
I see these compiler variants were recently added to the boost port (r116366).
I don’t know why. Usually, you should not need to set a specific compiler, and
should let MacPorts choose the correct default for you.
Is there a config file or log that I could provide for more precise
diagnostic?
Logs are automatically deleted upon successful installation, unless you asked
at installation time for them to be retained. For example, if you set “keeplogs
yes” in macports.conf at the time that you installed those ports, then their
main.log would be retained. If you used the “-k” flag while installing them
(e.g. “sudo port -k install boost”), then in addition to the main.log, the
entire work directory (which, if the port’s build system produces one, would
contain the config.log file) would be retained.
Please show the output of the following commands:
port -v installed boost source-highlight
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: source-highlight error after upgrade to 10.9
On Mar 5, 2014, at 18:19 , Ryan Schmidt ryandes...@macports.org wrote:
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
Here is the output of those commands:
port -v installed boost source-highlight
The following ports are currently installed:
boost @1.55.0_1+clang32+no_single+no_static+python27 (active)
platform='darwin 13' archs='x86_64'
boost @1.55.0_1+no_single+no_static+python27 platform='darwin 13'
archs='x86_64'
source-highlight @3.1.7_0 (active) platform='darwin 11' archs='x86_64'
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
/opt/local/lib/libboost_regex-mt.dylib:
/opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
/opt/local/lib/libicuuc.51.dylib (compatibility version 51.0.0, current
version 51.2.0)
/opt/local/lib/libicui18n.51.dylib (compatibility version 51.0.0,
current version 51.2.0)
/opt/local/lib/libicudata.51.dylib (compatibility version 51.0.0,
current version 51.2.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)
/opt/local/lib/libsource-highlight.4.dylib:
/opt/local/lib/libsource-highlight.4.dylib (compatibility version
5.0.0, current version 5.0.0)
/opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 52.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 159.1.0)
Do you want me to change those settings in macports.conf to show the logs? By
the way, thanks for helping me figure this out.
Jean-François
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: source-highlight error after upgrade to 10.9
On Mar 5, 2014, at 20:33, Jean-François Caron wrote:
On Mar 5, 2014, at 18:19 , Ryan Schmidt wrote:
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
Here is the output of those commands:
port -v installed boost source-highlight
The following ports are currently installed:
boost @1.55.0_1+clang32+no_single+no_static+python27 (active)
platform='darwin 13' archs='x86_64'
boost @1.55.0_1+no_single+no_static+python27 platform='darwin 13'
archs='x86_64'
source-highlight @3.1.7_0 (active) platform='darwin 11' archs='x86_64'
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
/opt/local/lib/libboost_regex-mt.dylib:
/opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
/opt/local/lib/libicuuc.51.dylib (compatibility version 51.0.0, current
version 51.2.0)
/opt/local/lib/libicui18n.51.dylib (compatibility version 51.0.0,
current version 51.2.0)
/opt/local/lib/libicudata.51.dylib (compatibility version 51.0.0,
current version 51.2.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)
/opt/local/lib/libsource-highlight.4.dylib:
/opt/local/lib/libsource-highlight.4.dylib (compatibility version
5.0.0, current version 5.0.0)
/opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 52.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 159.1.0)
As you can see from the “otool -L” output, libsource-highlight.4.dylib links
with libstdc++, not libc++ as it should for Mavericks or later. As you can see
from the “port installed” output, the reason for this is that the port was
built on Lion (darwin 11), not Mavericks (darwin 13). This suggests you did not
follow the instructions in the Migration page for uninstalling and reinstalling
all ports, which is necessary after upgrading the OS X version, so you should
do that now.
https://trac.macports.org/wiki/Migration
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: source-highlight error after upgrade to 10.9
On Mar 5, 2014, at 21:12, Jean-François Caron wrote:
On Mar 5, 2014, at 18:38 , Ryan Schmidt wrote:
On Mar 5, 2014, at 20:33, Jean-François Caron wrote:
On Mar 5, 2014, at 18:19 , Ryan Schmidt wrote:
otool -L /opt/local/lib/lib{boost_regex-mt,source-highlight.4}.dylib
Here is the output of those commands:
As you can see from the “otool -L” output, libsource-highlight.4.dylib links
with libstdc++, not libc++ as it should for Mavericks or later. As you can
see from the “port installed” output, the reason for this is that the port
was built on Lion (darwin 11), not Mavericks (darwin 13). This suggests you
did not follow the instructions in the Migration page for uninstalling and
reinstalling all ports, which is necessary after upgrading the OS X version,
so you should do that now.
https://trac.macports.org/wiki/Migration
You caught me. I did look at those instructions and saw that they were not
very good, and “port upgrade outdated” did re-install a large number of
ports (though I didn’t check carefully that /all/ were reinstalled) so I
assumed that those instructions were old and disused. After all, wikis are
where documentation goes to die and all that…
You’re not wrong about that. We have many outdated wiki pages. The Migration
page is current, however.
Why do the Migration instructions ask the user to manually sift through their
entire list of ports, including lib dependencies? Couldn’t it tell them just
to extract the list of requested ports with “port echo requested”, and
reinstall just the requested ports? The current instructions will mess up
users’ list of requested ports because it’s sometimes difficult to figure out
if a port was installed /just because/ it’s a dependency, or because it was
also wanted on its own.
While I am guilty of assuming that I was smart enough to ignore instructions,
instructions this tedious deserve to be ignored.
If there was a way to query the list of ports “as requested” i.e. with only
the user-requested variants (not including default variants), then this
migration would be trivial, and in the case of errors, it would likely be a
short (or at least shorter) list of ports to deal with:
port echo as_requested myports.txt
..uninstall all ports…
sudo port install `cat myports.txt`
I know I sound like a jerk with these comments, but c’mon..manually sorting
through a list of possibly hundreds of ports to see which are dependencies?
I understand your frustration, and agree the instructions are tedious.
Rebuilding all ports on a new major OS version is tedious but necessary to
prevent problems such as the one you encountered. The instructions for how to
rebuild all ports could perhaps yet be streamlined.
Recording and restoring only requested ports sounds perfectly reasonable. I’m
not sure why the instructions don’t say to do that. Please give it a try if you
can! If it fails, you can always start over with the full reinstall list.
I’d first examine the output of “port installed requested” and “port installed
unrequested” and make sure the lists reflect your reality; you can use “sudo
port setrequested” and “sudo port unsetrequested” to fix incorrect entries.
You can also use “port -v installed | grep -v 'darwin 13'” to find only those
ports that were not built on Mavericks; since you already did reinstall many
ports on Mavericks, this may reduce your list of ports to reinstall
considerably.
In fact, ports that weren’t built on the current OS version should show up as
outdated. For example, “port outdated” should currently show that
source-highlight is outdated, and “sudo port upgrade source-highlight” should
rebuild it, thus correcting this specific problem you wrote about.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: source-highlight error after upgrade to 10.9
On Wed, Mar 5, 2014 at 10:31 PM, Ryan Schmidt ryandes...@macports.orgwrote: Recording and restoring only requested ports sounds perfectly reasonable. I’m not sure why the instructions don’t say to do that. Please give it a try if you can! If it fails, you can always start over with the full reinstall list. For what it's worth, I did this with both my recent updates (within the past 2 years; desktop from 10.6 to 10.8 and MBA from 10.7 to 10.9) with no problems. I considered it a chance to not only upgrade but clear out possible deadwood. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
