libiconv problems after urxvt upgrade

Joerg van den Hoff j.van_den_hoff at fzd.de
Mon Mar 17 06:49:34 PDT 2008


On Fri, Mar 14, 2008 at 08:53:37PM -0500, Ryan Schmidt wrote:
> On Mar 14, 2008, at 07:38, Joerg van den Hoff wrote:
> 
> >ryan,
> >
> >thanks a lot for bothering. I really appreciate this.
> >
> >On Fri, Mar 14, 2008 at 06:39:20AM -0500, Ryan Schmidt wrote:
> >
> >>On Mar 13, 2008, at 06:11, Joerg van den Hoff wrote:
> >>
> >>>during upgrade from urxvt8.7 to the current version I got the error
> >>>message
> >>>
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>>Portfile changed since last build; discarding previous state.
> >>>--->  Fetching libiconv
> >>>--->  Verifying checksum(s) for libiconv
> >>>--->  Extracting libiconv
> >>>--->  Applying patches to libiconv
> >>>--->  Configuring libiconv
> >>>--->  Building libiconv with target all
> >>>--->  Staging libiconv into destroot
> >>>--->  Packaging tgz archive for libiconv 1.12_0+darwin_8
> >>>--->  Deactivating libiconv 1.11_0
> >>>Error: Deactivating libiconv 1.11_0 failed: Active version of
> >>>libiconv is not 1.11_0 but 1.11_0+darwin_8.
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>
> >>Peculiar...
> >>
> >>>after which install proceded (apparently successful).
> >>
> >>I don't know why MacPorts proceeds when it encounters an error
> >>activating a port. This only leads to further errors down the road,
> >>as you've seen:
> >
> >deserves this an "official" bug report (I was hoping a bit the ml  
> >might
> >suffice)?
> 
> All bugs deserve a bug report in our issue tracker. :) I'm just not  
> sure how to report this. I've seen it before, but I forget how it  
> happened to be exactly. And you don't know how it happened to you  
> either. Without a reproduction recipe, it'll be hard to fix. But it  
> should still be filed. I tried to search just now (summary contains  
> "activat", component = base) and didn't find it.
> 
> 
> >>>trying to start `urxvt' now throws the error:
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>>dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
> >>>Referenced from: /opt/local/lib/libXft.2.dylib
> >>>Reason: Incompatible library version: libXft.2.dylib requires
> >>>version 7.0.0
> >>>or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>
> >>No libiconv is active, because of the earlier error, so ports that
> >>require libiconv now explode.
> >>
> >>>trying a
> >>>
> >>>`sudo port deactivate libiconv at 1.11_0+darwin_8'
> >>>
> >>>yielded
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>>Error: port deactivate failed: Registry error: libiconv not
> >>>registered as
> >>>installed & active.
> >>>===================================CUT============================== 
> >>>==
> >>>========
> >>>which seems inconsistent with the error message during urxvt  
> >>>install.
> >>
> >>Agreed. That seems inconsistent. Not sure how you got into this  
> >>state.
> >
> >neither am I. I'm definitely _not_ tinkering with the system.  
> >rather I try
> >to upgrade by and then relevant packages and go on with my work.
> >
> >>>after a `sudo port activate libiconv at 1.12' now everything seems to
> >>>work,
> >>
> >>Great!
> >>
> >>>but
> >>>the above messages seems to hint at some grade of corruption of the
> >>>internal state of
> >>>port. is this the case? can I sanitize/check it somehow without
> >>>purging
> >>>everything?
> >>
> >>What does "port installed libiconv" show now?
> >
> >this:
> >
> >The following ports are currently installed:
> >libiconv @1.10_1+darwin_8
> >libiconv @1.11_0+darwin_8
> >libiconv @1.12_0+darwin_8 (active)
> >libiconv @1.9.2_1
> 
> Looks ok to me. You can force-uninstall those older inactive versions  
> if you want since nothing is using them.
> 
> 
> >>>I also notice that many packages appear both with
> >>>`port list active' _and_ `port list inactive'. how can this be?
> >>
> >>"port list" does not do what you think it does. "port list" does the
> >>following: for each port, display the current version (not the
> >>installed version).
> >>
> >>You probably would rather use "port installed active" and "port
> >>installed inactive".
> >
> >thanks for this clarification. I read the manpage again: this  
> >behaviour
> >is far from obvious from the manpage, since there "installed" and  
> >"active"
> >are both listed as pseudo-portnames which should imply that 'port  
> >list active'
> >should do what I expected.
> 
> No... because "port list" does not do what you expected. Read the  
> description of "port list" in the manpage:
> 
>    list
>      If no argument is given, display a list of the the latest  
> version of all
>      available ports.  If portname(s) are given as arguments,  
> display a list
>      of the latest version of each port.
> 
> (I just noticed "the the" and fixed it in r35030.)
> 
> So "port list active" lists the latest version of each active port,  
> *not* the installed version of each active port. For example, if you  
> deactivate libiconv @1.12_0+darwin_8 and then activate libiconv  
> @1.11_0+darwin_8, "port list active" (or "port list libiconv") will  
> still show "libiconv                       @1.12           textproc/ 
> libiconv" because 1.12 is the latest version of that port.
> 
> 
> >also "port installed" (or "port installed active")
> >works while "port active" does not. should not the manpage be  
> >modified to
> >make this point clear?

maybe a hint concerning the 'double nature' of `installed' (command
_and_ pseudo-portname) at both places where `installed' is defined
in the manpage would help. a few examples like yours (port list active
vs. port installed active, e.g.) might be good, too. but of course you
are right. it _is_ described correctly in the manpage, one only has to read
it completetly...

> 
> "installed" is both a command (e.g. "port installed" -- show  
> information about installed ports (by default, show information about  
> all installed ports, but you can specify a subset if you want, e.g.  
> "port installed libiconv")) and a pseudo-portname ("port info -- 
> maintainer installed" -- show the maintainer of each installed port).
> 
> "active" is only a pseudo-portname. It is not a command.
> 
> Do you have a specific suggestion about what should be changed? A  
> particular passage that is confusing, or a specific sentence you'd  
> like to have added?
> 
> Note that I believe the manpages have been rewritten since 1.6.0.  
> That is, they used to be standalone manpages, but with the recent  
> effort to write the web-based MacPorts guide, I believe the manpages  
> have also been rewritten and reformatted in the same docbook style,  
> though at the time MacPorts 1.6.0 was released there were some  
> problems actually generating the manpages from the docbook sources so  
> the old manpages were left in. I'm not sure if that situation has  
> changed since then.
> 
> 
> >>>and a last question: the "active" ports are the only one in use
> >>
> >>Yes.
> >>
> >>>or are "inactive" ones (especially libs) secretly used by other  
> >>>ports?
> >>
> >>No, inactive ports are not used at all.
> >>
> >>>I noted that a tentative
> >>>
> >>>`sudo port uninstall libiconv at 1.11_0+darwin_8'
> >>>
> >>>showed me lots of ports depending on it which would need prior
> >>>uninstall.
> >>
> >>The message shown by MacPorts is misleading. The message says "Unable
> >>to uninstall libiconv 1.11_0+darwin_8, the following ports depend on
> >>it" but what the message should say is "Unable to uninstall libiconv,
> >>the following ports depend on it" (in other words it should not list
> >>the version or variants). Since you already have a newer version of

and could _this_ not be done in future releases?

> >>libiconv installed, it's perfectly fine to remove the older version.
> >>MacPorts just doesn't know any better. Educate it by using "-f" when
> >>uninstalling ports in such situations:
> >
> >ah. maybe I manage to remember this in the future.
> >
> >>sudo port -f uninstall libiconv at 1.11_0+darwin_8
> >>
> >>>I understand that different versions of libs are needed at the same
> >>>time
> >>
> >>That's not how MacPorts works. Only one version of a library can be
> >>used at a time. If multiple versions of a library are needed at the
> >>same time, multiple separate ports must be created. See for example
> >>apr and apr0, db41 thru db46, and many other examples.
> >
> >please, could you clarify this a bit? does this not still mean  
> >that, e.g.
> >apr requires/installs, say libtmp1.1, and apr0 libtmp1.2 so that both
> >need to be there and are used "at the same time" (meaning when apr or
> >apr0 are started)? whether this is necessitated by two variants of
> >an application (say apr) or by uncorrelated apps seems not to make a
> >difference.
> 
> I'll try to clarify, with the APR example. APR is the Apache Portable  
> Runtime, a library used by the Apache web server, Subversion, and  
> other software that wants to run on multiple operating systems  
> without having to write lots of OS-specific code. OS-specific code is  
> encapsulated inside APR.
> 
> We have two ports for Apache 2: apache2, which installs Apache 2.2.x,  
> and apache20, which installs Apache 2.0.x. Most people will want the  
> latest version and so they will choose apache2. Some people may want  
> to use pre-compiled modules designed for Apache 2.0.x which won't  
> work with Apache 2.2.x, therefore they will choose apache20.
> 
> Apache 2.2.x requires APR 1.2.x and does not work with earlier  
> versions. Apache 2.0.x requires APR 0.9.x and does not work with  
> later versions.
> 
> Back in 2005, the apr port installed APR 0.9.x. But then in December  
> 2005, APR 1.2.x was released and the apr port was updated to that  
> version.
> 
> You cannot ask MacPorts to install an older version of a port. You  
> can only install the current version of a port.
> 
> Therefore, we need separate ports apr (provides APR 1.2.x) and apr0  
> (provides APR 0.9.x) so that ports that want the latest version (like  
> apache2) can use apr, and ports that want the older 0.9.x version  
> (like apache20) can use that version.
> 
> Back to libiconv: there is only one libiconv port, so your only  
> option is to install the latest version of libiconv. If there were a  
> port that required an older version of libiconv in order to run, we  
> would have to make a second libiconv port for that older version of  
> the libiconv software.
> 
> 
> >so, this is still not clear to me: I would expect that
> >some ports rely on a certain version of a lib, others (e.g. more
> >up-to-date ones) need different versions. surely not all available  
> >ports
> >always are in a state that they use the same library versions?
> 
> In MacPorts, there is no way to specify that a port depends on a  
> certain version of another port. It is only possible to specify that  
> a port depends on another port.
> 
> >and even
> >if so, would not otherwise a single upgrade of a single package
> >(inclduing some lib update) lead to necessity of upgrading virtually
> >_everything_ else which needs that library? (i'm not offended if
> >I get the "read the manual" message :-))
> 
> For most library updates, the library is a drop-in replacement for  
> the old library. Software that linked with and worked with the old  
> library will continue to work with the new library. But consider  
> gettext, the GNU internationalization library used by many many other  
> ports. When gettext was updated from 0.14.x to 0.15.x, the library  
> changed in a binary-incompatible way so the library version was  
> increased, which caused all other ports to break until they were  
> rebuilt. See the problem hotlist:
> 
> http://trac.macosforge.org/projects/macports/wiki/ 
> ProblemHotlist#a2.Aportfailedtobuildupgradeorrunwithamessagereferringtol 
> ibintl.3.dylib
> 
> This may not be super, but it is the state of MacPorts at this time.
> 

ryan, thanks a lot for taking (again) the time to explain this so thoroughly.
it really helped clarifying things up quite a bit for me.

joerg

> 
> >>>but why, then, is one declared "active" the others "inactive"?
> >>
> >>When you "sudo port upgrade foo", the old version is deactivated and
> >>the new version is activated. If you don't want the old version
> >>anymore, you can then uninstall the old version:
> >>
> >>sudo port uninstall foo @1.2.3
> >>
> >>If you want MacPorts to automatically uninstall the old version
> >>during the upgrade, use the "-u" flag:
> >>
> >>sudo port -u upgrade foo
> >>
> >>This will fail if any port depends on foo. In that case you must also
> >>force it. But the force flag also causes MacPorts to rebuild all
> >>dependencies, possibly multiple times, which you don't want. So if
> >>you want to force an upgrade, you should also always use the
> >>nonrecursive flag:
> >>
> >>sudo port -nfu upgrade foo
> >>
> >>>so in short what's the difference between "active" and "inactive",
> >>>especially
> >>>for libs?
> >>
> >>Inactive ports are not used. They're just there so that you can
> >>activate them again, should you choose to do so (after deactivating
> >>the version that you currently have active.) If you don't want to
> >>reactivate old versions, you can uninstall them to reclaim the disk
> >>space.
> >
> >
> >thanks a lot for getting most of my questions answered.
> 
> 


More information about the macports-users mailing list